| Platform SDK: Windows Sockets |
The Windows Sockets Transport SPI is similar to the Windows Sockets API in that all of the basic socket functions appear. When a new Windows Sockets 2 version of a function and the original Windows Sockets 1.1 version of a function both exist in the API, only the new version will show up in the SPI. For example:
Other API functions that are collapsed into the enhanced versions in SPI include:
Support functions like htonl, htons, ntohl, and ntohs are implemented in the Ws2_32.dll, and are not passed down to service providers. The same holds true for the WSA versions of these functions.
Windows Sockets service provider enumeration and the blocking hook-related functions are realized in the Ws2_32.dll, thus WSAEnumProtocols, WSAIsBlocking, WSASetBlockingHook, and WSAUnhookBlockingHook do not appear as SPI functions.
Since error codes are returned along with SPI functions, equivalents of WSAGetLastError and WSASetLastError are not needed in the SPI.
The event object manipulation and wait functions including WSACreateEvent, WSACloseEvent, WSASetEvent, WSAResetEvent, and WSAWaitForMultipleEvents are mapped directly to native OS services and thus are not present in the SPI.
All the TCP/IP-specific name conversion and resolution functions in Windows Sockets 1.1 such as getXbyY, WSAAsyncGetXByY and WSACancelAsyncRequest, as well as gethostname are implemented within the Ws2_32.dll in terms of the new name resolution facilities. See Windows Sockets 1.1 Compatible Name Resolution for TCP/IP for details. Conversion functions such as inet_addr and inet_ntoa are implemented within the Ws2_32.dll.