Transport Mapping Between API and SPI Functions
The Winsock Transport SPI is similar to the Winsock API in that all of the basic socket functions appear. When a new version of a Winsock function and the original version both exist in the API, only the new version will show up in the SPI. This is illustrated in the following list.
- connect and WSAConnect both map to WSPConnect
- accept and WSAAccept map to WSPAccept
- socket and WSASocket map to WSPSocket
Other API functions that are collapsed into the enhanced versions in SPI include:
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.
The event object manipulation and wait functions, including WSACreateEvent, WSACloseEvent, WSASetEvent, WSAResetEvent, and WSAWaitForMultipleEvents are mapped directly to native Windows 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. For more information, see Compatible Name Resolution for TCP/IP in the Windows Sockets 1.1 SPI. Conversion functions such as inet_addr and inet_ntoa are implemented within the Ws2_32.dll.