NIC and transport drivers complying with NDIS 3.0 use the NDIS interface library (NDIS.SYS) to access each other, and to access operating system functions. At initialization, when the operating system calls the NIC driver's initialization (DriverEntry) routine, the NIC driver calls the NDIS library (often referred to as the wrapper in earlier documentation) to register itself and each of its NICs. Each transport driver, within its initialization routine, then calls the NDIS library to bind to a specified NIC. The NDIS library returns a handle to the resulting binding. After this, the transport driver can submit requests to a given network interface card by calling the NIC driver functions through related NDIS library functions, specifying this binding handle.
To communicate with its remote node peer, a transport driver packages messages from upper layer components (such as the redirector) into network data packets. It then submits these packets to the NIC driver using calls to the NDIS library. Note that almost all NDIS library function names are prefaced with "Ndis...". Functions that are exclusively used by miniport NIC drivers are prefaced with "NdisM...".
The NDIS library calls NIC driver upper-edge functions, which prepare the packet for transmission on the network and queue it to be transmitted by an underlying NIC. NIC driver function names are prefaced with "Miniport..." or "Mac..." (depending on the type of NIC driver).
When a network packet arrives from a remote network node, the NIC captures the packet and signals the local NIC driver. The NIC driver then calls to the NDIS library which, in turn, calls transport driver lower-edge functions to notify bound transport drivers of the incoming packet and subsequently transfer the packet data. Transport driver function names are prefaced with "Protocol...".
The function of NIC and transport drivers dictate that they need to call, or be called by, various platform-specific operating system components. Some examples include:
·when a driver needs a buffer, it must ask the operating system to allocate memory.
·when a NIC driver is ready to transmit a packet, it might use programmed I/O to communicate with the appropriate NIC and, if needed, transfer the packet from system memory to the NIC's transmit buffer.
·after a packet is received by the NIC, the NIC will generate a hardware interrupt to pass control to the NIC driver.
The NDIS library provides functions that support all of these operations. When a driver needs operating system support, it calls NDIS library functions which, on Windows NT, call kernel executive APIs. When the NIC imposes a hardware interrupt, control goes to the NDIS library which, in turn, calls NIC driver upper-edge functions.
The NDIS library also includes a special Filter Library with which a set of NIC driver upper-edge Action functions are associated. The filter libraries provide a framework where a transport driver can specify destination addresses or address types of packets it is interested in receiving. Thereafter, each incoming packet will be routed to one, multiple or all bound transport drivers based on the packet's destination address.
NDIS 3 defines several hundred primitives used by the various NDIS components. The NDIS interface library can be thought of like the standard C library, providing a rich framework for writing NIC drivers. Only a small subset of these NDIS library functions needs be be used by a specific NIC or transport driver.
NIC drivers must provide only a small number of functions. Miniport NIC drivers export 13 functions, while the older-style full NIC drivers, being more complicated and difficult to write, must provide 21 functions.