Windows Dev Center

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.

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.

Because error codes are returned along with SPI functions, equivalents of WSAGetLastError and WSASetLastError are not required in the SPI.

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.

 

 

Community Additions

ADD
Show:
© 2015 Microsoft