NDIS NIC and upper layer drivers use the NDIS library (ndis.sys) to communicate with each other, and to call operating system functions. When the operating system calls the NIC driver’s DriverEntry routine, the NIC driver calls NDIS to register its entry points and to obtain a handle representing the association between the driver and NDIS. In turn, NDIS calls the miniport NIC driver once for each NIC it supports.
When each protocol driver initializes, it calls NDIS to bind to a specified NIC. NDIS returns a handle for the resulting binding to the protocol driver. Once initialized, the protocol driver can submit requests to a given underlying NIC by calling the NIC driver functions through related NDIS library functions, specifying this binding handle. NDIS in turn, will pass the request to the appropriate NIC driver, using the handle representing the NDIS-NIC association.
To communicate with its remote-node peer, an NDIS protocol driver packages messages from an originating component (such as the redirector) into network data packets. The protocol driver then submits these packets by calling NDIS. Almost all NDIS function names have the prefix “Ndis...”, except for filter library functions. Functions that are exclusively called by miniport NIC drivers have the prefix “NdisM...”. Those called by NDIS intermediate drivers have the prefix “NdisIM...”.
“Upper-edge” or miniport function names are documented with a “Miniport” prefix. “Lower-edge” or protocol driver function names are documented with a “Protocol” prefix. All of the MiniportXxx and ProtocolXxx functions mentioned here are metanames: the NDIS-defined driver functions actually can have any names chosen by the driver writer as long as they have the required functionality.
To send a packet, NDIS functions call NIC driver upper-edge functions or possibly an intermediate NDIS driver such as a LAN emulation driver. If the call is passed to a NIC driver, the NIC driver prepares the packet for transmission on the network and queues it to be transmitted by an underlying NIC. If the packet is passed from a protocol driver to an NDIS intermediate driver that exports a LAN-miniport interface on its upper edge, the intermediate NDIS driver, which exports the native-media protocol interface at its lower edge, translates the packet to the underlying native-media format, and again calls NDIS to send the packet. This time, the packet is passed by NDIS to a NIC driver.
When a network packet arrives from a remote network node, the NIC captures the packet and signals its NIC driver. The NIC driver then calls the NDIS library which, in turn, calls an intermediate NDIS driver’s or a highest level protocol driver’s lower-edge functions to notify bound protocol drivers of the incoming packet and either pass the entire packet or subsequently transfer the packet data.
The requirements imposed on NDIS drivers dictate that they need to call, or be called by, various platform-specific operating system components. Some examples include:
The NDIS library provides NdisXxx functions that support all of these operations. When a driver needs operating system support, it calls NDIS functions that, in turn, can call kernel-mode support routines. When a NIC interrupts, the interrupt is passed to the NDIS library first. NDIS, in turn, calls the appropriate NIC driver’s MiniportISR function.
NDIS defines several hundred primitives used by the various NDIS components. The NDIS library can be thought of as the standard C library, providing a rich framework for writing NIC drivers. Only a small subset of these NDIS functions is likely to be called by any specific NIC or protocol driver.
NIC drivers are only required to implement a small number of functions. Miniport NIC drivers have a smaller number of NDIS-defined functions than legacy full NIC drivers.