NDIS Protocol Drivers (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
This section describes the features of an NDIS driver that exports a set of ProtocolXxx functions at its lower edge. Such a protocol driver communicates with NDIS to send and receive network packets. The protocol driver binds to an underlying miniport driver or intermediate driver that exports a MiniportXxx interface at its upper edge.
Note The miniport driver upper edge of an intermediate driver (virtual miniport) does not manage physical devices. Underlying miniport drivers manage physical devices.
Such an NDIS protocol driver might support TDI at its upper edge. It might also export a private interface to a higher-level kernel-mode driver, possibly through a transport stack of drivers, including one that supports TDI at the top of the stack. For instance, an NDIS protocol driver can be the lowest module of a multimodule transport implementation of a standard protocol such as TCP/IP with TDI support in the highest module.
Protocol drivers always use NDIS-provided functions to communicate with underlying NDIS drivers to send and receive packets. For example, a protocol driver that has a connectionless lower-edge (which communicates with underlying drivers for connectionless media, such as Ethernet or token ring) must call NdisSendor NdisSendPacketsto send packets to an underlying NDIS driver. The protocol driver must call NdisRequestto query or set OIDs that are supported by underlying connectionless drivers. A protocol driver that has a connection-oriented lower edge (which communicates with underlying drivers for connection-oriented media, such as ATM and ISDN) must call NdisCoSendPacketsto send a packet or packets to a lower-level NDIS driver. It must also call NdisCoRequestto query or set OIDs that are supported by underlying connection-oriented drivers.
NDIS also provides a set of NdisXxx functions that hide the details of the underlying operating system. For example, a protocol driver can call NdisInitializeEventto create an event for synchronization purposes and NdisInitializeListHeadto create a linked list. Protocol drivers that use the NDIS versions of such functions are more portable across Microsoft operating systems that support the Win32 interface. However, protocol drivers can also call kernel-mode support routines, such as IoCreateDevice. For more information, see Summary of Kernel-Mode Support Routines.
Developers of protocol drivers should use the same programming considerations that are applied to other NDIS drivers. See Network Driver Programming Considerations.
The following topics describe how to implement a protocol driver:
Protocol Driver's DriverEntry and Initialization
Protocol Driver Packet Management
Dynamic Binding in a Protocol Driver
Protocol Driver Query and Set Operations
Receiving Data in a Protocol Driver
Sending Protocol Driver-Originated Packets
Handling PnP Events and PM Events in a Protocol Driver
Protocol Driver Reset Operations
Status Indications in a Protocol Driver