Microsoft Corporation
Windows Sockets is an application programming interface (API) for sending and receiving data on a network. It was originally designed as the top level interface for TCP/IP network transport stacks. Windows Sockets version 1.1 is formally defined in the Windows Sockets 1.1 specification, available in several locations on the Internet.
Microsoft is one member of the group that originally defined Windows Sockets. Microsoft is also one of several software vendors that offers an implementation of Windows Sockets. This is exported from the WSOCK32.DLL that is distributed with Microsoft Win32s, Microsoft Windows 95, and Microsoft Windows NT. The Windows Sockets specification clearly states that additional functions can be added to WSOCK32.DLL. Microsoft has added functions to its version of WSOCK32.DLL (Microsoft-specific extensions) in a manner consistent with the specification. These extensions were added to provide protocol independence, better server performance, and other features requested by customers.
The documentation for the functions in the Microsoft version of WSOCK32.DLL has been distributed in the Microsoft Win32 SDK, along with the rest of the Win32 API, for several years. This is consistent with the philosophy of the SDK, which is to provide software developers with focused, consistent information about numerous Windows-based technologies, including COM, OLE, RPC, OpenGL, MAPI, and TAPI. Although the original documentation did not, the current Win32 API documentation now explicitly lists which functions are part of Windows Sockets and which are specific to the Microsoft implementation.
An application that is written to use the Microsoft-specific extensions may not run correctly on a machine that has been configured to run a TCP/IP stack from another vendor. This white paper is provided to clarify exactly what the Microsoft-specific extensions are and how an application program can avoid dependency on them. An application that is written to use or depend on only the functions in the Windows Sockets specification will run on the widest possible number of machines.
The following Microsoft-specific extensions have been added to provide an abstraction for registering services and resolving names on the network (RNR):
EnumProtocols
GetAddressByName
GetNameByType
GetService
GetTypeByName
SetService
The following Microsoft-specific extensions have been added to provide improved application performance:
AcceptEx
GetAcceptExSockaddrs
TransmitFile
WSARecvEx
In order to work over any implementation of Windows Sockets, an application should not be linked at build-time with any of these functions. At run time, the application should call GetProcAddress (and check the error code) on any function it chooses to use. For more information on these functions, see the Win32 SDK documentation.
The Microsoft version of WSOCK32.DLL allows sockets-based communication over multiple types of networks (protocol independence), while the Windows Sockets specification is written only for IP-based networks. The following socket options are Microsoft-specific extensions designed for non-IP-based networks:
SO_CONNDATA
SO_CONNOPT
SO_DISCDATA
SO_DISCOPT
SO_CONNDATALEN
SO_CONNOPTLEN
SO_DISCDATALEN
SO_DISCOPTLEN
The following socket options are Microsoft-specific extensions for controlling asynchronous reads and writes on socket handles (see Extended File I/O later in this white paper):
SO_OPENTYPE
SO_SYNCHRONOUS_ALERT
SO_SYNCHRONOUS_NONALERT
The following socket options are Microsoft-specific extensions for controlling the size of datagrams:
SO_MAXDG
SO_MAXPATHDG
The following socket options are used with AcceptEx, which is a Microsoft-specific function:
SO_UPDATE_ACCEPT_CONTEXT
SO_CONNECT_TIME
The following socket options are Microsoft-specific extensions for supporting multicast over IP:
IPPROTO_IGMP
IP_MULTICAST_IF
IP_MULTICAST_TTL
IP_MULTICAST_LOOP
IP_ADD_MEMBERSHIP
IP_DROP_MEMBERSHIP
IP_TTL
IP_TOS
IP_DONTFRAGMENT
IP_DEFAULT_MULTICAST_TTL
IP_DEFAULT_MULTICAST_LOOP
IP_MAX_MEMBERSHIPS
The following socket option is a Microsoft-specific extension used to toggle the behavior of out-of-band data between two different standards:
TCP_BSDURGENT
The majority of these socket options were explained in the original Win32 SDK documentation or in the Microsoft Knowledge Base. All are now covered in the Win32 SDK documentation.
The following address and protocol families are Microsoft-specific extensions for supporting protocol independence:
AF_IPX
AF_VOICEVIEW
AF_FIREFOX
AF_UNKNOWN1
AF_BAN
PF_IPX
PF_VOICEVIEW
PF_FIREFOX
PF_UNKNOWN1
PF_BAN
The following define is a Microsoft-specific extension used in conjunction with WSARecvEx for message-oriented transports:
MSG_PARTIAL
The Microsoft implementation of Windows Sockets allows socket handles to be treated as file handles. That is, it is possible to use socket handles with ReadFile, WriteFile, ReadFileEx, WriteFileEx, DuplicateHandle, and other Win32 functions. For an application to run over non-Microsoft implementations of Windows Sockets, socket handles should not be used with the Win32 functions that expect file handles, or an alternate code path should be provided.
Microsoft PowerPoint for Windows 95, version 7.0 includes a powerful feature that allows one computer to broadcast a PowerPoint presentation to additional computers. It is accessible under the “Tools, Presentation Conference...” menu. The program calls EnumProtocols to determine whether to enable this feature. An implementation of Windows Sockets that does not provide EnumProtocols will cause this feature to fail and, in some cases, cause the application to crash. A fix to this problem is available at ftp://ftp.microsoft.com/softlib/mslfiles/wt1274.exe.
The WININET.DLL distributed with Microsoft Internet Explorer 3.0 (alpha release for developers), Internet Assistant for Microsoftâ Word for Windows 95, version 2.0, and the Microsoft ActiveX™ SDK (alpha release for developers) uses the RNR functions, and will not operate correctly over non-Microsoft implementations of Windows Sockets. An updated WININET.DLL will be made available in subsequent releases.
The winsock.def file in Appendix B.7 lists the ordinals defined for the Windows Sockets APIs. In addition to the ordinal values listed, all ordinals 999 and below are reserved for future Windows Sockets use. It may be convenient for a Windows Sockets implementation to export additional, private interfaces from the Windows Sockets DLL. This is perfectly acceptable, as long as the ordinals for these exports are above 1000. Note that any application that uses a particular Windows Sockets DLL's private APIs will most likely not work on any other vendor's Windows Sockets implementation. Only the APIs defined in this document are guaranteed to be present in every Windows Sockets implementation.
If an application uses private interfaces of a particular vendor's Windows Sockets DLL, it is recommended that the DLL not be statically linked with the application but rather dynamically loaded with the Windows routines LoadLibrary() and GetProcAddress(). This allows the application to give an informative error message if it is run on a system with a Windows Sockets DLL that does not support the same set of extended functionality.
Many of the features in the Microsoft-specific extensions have been incorporated into the Windows Sockets 2 specification. In addition to this increase in functionality, Windows Sockets 2 eliminates many of the problems encountered with Windows Sockets 1.1 by moving to a proper WOSA architecture. The DLL layer in Windows Sockets 2 is not duplicated by every vendor that distributes a network protocol stack. Instead, the DLL layer provides a well-defined service provider interface that any network protocol stack can plug into.
Windows Sockets 2 is available on Windows NT with the version 4.0 release and will be available for Windows 95.