PicLan Version 2.0.0.8 Release Announcement

(C) Copyright 1990-1997 Modular Software Corporation. All rights reserved.
For more information about PicLan contact: sales@modsoft.com or visit http://modsoft.com

PicLan Version 2.0.0.8 is now available

April 8, 1997

The 2.0.0.8 release has been delayed by about a week. It should hopefully be posted for all platforms on or before 4/11/97.

PicLan version 2.0.0.8 is currently being released for all platforms. This document discusses the elements that this release addresses. This release is considered a minor upgrade.

PicLan version 2.0.0.8 has the following bug fixes and additions:


Bug Fixes

Using Win95J

Problems with DBCS (Double Byte Character Set) versions of Windows 95 were discovered

A number of internal elements within the PicLan Windows client programs were found to be incompatible with Windows 95 J (Japanese). This has been corrected. Note that PicLan is not a DBCS application itself.

Error with Mentor PRO

Some users with Mentor PRO had problems with PicLan Windows applications

The same fixes for Win95J also fixed some intermittant problems when connecting to Mentor PRO systems that presented themselves with negative numbers for the PicLan serial number.

SERVER-PROCESS Print Job Internal Error

Some sites with busy printers have reported print jobs becoming stranded

A bug in the SERVER-PROCESS subroutine PLSP.EVENT.OUTBOUND.PRINT.JOB was discovered that would corrupt an internal SERVER-PROCESS table when print jobs were transferred across the network in a particular manner. The symptom would be that print jobs would be listed in LISTPEQS but not in PL-SPOOL. Executing a PL-SPOOL INIT would correct the problem (at least temporarily). This fix will hopefully keep the problem from happening in the first place.

Server Serial Number Errors

Some sites with unusual network configurations have reported problems with the Pick Host complaining about duplicate serial numbers

Some sites have network configurations where the Pick host system can communicate with itself, presumably through a router or switching hub. In general, this should not be possible, but some network configurations are apparently "looping-back" network traffic, so the Pick host literally can "talk to itself". By itself, this behavior is not a problem, but the security services inside of PicLan misinterpret this as an attempt to load a single copy of PicLan onto multiple hosts. The logic for this security check has been modified so that PicLan should no longer complain about seeing itself.


Bug Work-Arounds

Running a DSG on Windows NT when multi-homed

Windows NT workstation does not correctly handle IPX server routing in some configuration

Some users have reported problems running a PicLan Windows DSG on an NT system that was multi-homed or was used as a RAS (Remote Access Server) system. The underlying problem appears to be that NT is not allowing multiple applications to open the 0x0452 IPX SAP (Service Advertising Protocol) socket as the IPX specification requires. This release has a "work-around" for this problem that causes Windows DSG servers to listen on the PicLan dedicated IPX socket 0x80E1 instead. You can elect to use this workaround by selecting the "non-standard IPX SAP socket" button during PL_SETUP. The problem with the workaround is that selecting this function will prevent PicLan Windows applications from co-existing with PicLan DOS application entirely. If you use this workaround, do not attempt to run PicLan DOS programs on the same system if any PicLan Windows applications (servers or not) are running.

A more formal fix for this will be included in the next non-minor upgrade.


Performance Tuning

PLTW / PLTW32

PLTW and PLTW32 have been modified to use less system overhead

The PLTW and PLTW32 program have been reworked to lower the amount of system resources that they use when they are not busy or are in the background. Specifically, polling loops have been moved to dynamic timer events so that system resource monitors will not mistakenly think that the programs are always using 100% of the system's CPU resources. A side effect of this is that the throughput of the emulation engine may be lowered if the emulator is not the forground application.