Every TDI transport driver must provide an initialization routine explicitly named DriverEntry. In addition, a transport driver should have as many TdiDispatchXxx routines and internal driver functions as it needs to satisfy the requests of its kernel-mode clients. A TDI transport driver or one of the underlying protocol drivers in its transport stack also must provide the NDIS driver lower-edge functions described earlier in -Chapter 2 and in the Network Driver Reference.
Every transport driver must have a DriverEntry routine to be called by the I/O Manager when the transport is loaded. DriverEntry must be declared in the driver code to make the transport automatically loadable.
When it loads the driver, the Windows NT I/O Manger creates a driver object to represent the transport and passes a pointer to the driver object when it calls DriverEntry. The transport’s DriverEntry routine does the following:
Some transport drivers, such as NWLink, create only one named device object no matter how many NICs they bind themselves to. Other transport drivers create a separate named device object for each bound NIC, such as Nbf_Elnkii1, Nbf_Elnkii2, and so forth.
Any TDI transport driver must provide an Unload routine unless that driver cannot be unloaded without rendering the system unusable. Most TDI transport drivers declare an Unload routine, and their DriverEntry routines set its entry point in the driver object. For more information about transport Unload routines, see Section 4.1.2.
For more information about the kernel-mode support routines and objects used by TDI drivers, see the Kernel-mode Driver Reference.