Perché Microsoft ha implementato i socket in modo diverso?

Question

Sono attualmente nel bel mezzo di un progetto che coinvolge socket e uso solo il file sys/socket.h di Linux. Indirizza la porta a Microsoft e renditi conto che Winsock è diverso. Credo di avere due domande.

In primo luogo, quali sono le principali differenze tra le due implementazioni? C'è un modo semplice per "tradurli"? Un link a una guida sarebbe molto apprezzato, perché voi probabilmente potete ottenere link di qualità migliore di Google.

In secondo luogo, perché Microsoft ha fatto questo? Qual era la loro motivazione? Perché non hanno solo mantenuto la stessa implementazione di tutti gli altri?

Answer 1

Perdonami se ho perso il punto, ma stai guardando WSARecv e la famiglia, e il pensiero che l'API interi prese su Windows è diverso dal API Berkeley Sockets?

L'API Berkeley esiste su Windows (vedere recv e famiglia) ed è ampiamente compatibile con qualsiasi altra implementazione di Berkeley Sockets.

Vedere l'articolo MSDN "Porting Socket Applications to Winsock" per informazioni sul porting di codice socket su Windows.

Answer 2

Provare a utilizzare ACE - è una grande libreria di comunicazioni multipiattaforma.

Answer 3

Milen ha detto in un commento, ma la libreria Apache Portable Runtime copre molti dei problemi di portabilità per l'applicazione in rete.

Answer 4

Il Winsock Programmer's FAQ ha una sezione su questo, BSD Sockets Compatibility. (Disclosure: io sono manutentore le FAQ.)

Non ho davvero coprire il perché e il percome di questo articolo, in modo da:

• winsock.h vs sys/socket.h, ARPA /inet.h, netinet/in.h, ecc.: in realtà trovo un miglioramento. È tutto un insieme ristretto di funzionalità, quindi perché non avere tutte le definizioni per esso in una singola intestazione?

• close() vs. closesocket(): Back in the Windows 3 giorni in cui Winsock è stato inventato, compilatori di Windows C++ tutti ha avuto un qualche tipo di POSIX wrapper API per fornire un certo livello di base della portabilità, tra close() . Questi hanno appena richiamato l'implementazione stdio del compilatore, dal momento che DOS e Win16 non avevano un meccanismo I/O unificato come gli Unice. Non puoi semplicemente chiamare close() su un descrittore in Win16 e farlo funzionare indipendentemente dal fatto che si tratti di un file, un socket, un pipe o altro. Win32 esisteva nello stesso momento in cui Winsock veniva inventato come parte di NT 3.5 e lo risolve, ma rendere Winsock disponibile solo su derivati ​​NT avrebbe reso MS irrilevante su Internet fino a Windows XP. MS può essere lento al gioco, ma non quello lento. In conclusione, qualsiasi cosa nei socket BSD che utilizza meccanismi POSIX in conflitto con le API esistenti fornite dai compilatori C++ che lo avevano preso come bersaglio non poteva essere in Winsock. Dovevano dare alla stessa funzionalità un nuovo nome.

• WSA *(): questa è solo una funzionalità aggiunta, che fornisce funzionalità che i socket BSD no. Molto è bello, e sarebbe bello vedere meccanismi simili su tutti gli Unices, ma non succederà presto. Esistono meccanismi concorrenti, come aio *(), ma questo non è disponibile su tutti gli Unix, molto meno portabile a Windows.Si può semplicemente ignorarlo e attenersi alle API dei socket di base, anche se questa non è sempre la scelta migliore quando si esegue il porting su Windows.

• errno rispetto a WSAGetLastError(): errno fa parte di Standard C, ma i valori di errore sono fino all'implementazione C. Tieni presente che all'inizio Winsock non era una cosa specifica per Microsoft. DOS e Windows non hanno iniziato ad avere API di rete standard. Questo è stato fornito da terze parti, che si sono riunite tutte insieme e hanno inventato Winsock, coinvolgendo Microsoft. Gli stack iniziali di Winsock erano tutti di terze parti. Non potevano scrivere le specifiche per sovrascrivere il valore errno di C RTL, per diversi motivi. Questi valori di errore appartenevano al winsock.dll fornito dal fornitore, un mondo completamente diverso da C RTL.

• WSAStartup(), WSACleanup(): Anche questo è dovuto al fatto che winsock.dll era inizialmente un terzo fornita cosa, che interfacciato con qualche sottostante stack di rete che non è parte del sistema operativo . Inoltre, c'è l'aspetto Win16 delle cose: Win16 non può vedere che un programma è appena morto e ripulire automaticamente le risorse allocate. Dovevi rilasciare tutto in modo esplicito prima che il programma uscisse, altrimenti sarebbero trapelate.

• Mancanza di readv(), ecc: Questo non ha senso in di terze parti/Win16 mondo dove Winsock è nato.