Pourquoi Microsoft a-t-il mis en œuvre des prises différentes différemment?

Essayez d'utiliser ACE - C'est une grande bibliothèque de communications multiples plate-forme. .

MILEN l'a dit dans un commentaire, mais le Apache Portable Runtime Bibliothèque couvre bon nombre des problèmes de portabilité pour Application en réseau.

Le FAQ de programmeur Winsock a une section sur cette section, Sockets BSD Compatibilité . (Divulgation: Je suis le responsable de la FAQ.)

Je n'ai pas vraiment couvrant les Whays et les montants dans cet article, donc:

• winsock.h vs sys / socket.h, arpa / inet.h, neinet / in.h, etc. : cela je trouve réellement une amélioration. C'est tout un jeu de fonctionnalités serré, alors pourquoi ne pas avoir toutes les définitions de celui-ci dans une seule tête?

• Fermer () vs Closesocket () : retour dans les fenêtres 3 jours lorsque Winsock a été inventé, les compilateurs de Windows C ++ ont tous eu une sorte de wrapper POSIX d'API pour fournir un niveau de base de portabilité, y compris près (). Celles-ci s'appellent simplement dans la mise en œuvre de STDIO du compilateur, puisque DOS et Win16 n'avaient pas un mécanisme d'E / S unifié comme les unes. Vous ne pouvez pas simplement appeler fermer () sur un descripteur de Win16 et le faire fonctionner de manière indépendante de savoir s'il s'agit d'un fichier, d'une prise, d'un tuyau, d'une autre. Win32 existait en même temps que Winsock était inventé dans le cadre de la NT 3.5, et cela la corrige, mais la fabrication de Winsock disponible uniquement sur les dérivés NT n'aurait fait que MM non dénuée sur Internet jusqu'à Windows XP. MS peut être lent au jeu, mais pas que lent. En bout de ligne, tout ce qui est dans les sockets BSD utilisant des mécanismes de POSIX qui en conflit avec les API existantes fournies par les compilateurs C ++ qui la ciblaient ne pouvaient tout simplement pas être dans Winsock. Ils ont dû donner la même fonctionnalité un nouveau nom.

• WSA * () : Il s'agit simplement de fonctionnalités supplémentaires, fournissant des fonctionnalités que les sockets BSD ne le font pas. Beaucoup de choses sont vraiment sympas et ce serait bien de voir des mécanismes similaires sur tous les unes, mais cela ne se produira pas de temps bientôt. Il existe des mécanismes concurrents, tels que AIO * () , mais ce qui n'est pas disponible sur tous les unes, beaucoup moins portable pour Windows. Vous pouvez simplement l'ignorer et rester dans les API des prises de base, bien que ce n'est pas toujours le meilleur choix lors du portage vers Windows.

• errno vs wsagetlasterror () : errno fait partie de la norme C, mais les valeurs d'erreur sont jusqu'à la mise en œuvre C. Gardez à l'esprit que Winsock au début n'était pas une chose spécifique à Microsoft. DOS et Windows n'ont pas démarré avec des API réseau standard. Cela a été fourni par des tiers, qui se sont tous réunis et ont inventé Winsock, avec Microsoft impliquée. Les piles de Winsock initiales étaient toutes tierces. Ils ne pouvaient pas écrire la spécification pour écraser la valeur errno de C RTL, pour plusieurs raisons. Ces valeurs d'erreur appartenaient au fournisseur fourni winsock.dll, tout un monde différent du C RTL.

• wsarstartup (), wsacleanup () : Encore une fois, cela est dû au fait que winsock.dll était initialement une troisième partie fournie, qui a interfacé avec une pile de réseau sous-jacente qui Partie du système d'exploitation. En outre, il y a l'aspect Win16 des choses: Win16 n'a pas pu voir qu'un programme vient de décéder et de nettoyer ses ressources allouées automatiquement. Vous avez dû libérer explicitement tout avant la sortie du programme, sinon ils seraient fui.

• manque de lecture de lecture (), etc