WinSock 2 InformationWinSock 2 InformationWinSock 2 for Win95 and SDK released!!
Updates to WinSock 2 API and SPI Specifications Available
Windows Sockets Version 2.0 is the successor to version 1.1, which has been the standard since its release in January of 1993. WinSock version 1.1 has met, if not exceeded, its authors' original intent to provide a powerful and flexible API for creating universal TCP/IP applications. You can create any type of client or server TCP/IP application with an implementation of Windows Sockets based on the version 1.1 Windows Sockets specification. You can port Berkeley Sockets applications and take advantage of the message-based Microsoft Windows programming environment and paradigm. But that's not to say that WinSock cannot provide more.
The authors of Windows Sockets version 1.1 intentionally limited its scope to expedite the process and ensure its success. WinSock 1.1 deals primarily with TCP/IP because the software vendors involved sold TCP/IP network software, but it also conveniently allowed them to ignore the difficult issue of how to provide a single API for multiple vendors simultaneously. This focus on TCP/IP did not preclude the possibility that WinSock--like its Berkeley Sockets Model--could support other protocol suites at some point in the future. The future is now.
Windows Sockets version 2.0 (WinSock 2) formalizes the API for a number of other protocol suites-- DecNet, IPX/SPX, and OSI--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.
WinSock 2 goes beyond simply allowing the coexistence of multiple protocol stacks; it also 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:
* not implemented yet
** no QOS templates defined yet (for WSAGetQOSByName())
WinSock 2 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.
Ideally, the intermediate layer is virtually transparent and does little more than maintain the registry of service providers.
As we mentioned earlier, 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 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. It currently runs as an add-on for Windows 95, installed with the SDK. WinSock 2 ships as the native WinSock version for Windows NT version 4.0, and will be the native network API for Memphis (the new version of Windows 95--Windows97???--due for release later this year).
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.
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.
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.
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!
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'srecommended 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) (see "open issues" at the end of the status report below for more information on this setup spec) from the following World Wide Web sites. As of 8/10/96, the beta version 1.6 of the WS2 SDK has been widely available, but it is not the latest version of the WinSock 2 SDK.
...or from the following FTP Sites:
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. Notice that as of 9/19/96, this was moved from majordomo to listserv; for information on how to use listserv, you can reference http://www.lsoft.com/listserv.stm#DOCS. Note that there are two other Winsock-relevant mailing lists hosted by Intel at this site also (the winsock and winsock-hackers mailing lists).
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. Majordomo will send mail back to you confirming your subscription.
WinSock 2 mail list archives are available:
NT4's Service Pack 4 will have WPUCompleteOverlappedRequest() entry point
Date: Wed, 17 Sep 1997 15:38:55 -0700
From: Tim Moore <timmoore@MICROSOFT.COM>
Subject: Re: LSPs and IFS handles
To: WINSOCK-2@mailbag.jf.intel.com
IFS handles cause problems with NT 4.0 which will be fixed in service
pack 4.
I don't know when that will be available. IFS handles should work on Windows
95
with Winsock 2. RecvEx should work fine if IFS works.
Tim
New Program Manager for WinSock 2 from Microsoft
Date: Thu, 11 Sep 1997 13:58:08 -0700
From: Chris Steck <chrisste@MICROSOFT.COM>
Subject: Moving on...
To: WINSOCK-2@MAILBAG.INTEL.COM
Well, it was just a little over a year ago, where I was thrown to
the wolves
my second week on the job as WinSock PM at the Bakeoff at FTP in Boston.
Ws2
for Win95 is out the door, my Win98 involvement is waning, and it's now
time
for me to move on to something else here at MS.
So I just wanted to let you folks know that I'm in the process of
transitioning
off of the WinSock 2 project here at MS, and am moving over to our Interactive
Multimedia Group to program manage CarPoint (carpoint.msn.com)
I will continue to be involved with Ws2 for Windows 98 issues until
it ships
(mainly setup), but all of my responsibilities (including my seat on the
Advisory Board) are shifting over to Tim Moore. Please start sending to
Tim
(timmoore@microsoft.com) any WS2 mail you would normally send to me and
cc'ing
me, or vice versa, to aid in our transition.
I've enjoyed working with all of you and only hope that I've given
back to this
program as much as I've learned working with folks like yourselves.
-Chris
WinSock 2 for Win95 and SDK released!!
Available at:
ftp://ftp.microsoft.com/bussys/WinSock/winsock2.
http://www.microsoft.com/win32dev/netwrk/winsock2/ws295sdk.html
Date: Tue, 10 Jun 1997 19:36:26 -0700
Reply-To: Chris Steck <chrisste@MICROSOFT.COM>
Sender: Winsock-2 <WINSOCK-2@mailbag.jf.intel.com>
From: Chris Steck <chrisste@MICROSOFT.COM>
Subject: Re: WinSock 2 for Windows 95 SDK is now available!
To: WINSOCK-2@mailbag.jf.intel.com
Oh, and please take care to uninstall your beta versions of WinSock
2 for Win95 before installing the final release. There have been
numerous changes to setup, uninstall, and the files that are upgraded,
so your safest bet is to completely uninstall WS2 betas, reinstall 1.1
TCP from the control panel, then run ws2setup.exe. Please see the
details on this topic in the readme.txt.
Also take note to read the End User License Agreement, either in
the
SDK or when it pops up on download. It discusses your right to
redistribute WS2setup.exe (which contains all of the winsock 2 dlls)
but not the individual dlls. Again, see the license.txt and the readme
for full details.
-Chris
Microsoft Chris Steck Program Manager Networking & Communications
> -----Original Message-----
> From: Chris Steck
> Sent: Tuesday, June 10, 1997 4:33 PM
> To: 'Multiple recipients of list WINSOCK-2'
> Subject: WinSock 2 for Windows 95 SDK is now available!
>
> I am pleased to announce on behalf of Microsoft and the WinSock 2
Team
> that WinSock 2 for Windows 95 SDK is now available from
> http://www.microsoft.com/win32dev/netwrk/winsock2/ws295sdk.html (It'll
> hit the ftp site sometime tomorrow as well)
>
> Thanks to all of you who have participated in the betas, your input
> has been essential in helping us to ship a high quality product!
> -Chris
>
> Microsoft
> Chris Steck
> Program Manager
> Networking & Communications
Version 2.2.1 WinSock 2 API & SPI specs available
As the minor revision numbers indicate, these are not major updates to the specifications. Most of the changes are edits and clarifications; they do not yet contain the new interface additions described in Stardust's WinSock 2 Status Report. A few things of note: In the API, WSAGetQOSByName() was updated (to return a list of template names available), and socket group references have been flagged with "reserved for future use." In the SPI, WSCWriteProviderOrder() (in SPORDER.DLL) is now documented in Appendix B.
Note also, that the WinSock 2 Protocol-Specific Annex has not yet been updated (still version 2.0.3).
See report at Stardust website: http://www.stardust.com/wsresource/winsock2/ws2_status.html
The Last Bakeoff - Oct 28-Nov 1, 1996
This week-long event, hosted by Stardust Technologies, and sponsored by a number of major network vendors, was a great success. We got a lot of work done, and as always, we had fun doing it.
Aside from the interoperability testing between the vendors, there were a number of very productive "break-out sessions" where some serious discussions took place to tie-up some of the loose ends that still remain in the WinSock 2 specfication and implementations. From the RSVP meeting, there is ongoing work to define how the generic QoS APIs will map to the IETF RSVP protocol. Dave Anderson sent a proposal to the WinSock 2 mailing list for "Managing the Ordering of Layered Providers in Protocol Chains" that was a direct result of the discussions at the WinSock Hookers and Chainers session.