Each transport that supports Windows Sockets applications supplies a user-mode Windows Sockets helper dynamic-link library to interpret network addresses and to process socket options in the architecture as outlined in Section 6.1.
For example, when any application calls socket, it specifies an address family, a socket type, and a protocol. These three arguments must uniquely identify a transport driver to support the socket. Windows Sockets searches for a match between these application-supplied arguments and the standardized configuration information stored in the registry for WSH DLLs. If it finds a match, Windows Sockets subsequently calls down through MSAFD to the WSHXxx functions exported by the WSH DLL as necessary. Otherwise, the application's call to socket fails.
When a match is found, Windows Sockets calls LoadLibrary on the WSH DLL, and then calls GetProcAddress to retrieve the entry point for each exported WSHXxx function. These WSHXxx functions are called whenever necessary to query for protocols supported by the helper DLL, to translate addresses, and to process WSH-supported options as getsockopt and setsockopt calls occur. For example, when an application passes an option to setsockopt that is not explicitly supported by Windows Sockets, the appropriate WSH DLL is called to process the option. The WSH DLL takes any necessary action to support each such option the corresponding transport supports.
The following conventions permit mechanical transformations between socket addresses, application-specified as SOCKADDR structures, and the TDI-defined addresses used by underlying transport drivers.