有一些很有限的地方， Windows Sockets API 必須與從嚴格地堅持 Berkeley 傳統風格中解放出來。通常這么做是因為在 Windows 環境中實現的難度。

（1） 套接口數據類型和錯誤數值

Windows Sockets 規范中定義了一個新的數據類型 SOCKET ，這一類型的定義對于將來 Windows Sockets 規范的升級是必要的。例如在 Windows NT 中把套接口作為文件句柄來使用。這一類型的定義也保證了應用程序向 Win/32 環境的可移植性。因為這一類型會自動地從 16 位升級到 32 位。

在 UNIX 中所有句柄包括套接口句柄，都是非負的短整數，而且一些應用程序把這一假設視為真理。 Windows Sockets 句柄則沒有這一限制，除了 INVALID_SOCKET 不是一個有效的套接口外，套接口可以取從 0 到 INVALID_SOCKET-1 之間的任意值。

因為 SOCKET 類型是 unsigned ，所以編譯已經存在于 UNIX 環境中的應用程序的源代碼可能會導致 signed/unsigned 數據類型不匹配的警告。

這還意味著，在 socket() 例程和 accept() 例程返回時，檢查是否有錯誤發生就不應該再使用把返回值和 -1 比較的方法，或判斷返回值是否為負（這兩種方法在 BSD 中都是很普通，很合法的途徑）。取而代之的是，一個應用程序應該使用常量 INVALID_SOCKET ，該常量已在 WINSOCK.H 中定義。

例如：

（2） select() 函數和 FD_* 宏

由于一個套接口不再表示了 UNIX 風格的小的非負的整數， select() 函數在 Windows Sockets API 中的實現有一些變化：每一組套接口仍然用 fd_set 類型來代表，但是它并不是一個位掩碼。整個組的套接口是用了一個套接口的數組來實現的。為了避免潛在的危險，應用程序應該堅持用 FD_XXX 宏來設置，初始化，清除和檢查 fd_set 結構。

（3） 錯誤代碼－ errno,h_errno,WSAGetLastError()

Windows Sockets 實現所設置的錯誤代碼是無法通過 errno 變量得到的。另外對于 getXbyY() 這一類的函數，錯誤代碼無法從 h_errno 變量得到。錯誤代碼可以使用 WSAGetLastError() 調用得到。這一函數在 5.3.11 中討論。這個函數在 Windows Sockets 實現中是作為 WIN/32 函數 GetLastError() 的先導函數（最終是一個別名）。這樣做是為了在多線程的進程中為每一線程得到自己的錯誤信息提供可靠的保障。

為了保持與 BSD 的兼容性，應用程序可以加入以下一行代碼：

#define errno WSAGetLastError()

這就保證了用全程的 errno 變量所寫的網絡程序代碼在單線程環境中可以正確使用。當然，這樣做有許多明顯的缺點：如果一個原程序包含了一段代碼對套接口和非套接口函數都用 errno 變量來檢查錯誤，那么這種機制將無法工作。此外，一個應用程序不可能為 errno 賦一個新的值（在 Windows Sockets 中， WSASetLastError() 函數可以做到這一點）。

例如：

雖然為了兼容性原因，錯誤常量與 4.3BSD 所提供的一致；應用程序應該盡可能地使用“ WSA ”系列錯誤代碼定義。例如，一個更準確的上面程序片斷的版本應該是：

r = recv(...);

if (r == -1/* 但請見下文 */

&& WSAGetLastError() == WSAEWOULDBLOCK)

{...}

（4） 指針

所有應用程序與 Windows Sockets 使用的指針都必須是 FAR 指針，為了方便應用程序開發者使用， Windows Sockets 規范定義了數據類型 LPHOSTENT 。

（5） 重命名的函數

有兩種原因 Berkeley 套接口中的函數必須重命名以避免與其他的 API 沖突：

close() 和 closesocket()

在 Berkeley 套接口中，套接口出現的形式與標準文件描述字相同，所以 close() 函數可以用來和關閉正規文件一樣來關閉套接口。雖然在 Windows Sockets API 中，沒有任何規定阻礙 Windows Sockets 實現用文件句柄來標識套接口，但是也沒有任何規定要求這么做。套接口描述字并不認為是和正常文件句柄對應的 , 而且并不能認為文件操作，例如 read() ， write() 和 close() 在應用于套接口后不能保證正確工作。套接口必須使用 closesocket() 例程來關閉，用 close() 例程來關閉套接口是不正確的，這樣做的效果對于 Windows Sockets 規范說來也是未知的。

ioctl() 和 iooctlsocket()

