Microsoft-specific Extensions to Windows Sockets

March 29, 1996

Contents:

Introduction
Exended Functions
Extended Socket Options
Extended Defines
Extended File I/O
Known Application Problems
Excerpt from Windows Sockets 1.1 Specification
Windows Sockets 2

Introduction

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®, Windows® 95, and 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 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 Wind ows-based technologies, including COM, OLE, RPC, OpenGL®, MAPI, and TAPI. The Win32 API documentation that is now available does not explicitly list which functions are part of Windows Sockets and which are specific to the Microsoft implementation. Future releases of the documentation will clarify this distinction.

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.

Extended Functions

The following Microsoft-specific extensions have been added to provide an abstraction for registering services and resolving names on the network (RNR):

The following Microsoft-specific extensions have been added to provide improved application performance: 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.

Extended Socket Options

The Microsoft version of WSOCK32.DLL allows sockets-based communication over multiple types of networks (protocol indepe ndence), 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:

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):The following socket options are Microsoft-specific extensions for controlling the size of datagrams:The following socket options are used with AcceptEx, which is a Microsoft-specific function:The following socket options are Microsoft-specific extensions for supporting multicast over IP:The following socket option is a Microsoft-specific extension used to toggle the behavior of out-of-band data between two different standards:The majority of these socket options are explained in the Win32 SDK documentation or in the Microsoft Knowledge Base. They will all be documented in the next release of the Win32 SDK.

Extended Defines

The following address and protocol families are Microsoft-specific extensions for supporting protocol independence:

The following define is a Microsoft-specific extension used in conjunction with WSARecvEx for message-oriented transports:

Extended File I/O

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.

Known Application Problems

Microsoft PowerPoint® for Windows 95, version 7.0, includes a powerful feature that allows one computer to broadcast a PowerPoint presentation to additional computers. This feature is accessible from 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 will be made available on the Internet in April.

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™ Development Kit (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 on the Int ernet in early May. Updated versions of Internet Explorer 3.0, Internet Assistant 2.0, and the ActiveX Development Kit will also be made available on the Internet shortly thereafter.

Excerpt from Windows Sockets 1.1 Specification

Private API Interfaces (Section 3.3.7)

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.

Windows Sockets 2

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 int o.

Windows Sockets 2 will be available on Windows NT with the version 4.0 release and will be available for Windows 95 in the second quarter of 1996.

© 1996 Microsoft Corporation