The Windows Sockets (usually abbreviated "Winsock" or "WinSock") specification defines a network programming interface for Microsoft Windows which is based on the "socket" paradigm popularized in BSD Unix. It encompasses both familiar Berkeley socket style routines and a set of Windows-specific extensions designed to allow the programmer to take advantage of the message-driven nature of Windows. The new 2.x versions also add many Win32-centric extensions, as well as pure features like quality-of-service, multicasting and multiprotocol support.
Winsock provides a single API for application developers, to which multiple network software vendors can conform. The specification thus defines the library calls and associated semantics to which an application developer can program and which a network software vendor can implement.
You should get a copy of the API specification if you plan on programming for Winsock. Version 2.x and 1.1 specs are available.
The latest version (as of 1998.09.19) is 2.2.2, but most machines are still running Winsock 1.1. This is because only Windows NT 4.0 and Windows 98 include Winsock 2 out of the box. See Question 1.9 for more information on operating system support for Winsock 2.
By the way, most people just say "Winsock 2" when speaking of the current version of Winsock, because the newer versions just contain edits and clarifications to the original spec.
It's hard to say. Winsock 1.1 was out in January 1993, and Winsock 2.0 was due out in late 1993. What actually happened was that Winsock 2.0 didn't surface until 1995 sometime such is the nature of the standards process.
Also, I'm not sure what else the spec needs, excepting support for emerging LAN/WAN protocols. Given that, I would bet that betas of the next major revision of Winsock will arrive something like a year ahead of the appearance of IPv6 on Windows.
Another issue is that Winsock 2 isn't really "done" yet. A number of initiatives mentioned in the original Winsock 2.0 spec have not yet been implemented or defined fully. These initiatives will probably be implemented in future versions of Winsock, some versions of which may not appear for current versions of Windows. For example, Quality of Service is not yet implemented, and may only be implemented in Windows 98 and Windows NT 5.0. Complete information on the status of Winsock 2 is available at sockets.com's Winsock 2 Status Page.
Microsoft ships a version of Winsock with Windows 95/98 and Windows NT. The advantages of these versions is that they are free and work directly with the operating systems' native network stacks. A few vendors still maintain alternative Winsock stacks (mainly on Windows 95/98) to give their products an edge, but most people just stick with the native stacks.
Probably the two most popular options for Winsock stacks on Windows 3.1 are Microsoft's Wolverine stack and Trumpet Winsock. The basic tradeoff between these two options is that Wolverine is free, while Trumpet is inexpensive shareware. Also, Trumpet can do PPP (modem) connections, while Wolverine can't. Trumpet can also run on Windows 3.1, while Wolverine requires Windows for Workgroups.
The other major source for 16-bit Winsock stacks is the major networking software vendors, especially those that sell "network suites." Network suites are combined packages of common internetworking client applications like telnet, X-Windows, NFS, email and network news. There is a list of network suite vendors on the Resources page.
Keep in mind that you can't copy a WINSOCK.DLL (or WSOCK32.DLL, or WS2_32.DLL) to another machine and expect it to work. You have to get and install a complete network stack, including its proprietary Winsock.
Winsock defines the top level of a network stack, the part which is called by user programs. The method a given Winsock will use to access the network depends on the networking package you have installed, and therefore must vary.
Although you generally do need a networking stack to use Winsock, you can sometimes get away with one of a few workarounds, in a pinch. The first is to use a dummy Winsock, which doesn't do much more than implement an empty WINSOCK.DLL. These are mainly useful for using, say, Netscape while offline. The other method is to install a network stack that allows you to be disconnected, such as a PPP stack. You might then be able to connect through this Winsock to the "localhost address" (127.0.0.1) to test Winsock programs. This method also has problems, however, because a Winsock's localhost connectivity is not guaranteed to exist by the spec, much less work the same way a "normal" Winsock connection will work.
Not as such. The main problem is that Winsock depends greatly on Windows' messaging architecture; plus, DOS lacks the ability to use DLLs such as Winsock. However, there are a few BSD sockets and sockets-like network stacks for DOS available.
Erik Engelke's Waterloo TCP package is a freeware TCP/IP stack that runs over Crynwr-style packet drivers. I've used it myself, and it works very well.
Another option is JSB's Virtual Socket Library. It implements a common BSD sockets API for DOS, Windows, Windows NT, OS/2 and UnixWare programmers. This is probably a better option if you need BSD sockets compatibility and multiplatform support. I've not used it, though, so I can't actually endorse it.
Finally, FTP Software offers the PC/TCP Software Development Kit for DOS. This is roughly the same thing as the JSB product, and since I haven't used this library either, I won't comment further on it.
I have recently come across one other rather interesting alternative: the WSock library for the DJGPP compiler. This library accesses the wsock.vxd or wsock.386 driver used by Microsoft's Windows for Workgroups 3.1 and Windows 95 Winsock stacks. Naturally these drivers only work while Windows is running, so you have to run such a DOS application in a DOS box. This method does have a number of advantages: the DJGPP compiler is free, and the fact that it lets you program a Winsock application without writing a GUI can be a plus. My view, however, is that if you can afford a decent Win32 compiler and can stipulate that your program must run on Windows 95 or Windows NT, you can get this same low overhead by writing a console mode program. Also note that Cygnus Solutions is porting the free GNU tools (including the C and C++ compilers) to Win32 with their GNU-Win32 effort. The system is better than and worse than DJGPP, depending on which part you're looking at, but at least it generates true Win32 executables.
Most Unixes include some form of TCP/IP library (BSD sockets in most, TLI or XTI in the unfortunate remainder), so there isn't much need for Winsock on Unix.
As of OS/2 Warp 4, OS/2 supports Winsock as well as its own sockets API. The Winsock emulation is part of OS/2's Open32 API, and probably conforms to Winsock 1.1. (Winsock 2 is probably too Win32-specific for IBM to emulate it with any real degree of success.) OS/2's native sockets API is based on pure Berkeley sockets; in a sense, then, you can have a subset of Winsock without using the Open32 API. You mainly lose all the functions that begin with "WSA".
OS/2 Warp 3.0 and earlier have extra-cost packages available that add TCP/IP support, including some support for the Winsock API.
Yes. Win32s 1.1 contains a WSOCK32.DLL that thunks calls down to a 16-bit WINSOCK.DLL, if present. I have successfully used Win32s to run 32-bit Winsock programs over Trumpet Winsock and Microsoft's Wolverine stack.
Winsock 1.1 only provided real support for TCP/IP. However, Microsoft, Novell and a few other vendors did provide NetBIOS, IPX/SPX and other support through Winsock, but the point is that this support was never standardized in the Winsock specification.
Winsock 2 changed this by providing standardized support for DECNet, IPX/SPX and OSI. Support for other LAN/WAN protocols are likely to follow.
One of the most important new features is official support for multiple transport protocols. Although Winsock 1.1 was not actually limited to TCP/IP, that was the only protocol that had official support written into the spec. There was no standard way for a vendor to add support for another transport protocol, though a few vendors did do proprietary implementations of other protocols. With Winsock 2, official support for OSI, Novell IPX/SPX and Digital's DECNet exists in the spec, and it's now possible to add support for other protocols in a standard way. More importantly, a program can be written to be transport-independent, so that it works with all of these protocols, without change.
Winsock 2 also adds support for technical initiatives like Quality of Service and Multicasting. These technologies will become increasingly important as bandwidth requirements become more regimented and intense. For example, the QoS mechanism would allow a videoconferencing program to reserve a certain amount of bandwidth so that a sudden file transfer, for example, doesn't cause its video to begin breaking up due to a lack of bandwidth.
The multicasting support would allow you to hold a videoconference with multiple people on the same LAN but have each video phone only send a single stream of data. (The current alternative requires every phone to send a stream of data to every other conference particpant. This is wasteful and can quickly bog down a common LAN.)
Another important feature of Winsock 2 is complete integration with Win32's unified I/O mechanisms. For example, it is possible to use the Win32 ReadFile() API on a socket instead of recv(). More importantly, Windows NT's overlapped I/O mechanisms can now be used with sockets; Winsock 2 on Windows 95 also implements overlapped I/O with sockets, though it is faked, because Windows 95 does not support overlapped I/O natively.
Winsock 2 also allows for "Layered Service Providers." This enables many neat things, such as security plug-ins: drop in, say, an SSL service provider, and all of a sudden your data is automatically encrypted. Rumor has it that Windows NT 5.0 will include such a layer, for example.
There are a number of other additions to the spec. You can get a complete list of them on sockets.com's Winsock 2 Overview page.
Windows NT 4.0 and Windows 98 ship with Winsock 2 support, and you can get it for Windows 95 (see below). Unfortunately, Winsock 2 will not run on Windows 3.1 or Windows NT 3.51, so those users will have to upgrade to a newer operating system or stick with Winsock 1.1.
Windows 95 only ships with Winsock 1.1, but you can get the Winsock 2 SDK for Windows 95 for it. This package comes with a full set of freely redistributable components which your program's installer can use to upgrage a stock Windows 95 system to Winsock 2. Alternatively, you can download these user-level components instead of getting the entire SDK.
![]() |
Go to my home page |
![]() |
Go to my Important RFC Lists page |
![]() |
Go to the main Programming Resources page |
Please send updates and corrections to <tangent@cyberport.com>.