Mappage de transport entre les fonctions API et SPI

Le SPI de transport Winsock est similaire à l’API Winsock en ce que toutes les fonctions de base de socket apparaissent. Lorsqu’une nouvelle version d’une fonction Winsock et la version d’origine existent toutes les deux dans l’API, seule la nouvelle version s’affiche dans l’index SPI. Cela est illustré dans la liste suivante.

Les autres fonctions d’API qui sont réduites dans les versions améliorées dans SPI sont les suivantes :

Les fonctions de prise en charge telles que htonl, htons, ntohlet ntohs sont implémentées dans la _32.dll Ws2 et ne sont pas transmises aux fournisseurs de services. Il en va de même pour les versions WSA de ces fonctions.

Windows L’énumération des fournisseurs de services de sockets et les fonctions associées au hook de blocage sont réalisées dans la _32.dll Ws2. par conséquent, WSAEnumProtocols, WSAIsBlocking, WSASetBlockingHooket WSAUNHOOKBLOCKINGHOOK n’apparaissent pas en tant que fonctions SPI.

Étant donné que les codes d’erreur sont retournés avec les fonctions SPI, les équivalents de WSAGetLastError et WSASetLastError ne sont pas requis dans le SPI.

la manipulation d’objet d’événement et les fonctions d’attente, notamment WSACreateEvent, WSACloseEvent, WSASetEvent, WSAResetEventet WSAWaitForMultipleEvents , sont mappées directement aux services Windows natifs et ne sont donc pas présentes dans le SPI.

toutes les fonctions de conversion et de résolution de noms propres à TCP/IP dans Windows sockets 1,1, telles que GetXbyY, WSAAsyncGetXByY et WSACancelAsyncRequest, ainsi que gethostname sont implémentées dans le _32.dll Ws2 en termes de nouvelles fonctions de résolution de noms. pour plus d’informations, consultez résolution de noms Compatible pour TCP/IP dans le SPI Windows sockets 1,1. Les fonctions de conversion telles que inet _ addr et inet _ NTOA sont implémentées dans le _32.dll Ws2.