Banyan NDIS Configuration Guide
Chapter 1 - A Short History of NDIS
The Network Driver Interface Specification (NDIS) is a standardized interface for OS/2 or DOS network platforms. NDIS provides access to network services at the Data link layer and is especially useful if the access must be shared. Software developers who need to employ their own network protocol implementations can program to the NDIS interface and use NDIS-compliant drivers provided by network hardware vendors. This frees the protocol developer from programming directly to various network interface cards and solves compatibility problems on machines with multiple protocols.
Traditional Data Link Technology
Traditionally, network software vendors for the DOS environment have used ad hoc methods to implement the protocols and drivers that link applications to their resident network hardware. The entity that performs these network functions and provides communication between applications is usually referred to as a protocol stack. In the OSI Reference Model, the stack would correspond to the Data link, Network, Transport, and Session layers, with some stacks possibly including higher layers.
At the stack's top end is a user interface or some type of application programming interface (API). At the bottom end are the interfacing routines that control the network adapter hardware. In implementation, a stack might consist of one system driver, multiple drivers, a program, or a combination of drivers and programs.
In a typical implementation, the Data link, Network, and Transport layers might be implemented as three separate system drivers, and the Session layer as a TSR program.
Usually, communication between layers is accomplished through a proprietary interface developed by the vendor. In Figure 1-1, the application communicates to BAN and the lower-level protocols communicate through software interrupts. This works well in a homogeneous network environment, but as networks grow more complex, network programmers and users need the flexibility to use mixtures of different protocols, application interfaces, and network media.
Compatibility issues between various networking implementations can make it difficult or impossible to accomplish some seemingly simple tasks.
Example Problem with Native Drivers
Suppose you are running two protocol stacks simultaneously in a workstation, and your workstation is installed on an Ethernet network that has two types of file servers attached. Figure 1-2 shows one possible configuration.
You want to write a program to run on the workstation that can copy a file from the NetWare server to the VINES server.
You have the following hardware and software:
Two protocol stacks that are designed to communicate with each of the servers: one for VINES and one for NetWare. A programmer's interface on each protocol stack that allows you to write a program which talks to the two stacks. Enough workstation memory to load both stacks simultaneously. A driver supplied with each protocol stack that controls the EtherLink® II adapter board in the workstation.
The most significant configuration problem occurs at the bottom of the stacks. Each of the LAN drivers expects to have exclusive ownership and control of the EtherLink II adapter board. As one of the drivers tries to control the board, it interrupts or corrupts the functions being attempted by the other driver.
NDIS solves this problem by allowing one LAN driver to control the LAN card and arbitrate between protocol stacks that are competing for the card.
In May of 1988, 3Com and Microsoft released NDIS, which was jointly developed in conjunction with LAN Manager. NDIS is a standard designed to alleviate compatibility issues for both OS/2 and DOS network platforms. NDIS is designed to benefit the protocol-level network software developer, who now has a standard interface available, and the user, who gains flexibility and interoperability advantages of the protocols using NDIS.
When VINES was planned in the early 1980s, one of the design criteria was to create the fastest network operating system on the market at that time. To accomplish this goal, Banyan Systems developed native mode drivers for LAN cards and peripheral devices, integrating them into the VINES kernel for better manageability and improved speed.
At that time, the number of adapter companies was small. This allowed Banyan to work directly with the industry leaders (IBM, Western Digital, 3Com, among others) to ensure that the popular adapters were supported.
Today, with a dramatically changing industry, many LAN adapter vendors have emerged. Banyan has had driver requests from over 120 LAN card manufacturers requesting support for their products.
Because of the methods used to develop drivers and the architecture of our products, Banyan was required to engineer all drivers to ensure that adapters function properly and perform well with VINES. This process delayed the introduction of drivers and placed both Banyan, the LAN adapter vendors, and Banyan customers at a disadvantage.
NDIS as a Client-driver Solution
As Banyan finalized the release of VINES 5.5x, which included enhancements to NDIS support, it became apparent that a fully functional, high performance NDIS implementation would help solve Banyan's client-driver dilemma. This improved NDIS support found in VINES 5.5 includes:
Enhanced performance and memory usage Support for Ethernet, Token-Ring, and ARCNET for DOS Support for Ethernet and Token-Ring for OS/2 Ability to load NDIS drivers into high memory
With NDIS providing a current client-side solution, Banyan can now concentrate on improving other aspects of its products.
