|September 30, 1999 No. 92|
NPL in a Windows NT Environment
[12/20/2000 - This Tech Note has been amended by, and should be used in conjunction with, Tech Note 98 "Configuring LANA Numbers in NT 4.0 and Windows 2000".]
In recent months, many Niakwa developers have installed NPL applications on Windows NT 4.0 servers, both as new installations and in transitioning from Novell NetWare servers. These installations require the developers to configure their customers networks for NPL to work properly.
To assist in this process, this document discusses configuration issues, protocol stack considerations, enabling Niaknetw.dll, related hardware/software considerations and/or conflicts, as well as known issues regarding the NPL Revision 5.0 RunTime. Please note that this document is not conclusive and will be expanded and/or revised as additional considerations regarding NPLs operation in a Windows NT environment are identified.
Configuring Windows NT Server and Workstation Protocols
NPL Release V is tested and supported on Microsoft Windows NT. This section details the NetBIOS configuration requirements for NPL to operate correctly in a Windows NT 4.0 environment. The following process applies to both Windows NT servers and workstations.
Display the network configuration screen by choosing Network from the Control Panel. Select the Protocols tab. The protocol list displays the installed networking protocols. NPL requires that the following items be present in the protocol list to operate correctly:
NWLink IPX/SPX and NWLink NetBios
All of the above
When NWLink IPX/SPX Compatible Transport and the NetBEUI protocols are loaded, Windows NT should automatically load NWLink NetBIOS.
Additional protocols may be listed in the protocols screen. The above protocols are the required minimum for NPL to operate properly on an NT network. Other protocols such as TCP/IP are transparent to NPL and will not affect the operation of the RunTime.
Any changes to the protocols listed will require the server to re-bind the protocols to the network. When the system prompts for confirmation to reboot, restart the computer to ensure the new settings take effect.
Protocol Stack Considerations
Occasionally the RunTime may experience difficulty authenticating with the NT server from properly configured NT workstations, resulting in an erroneous "Number of Authorized users exceeded" error message. This problem often relates to the Lana Number configuration of Netbios on the NT workstation and occurs when the first Lana number is bound to a wide-area network protocol, such as TCP/IP. The following will correct the Lana number problem on an NT 4.0 system:
- Log in as administrator.
- Open Properties of Network Neighborhood (or open the Control Panel/ Network applet).
- Click on the Services tab.
- Click on the NetBIOS Interface.
- Click the Properties... Button.
- The network route associated with Lana number 000 should be either
NwlnkNbà NwlnkIpx or
Nbfà (your network Card Name).
Note: If Lana number 000 is set to "NetBTà (something)", it needs to be adjusted.
Niakwa strongly recommends, and has recommended since WFW 3.11, associating the network route (NwlnkNbà NwlnkIpx) with Lana number 000. However, check the settings of a problem workstation against a properly functioning workstation to make sure that the settings are identical. Do not under any circumstances use a network route containing NetBT or WAN in the name. To correct the Lana Number:
- Highlight the 000, and press the Edit Button.
- Change the number to a larger one (such as 9).
- Highlight the number next to NwlnkNb à NwlnkIpx and change it to 0. (If you want to keep the LANA numbers in numerical order, you could then change the 9 (from step 2) to the next unused number in the sequence.)
- Close the Networks dialog and restart the machine for the change to take effect.
Back to Top
Migrating NPL Applications from NetWare to Windows NT
End users upgrading their network from Novell NetWare to Windows NT may notice a significant performance reduction regarding their NPL application.
Observations of performance loss are probably correct. NetWare provides file locking services that more closely correspond to the requirements of a typical NPL application. Specifically, NPL users on a network typically lock the file ($OPEN), access the data, then unlock the file ($CLOSE). Additionally, NPL disk statements automatically lock a file even when the application has not issued a $OPEN statement.
If the file is already locked by another user, the NetWare locking request can be made to wait for a short period, for the other user to release the file. However, Windows NT locking requests can only return immediately, indicating that the file lock is unavailable. The application must delay and try again. In many cases, the result is increased network traffic and longer delays to lock the file when compared to NetWare.
Recent additions to the $OPTIONS settings however, may improve the RunTimes efficiency reading and loading data in a Windows NT environment. One recommendation to improve performance is to set $OPTIONS byte 39 to HEX(03). This setting enables NPL to avoid issuing file locks on some statements, relying instead on the server to report file access conflicts (in which case NPL automatically retries the statement, this time using the file locks). On lightly loaded networks, this option may considerably improve performance. This enhancement was initially added to Revision 4.10 of NPL to increase performance in Windows for Workgroup environments, but applies to all NPL environments.
Setting $OPTIONS byte 51 to HEX(01) may also improve performance in a Windows NT environment. Byte 51 handles timing issues related to multitasking environments, and prohibits implied $BREAK operations after a polling KEYIN, if no keystroke is detected. Under certain conditions, this setting may increase the speed of sort functions.
After migrating from a Novell server to a Windows NT server, end users may also encounter a different problem. When starting the RunTime, users may receive an error message stating "You may be connected to a Novell server, but are not logged in. Please login to the Novell server before starting the Run Time."
This error occurs because when the Novell server is removed, the client and protocols are removed from the Network icon in the Control Panel of a workstation. However, the Novell drivers remain in the system registry. To correct this problem, remove the client and protocols from the Network icon in the Control Panel. The system will then prompt you to reboot. After rebooting, return to the Network icon and re-install the proper client and protocols.
Also, determine if the \WINDOWS\SYSTEM directory or \WINNT\SYSTEM contain NWCALLS.DLL. Windows NT does not need this library unless it is connected to a NetWare server. Rename the file to NWCALLS.OLD for example, then reboot the computer to clear the file from system memory. These adjustments should eliminate the error.
Back to Top
Windows 95/98 Workstation Configurations
NPL Release V is tested and supported on Microsoft Windows 95 and Windows 98. This section details the NetBIOS configuration requirements for NPL to operate correctly in a Windows 95/98 environment.
During the Windows 95/98 Setup, the network configuration screen will display the networking components that will be installed on your system. If Windows 95/98 is already installed on your system, display this list by choosing Network from the Control Panel, and selecting the Configuration tab. For NPL to operate properly, the list of networking components installed should appear similar to the following:
Client for Microsoft Networks
(Your Network Adapter is shown here)
IPX/SPX Compatible Protocol
NetBIOS support for IPX/SPX Compatible Protocol
File and Printer Sharing for Microsoft Networks
NOTE: Windows 95/98 does not automatically select a default protocol for you.
In the Properties section for the IPX/SPX Compatible Protocol verify that the following three options are selected:
- In the NetBIOS setup, check "I want to Enable NetBIOS over IPX/SPX" on the NetBIOS tab.
- In the Advanced setup, set the NetBIOS protocol as the default protocol.
- In the Bindings setup, choose all the components to communicate using the NetBIOS protocol.
You must then restart the computer for the new settings to take effect.
Both Windows NT and Windows 95/98 are NetBIOS type networks, so NIAKNETW.DLL must be enabled for NPL to function correctly. As of NPL Release V, NIAKNETW.DLL is enabled to run by default. However, for RunTimes prior to Release V enable the use of NIAKNETW.DLL, by adding the command
to the [GENERAL] section of either the local RTIWIN.INI file or the configured network RTIWIN.INI File.
The NPL Windows RunTime loads NIAKNETW.DLL at start-up (if it is not already present). Therefore, NIAKNETW.DLL must be locatable using the standard Windows DLL search procedure. For the simplest operation, ensure that NIAKNETW.DLL is in the same directory as the NPL Windows executables.
The Windows RunTime displays a small status window at the top of the screen with the caption "NiakNetW Monitor - Establishing NETBIOS interface" when authenticating over NetBIOS (using NIAKNETW.DLL). This feature was added because some NetBIOS operations effectively stop Windows for a number of seconds. The status window informs the user that the behavior is temporary, and that the workstation is not locked.
NIAKNETB.COM performs the same tasks for the DOS RunTime as NIAKNETW.DLL does for the Windows RunTime. To use NIAKNETB.COM, create a batch file. The first line of the batch file should load NIAKNETB.COM and the last line should unload it, as in the following example:
G:\BASIC2C\RTI /D30 FILENAME.OBJ
The message "NIAKNETB.COM installed using LANA 0" displays upon successfully loading NIAKNETB.COM. Similary, the message "Successfully Uninstalled" displays when the file is unloaded. If the file is not unloaded, an error message will be displayed when the DOS window closes.
Back to Top
Hardware Compatibility Issues
Multiple Monitor Support
Problems have been reported with the RunTime on a system utilizing multiple monitors under Windows 98. The workstations have a video adapter to display one window on one monitor and another window on the other monitor, from the same machine. However, after a few minutes the system crashes out with fatal video errors. Niakwa is currently investigating the problem, and will provide additional information as it becomes available.
Several users have reported various difficulties operating the RunTime with certain brands and types of network interface cards. Specifically, if a network card has a built-in "loopback" feature, duplicate #ID or $NETID values may be produced on networks that have multiple workstations using this same brand and model of network card. This "loopback" feature must be disabled using the driver or manufacturer utilities to generate a unique physical address. One reported configuration was the CompUSA branded OEM PCs with an on-board PCI network interface.
In addition, certain 3COM brand network cards have been associated with RunTime network problems, such as intermittent I90 errors, and RunTime "deadly embrace" conditions under Windows 95, 98, and NT. These 3COM network cards may contain a built-in self-diagnostic feature that activates at a set interval, temporarily disconnects the network, and self-tests the network interface. Evidence of its existence is a small 3COM icon in the System Tray, that when right-clicked, yields a Diagnostics option.
Although the test only lasts a split-second, repetitive NPL disk operations could cause the RunTime to fail in the event a disk request occurs at the exact moment the self-test is running. If the request involves a $OPEN (file lock), an I90 error will most likely occur. If the request involves a $CLOSE (file unlock), the unlock may fail (the file stays locked). Consequently, the RunTime would fall into a wait state upon the next $OPEN, either on the same workstation, or any other workstation attempting to lock the same file. In the latter case, the RunTime appears to hang, though pressing Alt-Tab or Ctrl-Esc allows navigation to other running tasks. This state is similar in behavior to what is known as a "deadly embrace", where a RunTime task waits indefinitely for a lock to be released.
3COM has identified that removal of the self-diagnostic feature eliminates the problem. For example, a newer revision of the 3C905B 10/100 PCI card, the 3C905C, does not have the problematic self-diagnostic in its driver. Owners of the 3C905B may upgrade the driver to use the 3C905C driver (which is backward compatible), to remove the diagnostic support. The previous driver must be removed from the system before installing the new driver. Contact 3COM or visit their website at http://www.3com.com for more information about a specific card model.
Back to Top
In the past, some developers hesitated to use the Windows RunTime because their application sent printer control codes to the printer. The Windows Print Manager stripped out these control codes and as a result, the developer had no control over the printing process. The release of Revision 4.22 resolved this problem through the "XPA=Y" option.
The "XPA=Y" clause permits printer control codes to be "passed through" the printer driver to the printer instead of being stripped out, as in the past. Most printer drivers support the "pass through" option, but not all.
The correct syntax to enable "Pass through control codes" is
$DEVICE(/000)=">(printer driver address) XPA=Y"
This of course must be entered in the device table.
Here's a handy trick to find the correct way to address the Windows printer driver.
- Make sure the printer is configured in Windows 95, 98 or NT.
- Write a small program
10 $DEVICE(/215)=">(?) SET=Y"
20 SELECT PRINT 215
30 PRINT "HELLO"
- Run this program using RTIWIN. A Windows printer selection box will pop up and allow you to select a printer.
- Select the printer you want to define and let it print. Don't exit the RunTime, but enter "LIST DT".
- Make a careful note of exactly how device 215 is listed.
- Enter that DEVICE definition into your program device table, and
- substitute XPA=Y for SET=Y.
As mentioned earlier, MOST printer drivers support the "pass through" option. If a particular printer driver doesn't support the "pass through" option a P-48 error occurs the first time you try to print to that device. In that case, configure the Windows "Generic text only" printer driver for that printer and use the "XPA=Y" option. After all, you are sending control codes to the printer anyway. If you get a double page feed at the end of the print job, change the "Paper" setting in the properties window of the Generic printer driver to "Continuous, No page break".
Here's a little tip for troubleshooting printer problems in the Windows runtime. Try setting the XPA=Y option, even if you're not sending control codes. It may help correct some line feed problems.
Back to Top
Bugs that could Affect the RunTime
Bug 1156 states: In a DOS / Windows environment, setting $OPTIONS byte 39 to HEX(01) to avoid implied opens causes incorrect data (from sector 0) to be returned if a program tries to access data on a locked diskimage (and must wait). This bug affected Revision 4.30.09 and 5.00.09 of the RunTime.
Workaround: If the HEX(02) bit in $OPTIONS byte 39 is set, the bug does not occur. So set $OPTIONS byte 39 to HEX(03).
Solution: Corrected on Revision 4.31.07 and 5.01.07.
Bug 1177 states: If a network printer is configured, but not captured (for use by DOS programs) under WIN98, accessing diskimages may result in lock violation errors. This bug affected Revision 5.00.09 of the RunTime.
Workaround: Change properties of all network printers to support a DOS capture address.
Solution: Corrected on Revision 5.01.07.
Bug 1183 states: If two programs (almost) simultaneously start up in a configuration that uses NIAKNETW communications, the RunTime should make one task wait, but it does not. This could potentially result in an unsuccessful startup, and reportedly a protection fault screen under Windows 98. This bug affected Revision 5.00.09 of the RunTime.
Solution: Corrected on Revision 5.01.07