WinSock 2 InformationWinSock 2 Information
For the status of specific WinSock 2 features, see the WinSock 2 Feature Status page. Here is a summary:
WinSock version 1.1 has been the standard since its release in January of 1993, and has exceeded its authors' original intent to provide a powerful and flexible API for creating universal TCP/IP applications. Some have argued that it was an unsung hero in the Internet's phenomenal success, as it enabled the creation of a single network appliation--like Netscape's browser, for example--to run on the many TCP/IP stacks for PC's that existed at the time.
Since those early days, the PC network industry has changed completely: The many TCP/IP vendors have all but disappeared after their software was replaced by Microsoft's free TCP/IP implementations built into the operating systems. The Internet has continued to explode in popularity, as have the number of applications that depend on WinSock and they have changed as they diversified. Applications have become more demanding of Internet services. As a result, the Internet itself is changing, evolving. The Grand Convergence of phone, radio and television networks to the Internet Protocols (IP) is underway. So, of course, it comes as no surprise that WinSock--the APIs--have undergone change also. Specifically, in support for the new Internet concept of "Quality of Service" (QoS). But that's not all.
The authors of Windows Sockets version 1.1 originally limited the scope of the API specification to TCP/IP primarily, but this focus did not preclude the possibility that WinSock--like its Berkeley Sockets Model--could support other protocol suites. Windows Sockets version 2.0 (WinSock 2) formalizes the API for a number of other protocol suites-- ATM, IPX/SPX, and DECnet--and allows them to coexist simultaneously. WinSock 2 also adds substantial new functionality. Most importantly, it does all this and still retains full backward compatibility with the existing 1.1--some of which is clarified further--so all existing WinSock applications can continue to run without modification (the only exception are WinSock 1.1 applications that use blocking hooks, in which case they need to be re-written to work without them)..
WinSock 2 goes beyond simply allowing the coexistence of multiple protocol stacks, in theory it even allows the creation of applications that are network protocol independent. A WinSock 2 application can transparently select a protocol based on its service needs. The application can adapt to differences in network names and addresses using the mechanisms WinSock 2 provides.
Here is a list of the new features that WinSock 2 provides:
In a nutshell, WinSock 2 is WinSock 1.1 on steroids, it's a superset of 1.1's APIs and architecture. In addition to its new features, it also clarifies existing ambiguities in the 1.1 WinSock specification and adds new extensions that take advantage of operating system features and enhance application performance and efficiency. Finally, WinSock 2 includes a number of new protocol-specific extensions. These extensions--such as multicast socket options--are relegated to a separate annex, since the main WinSock 2 protocol specification is protocol-independent.
The authors of WinSock version 1.1 deliberately limited its scope in the name of expediency. One result of this is the simple architecture of WinSock 1.1. A single WINSOCK.DLL (or WSOCK32.DLL) provides the WinSock API, and this DLL "talks" to the underlying protocol stack via a proprietary programming interface. This works fairly well since v1.1 WinSock only supports one protocol suite--TCP/IP--and most computers running Windows have only a single network interface.
However, this WinSock 1.1 architecture limits a system to only one WinSock DLL active in the system path at a time. As a result, it is not easy to have more than one WinSock implementation on a machine at one time. There are legitimate reasons to want multiple WinSock implementations. For example, one might want a protocol stack from one vendor over the Ethernet connection and a different vendor's stack over the Serial Line.
WinSock 2 has an all-new architecture that provides much more flexibility. The new WinSock 2 architecture allows for simultaneous support of multiple protocol stacks, interfaces, and service providers. There is still one DLL on top, but there is another layer below, and a standard service provider interface, both of which add flexibility.
WinSock 2 adopts the Windows Open Systems Architecture (WOSA) model, which separates the API from the protocol service provider. In this model the WinSock DLL provides the standard API, and each vendor installs its own service provider layer underneath. The API layer "talks" to a service provider via a standardized Service Provider Interface (SPI), and it is capable of multiplexing between multiple service providers simultaneously. The following sketch illustrates the WinSock 2 architecture.
+---------------+ +-----------------++-----------------+
| WinSock 2 | | 16-bit WinSock || 32-bit WinSock |
| Application | | 1.1 Application || 1.1 Application |
+---------------+ +-----------------++-----------------+
| | |
| +-----------------++-----------------+ <-- WinSock
| | WINSOCK.DLL || WSSOCK32.DLL | 1.1 API
| | (16-bit) || (32-bit) |
| +-----------------++-----------------+
| |
+-------------------------------------------------------+ <-- WinSock
| WS2-32.DLL (32-bit) | 2.0 API
+-------------------------------------------------------+
|
+-------------------------------------------------------+ <--- WinSock
|+-----------++--------------++------------++----------+| 2.0 SPI
|| TCP/IP || TCP/IP-based || additional ||Layered SP|| /
|| transport || namespace || service |+----------+| /
|| service || service pro- || providers |+----------+| <--
|| provider || vider (DNS) || (SPX, etc.)|| Any TSP ||
|+-----------++--------------++------------++----------+|
+-------------------------------------------------------+
Note that the WinSock 2 specification has two distinct parts: the API for application developers, and the SPI for protocol stack and namespace service providers. Notice also that the intermediate DLL layers are independent of both the application developers and service providers. These DLLs are provided and maintained by Microsoft and Intel. And lastly, notice that the Layered Service Providers would appear in this illustration one or more boxes on top of a transport service provider.
There is no plan to create a 16-bit WinSock 2 DLL (WS2-16.DLL) for a number of reasons, not the least of which is the fact that service providers expressed little interest in developing 16-bit versions of their modules. This means that there is no WinSock 2 available for Windows version 3.1 (or 3.11).
WinSock 2 is designed only for 32-bit Windows platforms; it cannot be run using Win32s on 16-bit Windows platforms. Nonetheless, as described earlier, (almost) all 16-bit WinSock 1.1 applications can be used
Windows NT version 4 has been called the "shell-update," since the most obvious change was the addition of the Windows 95 user interface. But there's a whole lot more that was changed within the NT4 kernel design. Significant modifications were done to make WinSock 2 the native network API for Windows NT4. As a result, WinSock 2 will not be available for NT 3.51 or earlier*.
* Also note that although Windows CE is a new 32-bit networking-capable operating system from Microsoft that provides a WinSock API, Windows CE 2.0 only supports a subset of WinSock 1.1
The specification for WinSock 2 is actually made up of several seperate documents. Each of these documents are usually (though not always) available in the 3 different formats: MS Word for Windows (.doc), Text (.txt) and Postscript (.ps). Most are BIG (250+ pages each), so you are encouraged to print double-sided, if possible.
NOTE: Although the following specifications are very useful and mostly complete, unfortunately these publically available specifications (in Word95 format) have not been kept entirely in synch with the actual WinSock releases and beta versions from Microsoft. For the very latest versions of the WinSock API documentation--and especially for the proprietary Microsoft extensions--you need to buy a subscription to the Microsoft Developer's Network (MSDN). The core of WinSock is still an open standard, but the many new changes and additions along with the changes in the PC-based TCP/IP network stack industry have made it much less so.
The WinSock 2 API and Protocol Specific Annex documents are
of primary interest to WinSock application developers (those working above
the WinSock 2 DLLs). Whereas, the WinSock 2 SPI document is for
those who provide a WinSock 2 service (those working below the WinSock
2 DLL, to provide NameSpaces, Transports, or Layered Services).
The WinSock 2 Debug and Trace Facilities document will be of interest to both application developers and service providers, as well as to technical support people. This document describes a great new addition to the WinSock 2 Software Development Kit (SDK) that provides the ability to trace WinSock 2 function calls and returns. These new facilities will provide invaluable help in determining who is responsible when a problem exists: the WinSock 2 application developer, intermediate DLL, or service provider.
NOTE: The Microsoft versions of the WinSock 2 specifications include some Microsoft-proprietary (non-WinSock) APIs interspersed with the standard APIs. In most cases these are flagged, but beware of using these since they may have problems with third-party layered or base Service Providers. For more information see http://www.sockets.com/mswsock.htm
To provide the debug/trace facilities, the SDK comes with a (non-redistributable) drop-in replacement for the WinSock 2 DLL that outputs function call and return information to an external DLL (DT_DLL.DLL). This debug/trace DLL has a simple user interface that allows viewing and/or redirection of the debug/trace information. The SDK even includes source code for the DT_DLL.DLL, in case you want to look or tinker "under the hood." Useful, useful, useful! For more information see my Debug Trace DLL Issues (on the WinSock 2 Feature Status page in the Multiple Protocol Support section), and the Debug Trace specification.
The Debug Trace DLL will only function when you replace WS2-32.DLL with the symbolic (debug) version that comes with the WinSock 2 SDK. It's recommended that you do NOT put DT_DLL.DLL in your \windows\system directory. At a minimum, having the DT_DLL message box pop-up every time you run a WinSock application is annoying, but at worst it can keep your system from booting if you have servers that run automatically on Windows NT 4.0 (because it automatically pops up a dialog box prompt for where output should go).
You can retrieve copies of the current provisional specifications for the WinSock 2 API, Protocol Specific Annex, WinSock 2 SPI, WinSock 2 beta SDK, and Microsoft's WinSock 2 Setup Spec (for Win95) from the following World Wide Web sites. .
...or from the following FTP Site:
There is a single mailing list for all suggestions, questions, and comments regarding the WinSock 2 specifications. It is called, appropriately, "winsock-2," and maintained at Intel Research Labs. It uses ListServ for the mail list manager software; for information on how to use listserv, you can reference http://www.lsoft.com/listserv.stm#DOCS.
You need only specify [address] if the address you want subscribed is *not* the same as the address from which you are sending the email to majordomo. Listserv will send mail back to you confirming your subscription.
WinSock 2 mail list archives are available:
Updated 12/5/98 (c) Bob Quinn, 1995-1998