Warum hat Microsoft Sockets anders implementiert?

Question

Ich bin gerade mitten in einem Projekt mit Sockets, und ich verwende nur Linux sys/socket.h Datei. Rufen Sie Microsoft den Port zu und erkennen Sie, dass Winsock anders ist. Ich denke, ich habe zwei Fragen.

Erstens, was sind die Hauptunterschiede zwischen den beiden Implementierungen? Gibt es einen einfachen Weg, sie zu "übersetzen"? Ein Link zu einem Leitfaden wäre sehr zu begrüßen, da Sie mir wahrscheinlich bessere Links als Google verschaffen können.

Zweitens, warum hat Microsoft das getan? Was war ihre Motivation? Warum haben sie nicht dieselbe Implementierung wie alle anderen beibehalten?

Answer 1

Verzeihen Sie, wenn ich den Punkt verpasst habe, aber betrachten Sie WSARecv und Familie, und denken, dass die gesamte Sockets-API auf Windows ist anders als die Berkeley Sockets API?

Die Berkeley-API existiert unter Windows (siehe recv und Familie) und ist weitgehend kompatibel mit anderen Berkeley Sockets-Implementierungen.

Informationen zum Portieren von Sockets-Code in Windows finden Sie im MSDN-Artikel "Porting Socket Applications to Winsock".

Answer 2

Verwenden Sie ACE - es ist eine großartige Cross-Plattform-Kommunikationsbibliothek.

Answer 3

Milen sagte es in einem Kommentar, aber die Apache Portable Runtime Bibliothek deckt viele der Portabilitätsprobleme für die vernetzte Anwendung.

Answer 4

Die Winsock Programmer's FAQ hat einen Abschnitt über diese, BSD Sockets Compatibility. (Disclosure: Ich bin der Betreuer FAQ.)

ich nicht wirklich, wie und warum in diesem Artikel deckte, so:

• winsock.h vs sys/socket.h, arpa /inet.h, netinet/in.h usw.: Das finde ich eigentlich eine Verbesserung. Es ist alles eine enge Reihe von Funktionen, warum also nicht alle Definitionen dafür in einem einzigen Header?

• close() vs. Close(): Zurück in den 3 Tagen von Windows, wenn Winsock wurde erfunden, Windows-C++ Compiler alle eine Art von POSIX-API-Wrapper hatte einige grundlegende Ebene der Tragbarkeit zu schaffen, in der Nähe, einschließlich() . Diese wurden nur in der stdio-Implementierung des Compilers aufgerufen, da DOS und Win16 keinen einheitlichen I/O-Mechanismus wie Unices haben. Man kann nicht einfach close() auf einen Deskriptor in Win16 aufrufen und es funktioniert unabhängig davon, ob es eine Datei, ein Socket, eine Pipe oder was auch immer ist. Win32 existierte zur selben Zeit, als Winsock als Teil von NT 3.5 erfunden wurde, und es behebt dies, aber Winsock nur für NT-Derivate verfügbar zu machen, hätte MS im Internet bis Windows XP irrelevant gemacht. MS kann langsam zum Spiel sein, aber nicht , dass langsam. Bottom Line, alles in BSD-Sockets, die POSIX-Mechanismen verwendet, die mit vorhandenen APIs kollidierten, die von den C++ - Compilern zur Verfügung gestellt wurden, die darauf abzielten, konnten sich nicht in Winsock befinden. Sie mussten der gleichen Funktionalität einen neuen Namen geben.

• WSA *(): Dies ist nur zusätzliche Funktionalität, die Funktionalität, die BSD-Sockets nicht bietet. Vieles ist wirklich nett, und es wäre schön, ähnliche Mechanismen in allen Unis zu sehen, aber das wird in absehbarer Zeit nicht passieren. Es gibt konkurrierende Mechanismen, wie aio *(), aber das ist nicht über alle Unices verfügbar, viel weniger portabel zu Windows.Sie können es einfach ignorieren und bleiben bei den Sockets-APIs, obwohl dies nicht immer die beste Wahl für die Portierung auf Windows ist.

• errno vs. WSAGetLastError(): errno ist Teil von Standard C, aber die Fehlerwerte sind bis zur C-Implementierung. Denken Sie daran, dass Winsock am Anfang keine Microsoft-spezifische Sache war. DOS und Windows haben nicht mit Standard-Netzwerk-APIs begonnen. Dies wurde von Dritten zur Verfügung gestellt, die alle zusammen kamen und Winsock erfanden, an dem Microsoft beteiligt war. Die anfänglichen Winsock-Stapel waren alle von Drittanbietern. Sie konnten aus verschiedenen Gründen die Spezifikation nicht schreiben, um den errno-Wert des C RTL zu überschreiben. Diese Fehlerwerte gehörten zu der vom Hersteller bereitgestellten winsock.dll, eine ganz andere Welt als die C RTL.

• WSAStartup(), WSACleanup(): Auch dies ist aufgrund der Tatsache, dass winsock.dll war ursprünglich ein Dritte Sache zur Verfügung gestellt, die mit einigem zugrunde liegenden Netzwerk-Stack einer Schnittstelle, die nicht Teil des OS ist . Außerdem gibt es den Win16-Aspekt der Dinge: Win16 konnte nicht sehen, dass ein Programm gerade gestorben ist und seine zugewiesenen Ressourcen automatisch bereinigt. Sie mussten alles explizit freigeben, bevor das Programm beendet wurde, oder sie wurden durchgesickert.

• Mangel an readv(), etc.: Dies machte keinen Sinn in der Drittpartei/Win16 Welt, wo Winsock geboren wurde.