9 Apr 1995
The Network Driver Interface Specification (NDIS) is a standard developed by Microsoft and 3Com and used by everyone in the computer industry other than Novell. NDIS is the network component used by the following packages:
Windows for Workgroups
Microsoft LAN Manager (DOS or OS/2 clients)
IBM LAN Server (DOS or OS/2 clients)
IBM TCP/IP for OS/2
Windows 95 (Chicago)
Using the NDIS support and the network client "redirector" program, DOS, Windows, Windows for Workgroups, OS/2, and NT systems can access file services from:
In addition, NDIS clients can access database services on Windows NT SQL Server and IBM DB/2 for OS/2, or they can use SNA programs to access mainframe or AS/400 machines through Windows NT SNA Server or IBM OS/2 Communications Manager.
There are two generations of NDIS software in current use. NDIS 2.x has been around for years. It reflects the old 16-bit architecture of DOS, Windows, and older OS/2. NDIS 3.x was introduced in Windows NT and is supported in Windows for Workgroups 3.11. It supports the 32-bit programming environment to which all systems are slowly migrating.
NDIS allows one machine to have several Ethernet adapters and/or run several communications protocols. It can run the NETBEUI protocol needed to use NT or OS/2 file machines as file or database servers. It can run the DLC protocol needed to run SNA sessions with a mainframe. It can run the TCP/IP protocol needed to access the Internet. There are also packages for DECNET, Appletalk, or OSI over NDIS. All of the protocols can operate at the same time on the same adapter(s).
NDIS software used to be distributed with Microsoft LAN Manager, IBM LAN Server, and IBM TCP/IP products. However, when Microsoft replaced LAN Manager with Windows NT, the client piece was made freely redistributable. This is the "New Microsoft Client" package.
The most current version of the Microsoft Client code is distributed on the CDROM that comes with Windows NT 3.5 Server. An older version of the package was on the network at ftp.microsoft.com, but it is not clear if it will be updated to match the latest code.
NDIS software has three components:
NDIS modules are loaded and configured automatically during the standard installation process for Windows for Workgroups, Windows NT, or Windows 95 (Chicago). In IBM's OS/2 operating system, a nearly identical configuration process is supported through the LAPS utility. Otherwise, NDIS will be configured as part of the installation of a Microsoft client package.
The NDIS components initialize in four steps:
By holding off, and performing the Binding function last, NDIS can tolerate a configuration that is slightly jiggled (say by loading some of the communications protocols before some of the Ethernet drivers).
A full set of network software takes up a significant amount of memory. Microsoft has changed the packaging of NDIS software over time to reduce the burden on the DOS 640K. In some cases, software is moved to Upper Memory Blocks. In other cases, it is moved to extended storage managed by Windows.
The installation and configuration of NDIS under DOS/Windows has evolved over time. There are four configurations in common use. Each represents an evolutionary refinement of the previous package. Given the hypertext capability of this document, it would have been possible to describe just the single configuration that matches a particular target system. However, many users end up "upgrading" from Plain Old Windows to Windows for Workgroups or from one release to another. For these users, it is helpful to be able to browse sequentially through the evolutionary tree and, therefore, to know what to expect from the "before" and "after." Hypertext links exist to skip forward if the other details are uninteresting. Read on, or select one of the following to jump:
"Classic" NDIS was implemented in early Microsoft DOS products. The need to move drivers from the famous 640K area into higher memory has forced Microsoft to use a few new underhanded tricks that mess up my documentation. Fortunately for those of us who teach, Classic NDIS is still supported by IBM in its OS/2 system (where the 640K limit doesn't apply). All of the NDIS components (Protocol Manager, MAC adapter card drivers, and protocols) are loaded as device drivers. A typical CONFIG.SYS contains statements such as:
The first statement loads PROTMAN. The second statement loads the Ethernet driver for the 3Com 3C503 Etherlink II adapter. The last statement loads the NETBEUI protocol that provides NETBIOS services for application programs and for the Redirector (the network file server client code).
After all the pieces have been loaded, the NETBIND.EXE program is loaded to trigger the "binding" process. In DOS, it is called with a statement in AUTOEXEC.BAT. In OS/2, it will be triggered with a RUN= statement in CONFIG.SYS. Binding connects the protocols (in this case NETBEUI) to the LAN drivers (in this case ELNKII) based on statements in the PROTOCOL.INI configuration file. As it happens, binding will generally be triggered if any other program tries to use LAN services before NETBIND is loaded. Therefore, it is not really an error if NETBIND is missing from AUTOEXEC.BAT as long as something else (such as "NET START" is there to trigger the binding anyway).(to skip the description of other NDIS configurations)
Microsoft now distributes a generic DOS client program through the Internet, on CompuServe, and on CD- ROM. This client is required because Windows NT and Windows NT Advanced Server do not come with DOS client code. The Protocol Manager and MAC adapter card driver are loaded as device drivers in CONFIG.SYS:
Unlike the "classic" NDIS, the Microsoft protocol drivers are not loaded in CONFIG.SYS. Instead, they are loaded by statements in AUTOEXEC.BAT. Presumably this allows more code to be placed in the Upper Memory Blocks.
net start workstation
Although Microsoft may choose to put the NETBEUI/NETBIOS driver in AUTOEXEC, this is not a restriction on other software. Other NDIS protocol modules (particularly the Packet Driver shim) can still load as device drivers.(to skip the description of other NDIS configurations).
Windows for Workgroups 3.1 was designed to move the Redirector and Server modules into Windows managed storage above the first megabyte. The Protocol Manager and MAC adapter card driver are loaded as device drivers from CONFIG.SYS. There is also an additional driver that provides the DOS-area resident component of the LAN functions.
AUTOEXEC.BAT calls the NET command to do minimal initialization. In reality, most of the NETBIOS and network code will be loaded after Windows starts.
Normally, DOS will not have use of the network server. However, the user can explicitly load the full network support package into DOS memory by issuing the "net start workstation" command after or in place of the simple "net start."(to skip the description of other NDIS configurations).
Windows for Workgroups 3.11 permits new 32-bit LAN support modules to run in Windows. Technically, such MAC adapter card drivers and protocol modules are said to follow the NDIS 3.0 specification. CONFIG.SYS contains only a single statement that serves as a placeholder:
AUTOEXEC contains a statement to call the \WINDOWS\NET.EXE program. NET will either do nothing, or it will load all kinds of programs depending on the environment.
NET examines \WINDOWS\SYSTEM.INI to determine if all the network code is based on the new 32-bit standard. If so, then the loading of network support is deferred till Windows starts up. However, WFWG 3.11 supports old NDIS 2.0 LAN adapter drivers, and it supports old protocol modules. Since this old code cannot run in Windows memory, if there is are any old "Real Mode" drivers then WFWG 3.11 is going to have to load a bunch of code into the DOS area to create the same control blocks and linkage used by all the previous versions of NDIS.
A WFWG 3.11 user can add Internet support in one of two ways. Microsoft has its own 32-bit TCP/IP package commonly known by its code name "Wolverine". It is available from ftp.microsoft.com and is distributed on the CD with the other client code for Windows NT 3.5 Server. This code runs entirely in the Windows memory area (above the 640K). It supports WINSOCK applications and TCP/IP access to NT file servers. Generally, a copy of this code is placed on a file server. The user then accesses the disk directory, and from the Windows Program Manager runs SETUP.
Wolverine adds an additional 32-bit VxD component to the WFWG 3.11 environment. Changes are automatically made to the SYSTEM.INI file. The user is not required to edit datasets. If a Windows NT 3.5 Server is available and has been configured as a DHCP server, then the TCP/IP configuration can be done automatically. This is by far the simplest method of upgrade. The only limitation is that Wolverine does not support dial-in modem access. There are a few applications that are reported to have trouble with the Wolverine code.
It is also possible to install a good old Packet Driver into the WFWG 3.11 environment and run Trumpet WINSOCK on top of it. Trumpet may provide a more reliable environment for certain shareware programs that are typically tested using it. Trumpet also provides dial-in modem connections and may be a better choice on a laptop computer that is sometimes connected to the LAN and sometimes off on the road. However, the Packet Driver is an old 16-bit Real Mode protocol and it will force WFWG 3.11 to load some of the older, less efficient, Real Mode drivers. Details will be provided below.
WEBTOOLS supplies a copy of the Packet Driver module that provides an interface to NDIS. The program is called DIS_PKT.DOS. In any of the NDIS 2 configurations:
For Classic NDIS (old LANMAN or IBM clients)
For current Microsoft Clients
For WFWG 3.1
DIS_PKT.DOS is loaded by adding a DEVICE statement to CONFIG.SYS. In the following example, the first two statements were originally present and the third statement is added:
Note: this DEVICE statement is used even when the Microsoft LAN protocol software (NETBEUI) is loaded directly or indirectly by statements in AUTOEXEC. DIS_PKT is designed to load as a device driver.
Now proceed toupdate PROTOCOL.INI .
For WFWG 3.11, DIS_PKT must be loaded by changing statements in \WINDOWS\SYSTEM.INI. Toward the end of that file, there will be a [network drivers] section. It may have statements that look like this:
The "netcard=elnk3.dos" is present because, in this example, the 3C509 card had no 32-bit NDIS 3.0 driver. An older 16-bit NDIS 2.0 driver was used instead. So even if there are no Real Mode protocol drivers, the presence of a 16-bit adapter driver forces WFWG 3.11 to load some stuff in the DOS area.
To support the Packet Driver shim, the LoadRMDrivers (Load Real Mode Drivers) is set to Yes and the DIS_PKT.DOS is added to the "transport" list.
Put DIS_PKT.DOS in the \WINDOWS directory with all the other protocol modules. Now proceed to edit PROTOCOL.INI.
Whether DIS_PKT is added with a DEVICE statement or in SYSTEM.INI, it must be configured by adding a block of statements to PROTOCOL.INI, a file that resides either in LANMAN.DOS (LAN Client) or in \WINDOWS (either release of WFWG):
The [PKTDRV] section defines parameters for the Packet Driver. The "PKTDRV$" name is a character string built into the DIS_PKT program that makes it possible for the other programs (such as the Trumpet WINSOCK TCP/IP package) to find DIS_PKT once DOS is running. The important parameters, that may need consideration, are found in the next two statements.
BINDINGS indicates which Ethernet adapter card the Packet Driver should use. It will match the name of another section somewhere in PROTOCOL.INI, where the hardware parameters (if any) for the Ethernet adapter driver are stored. More importantly, the correct value for BINDINGS that you add to the [PKTDRV] section will match the value in any other protocol configuration. The purpose of BINDINGS is to control which protocols use which adapters when there are several Ethernet boards in the same machine. In normal use, however, there is only one board and so all BINDINGS statements are identical.
For example, the existing statements in PROTOCOL.INI could include:
The first [MS$NE2CLONE] section would include whatever parameters (address, interrupt, etc.) needed to define what is probably an NE2000 clone board. The definition of the NETBEUI protocol then includes a BINDINGS statement referencing the adapter definition section. In this case, the correct statement in the [PKTDRV] section would also be BINDINGS=MS$NE2CLONE.
The INTVEC statement identifies a software Interrupt number that other programs will use to make requests from the Packet Driver. DOS reserves the interrupt numbers starting at 0x60 for packages and products. The best choice is to use 0x60, unless that number is already being used by another program for some other purpose.
Reboot the computer. DIS_PKT.DOS should print out a message indicating that it was loaded. If it complains that it was not able to "bind" to a LAN card, then PROTOCOL.INI was not correctly updated.Continue Back PCLT
Copyright 1995 PC Lube and Tune -- Windows on the World -- H. Gilbert