See Also
 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
The Windows Sockets Transport SPI is similar to the Windows Sockets API in that all of the basic socket functions appear. When a new Winsock 2.2 version of a function and the original Winsock 1.1 version of a function both exist in the API, only the new version will show up in the SPI, as shown in the following examples:
-
Connectand
WSAConnectboth map to
WSPConnect
-
Acceptand
WSAAcceptmap
to
WSPAccept
-
Socketand
WSASocketmap
to
WSPSocket
The following list shows other functions that are collapsed into the enhanced versions in SPI:
Support functions like htonl, htons, ntohl, and ntohsare implemented in Ws2.dll, and are not passed down to service providers. The same holds true for the WSA versions of these functions.
Because error codes are returned along with SPI functions, equivalents of WSAGetLastErrorand WSASetLastErrorare not needed in the SPI.
The event object manipulation and wait functions including WSACreateEvent, WSACloseEvent, WSASetEvent, and WSAResetEventare mapped directly to native OS services and thus are not present in the SPI.
The TCP/IP-specific name conversion and resolution functions ,such as getXbyYas well as gethostnameare implemented within Ws2.dll in terms of the new name resolution facilities. Conversion functions, such as inet_addrand inet_ntoa, are implemented within Ws2.dll.