許多 C 語言的運行時系統出于與 Windows Sockets 無關的目的使用 ioctl() 例程，所以 Windows Sockets 定義 ioctlsocket() 例程。它被用于實現 BSD 中用 ioctl() 和 fcntl() 實現的功能。

（6） 阻塞例程和 EINPROGRESS 宏

雖然 Windows Sockets 支持關于套接口的阻塞操作，但是這種應用是被強烈反對的 . 如果程序員被迫使用阻塞模式（例如一個準備移植的已有的程序），那么他應該清楚地知道 Windows Sockets 中阻塞操作的語義。有關細節請參見 4.1.1

（7） Windows Sockets 支持的最大套接口數目

一個特定的 Windows Sockets 提供者所支持的套接口的最大數目是由實現確定的。任何一個應用程序都不應假設某個待定數目的套接口可用。這一點在 4.3.15 WSAStartup() 中會被重申。而且一個應用程序可以真正使用的套接口的數目和某一特定的實現所支持的數目是完全無關的。

一個 Windows Sockets 應用程序可以使用的套接口的最大數目是在編譯時由常量 FD_SETSIZE 決定的。這個常量在 select() 函數（參見 4.1.18 ）中被用來組建 fd_set 結構。在 WINSOCK.H 中缺省值是 64 。如果一個應用程序希望能夠使用超過 64 個套接口，則編程人員必須在每一個源文件包含 WINSOCK.H 前定義確切的 FD_SET 值。有一種方法可以完成這項工作，就是在工程項目文件中的編譯器選項上加入這一定義。例如在使用 Microsoft C 時加入 -D FD_SETSIZE=128 作為編譯命令的一個命令行參數 . 要強調的是： FD_SET 定義的值對 Windows Sockets 實現所支持的套接口的數目并無任何影響。

（8） 頭文件

為了方便基于 Berkeley 套接口的已有的源代碼的移植， Windows Sockets 支持許多 Berkeley 頭文件。這些 Berkeley 頭文件被包含在 WINSOCK.H 中。所以一個 Windows Sockets 應用程序只需簡單的包含 WINSOCK.H 就足夠了（這也是一種被推薦使用的方法）。

（9）A PI 調用失敗時的返回值

常量 SOCKET_ERROR 是被用來檢查 API 調用失敗的。雖然對這一常量的使用并不是強制性的，但這是推薦的。如下的例子表明了如何使用 SOCKET_ERROR 常量

典型的 BSD 風格：

r = recv(...);

if (r == -1 /* or r < 0 */

&& errno == EWOULDBLOCK)

{...}

更優良的風格：

r = recv(...);

if (r == SOCKET_ERROR

&& WSAGetLastError == WSAEWOULDBLOCK)

{...}

（10） 原始套接口

Windows Sockets 規范并沒有規定 Windows Sockets DLL 必須支持原始套接口－用 SOCK_RAW 打開的套接口。然而 Windows Sockets 規范鼓勵 Windows Sockets DLL 提供原始套接口支持。一個 Windows Sockets 兼容的應用程序在希望使用原始套接口時應該試圖用 socket() 調用（參見 5.1.23 節）來打開套接口。如果這么做失敗了，應用程序則應該使用其他類型的套接口或向用戶報告錯誤。

七 在多線程 Windows 版本中的 Windows Sockets

Windows Sockets 接口被設計成既能夠在單線程的 Windows 版本（例如 Windows 3.1 ）又能夠在占先的多線程 Windows 版本（例如 Windows NT ）中使用，在多線程環境中，套接口接口基本上是不變的。但多線程應用程序的作者必須知道，在線程之間同步對套接口的使用是應用程序的責任，而不是 Windows Sockets 實現的責任。這一點在其他形式的 I/O 中管理，例如文件 I/O 中是一樣的。沒有對套接口調用進行同步將導致不可預測的結果。例如，如果有兩個線程同時調用同一套接口進行 send() ，那么數據發送的先后順序就無法保證了。

在一個線程中關閉一個未完成的阻塞的套接口將會導致另一個線程使用同一套接口的阻塞調用出錯（ WSAEINTER ）返回，就象操作被取消一樣。這也同樣適用于某一個 select() 調用未完成時，應用程序關閉了其中的一個被選擇的套接口。

在占先的多線程 Windows 版本中，并沒有缺省的阻塞鉤子函數。這是因為如果一個單一的應用程序在等待某一操作結束時并不會調用 PeekMessage() 或 GetMessage() 這些會使應用程序產生一個非占先窗口的函數。因此機器在這種情況下不會被阻塞。然而，為了向后的兼容性，在多線程 Windows 版本中， WSASetBlockingHook() 函數也被實現了。任何使用缺省阻塞鉤子的應用程序可以安裝它們自己的阻塞鉤子函數來覆蓋缺省的阻塞鉤子函數。