November 11, 1996
(C) Copyright 1992-1995 Modular Software Corporation. All rights reserved.
For more information about PicLan contact: sales@modsoft.comThese problems have been encountered with various PicLan v 1.9.x.x and earlier v 2.0.0.x releases. All documented bugs are believed to have been fixed with the 2.0.0.4 build.
The following bug has been reported at a number of field installations and has been reproduced in-house at Modular Software
A number of installations have been reporting intermittant system hangs with PicLan. Most of these reports have been with Mentor PRO host systems, but some reports with other Ethernet hosts have also been reported. In general, only heavily loaded system with very fast processors (Pentium 90 or faster) have reported these problems. In addition, systems with NE2000 adapters appear to be more likely to experience these problems than systems with WD/CPX style adapters.
Research at Modular Software has discovered a timing bug in the PicLan driver that manifest's itself on systems with very fast CPUs. The PicLan NE/WD/CPX driver was developed based on source code provided by Western Digital with additional examples from other sources. In general, these examples are quite old. In reviewing the techniques used in implementing the PicLan driver and then comparing these techniques with current commercial drivers (such as current Novell ODI drivers), it was discovered that current drivers have been modified to signifigantly slow down programmed I/O write operations. This is presumably required because the previous delay instructions are now faster with faster CPUs (the typical delay instruction is to perform a dummy inport instruction from location 0x61 which is part of the programmable interrupt controller). Older NE2000 drivers would typically use one of the delay input instructions. Modern drivers appear to now be using three of these instructions in succession.
The PicLan driver has been modified to increase the delay period (a total of four of these dummy input instructions is now in use). This will have the effect of reducing PicLan performance slightly on slower speed processors. It should also make PicLan more stable on higher speed processors.
Initial testing at both Modular Software and at Monilith appears to indicate that this fix has been successful.
The fix is incorporated into all versions of the NE/WD/CPX drivers, both under DOS and on all Ethernet Pick host systems.
June 3, 1996Additional testing and reasearch indicates that the above fix only reduces the frequency of hangs
After additional stress testing, it has been discovered that the above fix only reduces the frequency of driver hangs. A more robust fix involving controlling the order in which the adapter is programmed for various stages of operation appears to have finally elimiated the problem. PicLan build 1.1.0.31 and 1.9.1.13 include this new fix.
Field sites have been reporting intermittant "Command Timeout" errors when importing large amounts of data from a DOS Serivces Gateway.
A number of sites (all running very large import operations) have reported "Command Timeout" errors when importing a large number of blocks from a DSG. The problem appears most prevelent with fast DSG systems that have the files stored locally (not over network connections). This bug has finally been reproduced at Modular Software and is a failure of the DSG program (all three versions) to successfully write the last character of a transaction if the network buffers happen to be completely full at just the wrong time. This bug has been fixed in build 1.9.1.14.
Field sites have reported this problem and it has been reproduced in-house at Modular Software
The PLTW32 program would fail if it is minimized when running on a Windows 95 system. This has been fixed in the build 2.0.0.0.
July 5, 1996
Field sites have reported this problem and it has been reproduced in-house at Modular Software
The PLTW32 program would fail with an invalid temporary directory if the system was configured as a DSG in the PL-CFG.INI file. This has been fixed in build 2.0.0.0.
The following bug was reported in a field installation and has been reproduced in-house at Modular Software.
Initial testing of PicLan on Windows 95 was conducted on a network that included IPX routers (actually Novell File Servers). The presence of these routers change the behavior of the Windows 95 IPX protocol support drivers.
If you are running PicLan v 1.9.x.x without the presence of IPX routers, you need to specify additional configuration information in network setup to give Windows 95 hints as to how to setup the IPX protocol layers. You only need to perform these operations for installations that do not have IPX routers. Specifically, you need to:
This change to the configuration allows the Windows 95 IPX driver to correctly direct PicLan IPX traffic out through the LAN adapter using the specified frame type. Future releases of PicLan will attempt to configure themselves making this manual configuration unnecessary, but the success of this is not certain.
The following bug has been noted in in-house testing at Modular Software.
In testing PicLan on Windows 95, it has been observed that the PicLan driver help program, PLAN32S.EXE, does not always appear to start. This manifests itself as an apparent hang in 16-bit Windows applications (like PL-STATW.EXE or PLTW.EXE). You can tell if this is the case by pressing <ctrl><alt><delete> and checking to see if PLAN32S.EXE is listed in the active process list. If it is not listed, you can kill the hung 16-bit Windows application and then try re-starting it.
Once a 16-bit application is running and PLAN32S.EXE has been started, other applications do not need to restart this application and should run without difficulty.
The PL-STATW.EXE application appears particularly prone to this hang, presumably because PLAN32S.EXE is started and stopped a total of 17 times in it's execution.
October 13, 1995 - PicLan v 1.9.1.0This problem has been corrected with the 1.9.1.0 driver. PLAN32S.EXE is now started and stopped apparently without problems. The length of time that it takes to start and stop PLAN32S.EXE is now longer and this can make some applications that allocate and deallocate PicLan handles appear to run slower. This should not effect production applications that keep connections open.
The following bug was reported in a field installation and has been reproduced in-house at Modular Software.
When running DOS applications in Windows 95 DOS boxes, the performance of network connection can be very bad when "Enhanced mode (32 bit and 16 bit) NDIS drivers" are in use. This poor performance is primarily noticable with terminal emulation sessions as jerky responsiveness. Executing PL-STAT (R on the Pick host system shows a large number of packet retries indicating that the network connection is losing packets.
This problem appears to be a bug in the VIPX (Virtual IPX) support layer in Windows 95.
A workaround for this bug is to load either "Real mode (16-bit) NDIS drivers" or "Real mode (16-bit) ODI drivers" in the "My Computer | Control Panel | Network Setup" setup screen for your LAN adapter.
This problem does not seem to effect 16-bit or 32-bit Windows applications.
The following problem has been reported in field installations and has been reproduced in-house at Modular Software.
Windows 95 does not appear to support IPX applications executing in DOS-boxes unless you load the NetWare client requestor. If you wish to use PicLan DOS applications, you will need to install the NetWare DOS requestor, even if you do not have a Novell server. Other than using some memory, loading the NetWare requestor does not appear to impact Windows 95 in terms of operation or performance.
You can use this proceedure to load the NetWare requestor:
You may need to insert your Windows 95 CD or diskettes as prompted and Windows 95 will need to reboot.
The first time that you reboot your system, the NetWare requestor will ask for a preferred server. You can select "<none>" and the question will not be repeated.
The following problem ws reported in a field installatin and has not been reproduced at Modular Software.
If you wish to run DOS applications within Windows NT, you must load the "Client Service for NetWare" network module. Without this module, Windows NT does not install VIPX (Virtual IPX) support within it's DOS boxes. More complete configuration information is being developed.
The following problems have been reported with PicLan versions 1.9.1.0 thru 1.9.1.7. Thanks to help from users, we believe these problems are finally solved.
The PL_SETUP program has been reported to fail with errors copying files. Error display login has been included in version 1.9.1.3 to try and locate what files are failing the copy commands. If you encounter this type of error (and if there is not a newer PicLan release or technical note concerning your problem), please email Modular Software with the error messages that you receive.
The following problems have been encountered with PicLan versions 1.9.1.4 thru 1.9.1.3. They appear to be fixed in version 1.9.1.4.
If you experience problems connecting with a PicLan DSG or if your connection to the Pick host system appears to be going through a router even though you are connected to the same network segment as the Pick host, try configuring the Pick host to use IPX routers and not run in AUTO mode. If you have experienced this type of error with PicLan version 1.9.1.4 or later on both the Pick host and on the client, please drop Modular Software a line with your configuration and symptoms.
The following problems were discovered at Modular Software and are believed to be fixed in PicLan version 1.9.1.3. These problems may have been experienced in the field and required the "Use EMS=no" and "UseXMS=no" PL-CFG.INI settings to workaround the problems.
An interrupt re-entrancy bug was discovered in the stand-alone DOS PicLan driver. This bug could cause data corruption when PicLan was using EMS or XMS memmory for communications buffers. The bug did not occur if PL-DEV was loaded. The bug also did not occur with all EMS and XMS memory managers. PicLan version 1.9.1.3 has been modified to work around the interrupt windows created by some EMS and XMS memory managers.
As a side note, in diagnosing this problem, the PLT.EXE program was modified to allow it to run without loading PL-DEV.
March 4, 1996 - PicLan v 1.9.1.4
You can reduce the amount of real-mode memory that PL-DEV uses in some system configurations.
If you have a system that is compatible with PicLan's use of extended and expanded memory, you can reduce the amount of real-mode memory that PL-DEV uses by setting "UseEMS=yes" and "UseXMS=yes" in the PL-CFG.INI file. Not all systems are compatible with these settings, so you will need to experiment to see if this works for you. If your system is compatible, the PL-DEV program will attempt to automatically load into high memory blocks and the EMS page frame. If you want to see where PL-DEV loads, include the '/I' option to display additional information about how PL-DEV loads.
March 4, 1996 - PicLan v 1.9.1.4
This limiation will be elimiated in a future release of PicLan.
The PicLan DSG for Windows will not allow routing of print jobs from NetWare to Microsoft NetWork print queues. In other words, you cannot specify:
QNameOut=\\system\printq
as a part of the PL-CFG.INI DOS Services Gateway section.
June 25, 1996 - PicLan v 2.0.0.0
These problems have been fixed with version 2.0.0.0
Numerous field installation have encountered problems traced to incorrect versions of various PicLan DLL files when executing Windows applications. PicLan version 2.0.0.0 now enforces DLL versions between all PicLan DLLs. This means that you will have to use the entire client release at one time and cannot mix and match components. The PL_SETUP program has also been enhanced to scan for old versions of PLAN.DLL and other shared PicLan files giving you the oportunity to delete them.