The key to transport-independent Windows Sockets support in Windows NT is a common kernel-mode transport interface called Transport Device Interface, or TDI for short. All of the networking components of Windows NT go through TDI to access a transport protocol's services. TDI abstracts key differences between protocols, such as the format of transport addresses, and provides common entry points for typical transport features like sending data.
Networking architecture of Windows NT
All the kernel-mode networking components of Windows NT use the TDI interface to speak to the transport layers below them. This use of a common interface allows easy addition or removal of transport protocols, since each transport protocol is completely separated from the layers which use it; in fact, each transport is packaged as a separate driver file.
However, TDI is not the only kernel-mode transport interface available in Windows NT. There is also the Streams interface, which is based on the AT&T® SVR4 Streams environment. Streams is useful for porting existing transport protocols to Windows NT quickly and easily. However, it does impose a performance overhead on all transactions, since there is a mapping layer between the TDI calls made by upper layers and the internal interfaces used by Streams. The TCP/IP and IPX/SPX transport protocols supplied with the original release of Windows NT existed in the Streams environment, but Daytona, the next release of Windows NT, will include native TDI implementations of these transport protocols for improved performance.
The use of TDI as the interface underneath Windows Sockets solves most of the issues with multiple transport support, but some additional issues do remain. For example, because each transport protocol uses a different address format, how could Windows Sockets know which addresses are broadcast addresses? How can the Windows Sockets DLL know which transport device name corresponds to a given type of socket? And how can transports supply their own unique socket options like TCP/IP's SO_DONTROUTE option?
The answer is the use of user-mode "helper DLLs" which the Windows Sockets DLL (WSOCK32.DLL) uses for carefully defined functionality. Each of the TDI transport protocols exposed through Windows Sockets supplies one of these helper DLLs as well as placing information in Windows NT's registry about where to find the helper DLLs and what sorts of sockets each supports. The Windows Sockets DLL then calls into the helper DLL's entry points to learn about the format of transport addresses, to process transport-specific socket options, and more.
Windows Sockets architecture of Windows NT
In addition to 32-bit Windows Sockets applications supported through WSOCK32.DLL, Windows NT also supports 16-bit Windows Sockets applications through the file WINSOCK.DLL. This file is composed of minimal entry points which call into Windows NT's "WOW" (Windows-on-Windows) subsystem, which widens the parameters to 32-bits and calls into WSOCK32.DLL for the actual networking support. Thus, WINSOCK.DLL acts as a "thunking layer" between 16-bit applications and the rest of the operating system, which is all 32-bit.