1.1 - What is Winsock?
The Windows Sockets (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:
- Winsock 1 apps can ask Winsock to send notifications in window messages. This allows your program to handle both the network, UI issues, and background processing without having to worry about concurrency.
- Winsock 2 adds many features. See below for details.
Winsock 2.x defines two interfaces: an application programming interface (API) which shields application developers from underlying layers, and a service provider interface (SPI) which allows transparent extensions to a Winsock stack. Through proper use of the API, a Winsock application can work over various network transport protocols and Winsock implementations.
(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.)
You should get a copy of the API specification if you plan on programming for Winsock. Winsock 2 and Winsock 1.1 specs are available.
1.2 - What is the latest version?
The latest version (as of 1998.09.19) is 2.2.2, but most Windows 95 machines are still running Winsock 1.1. There is an upgrade available for Windows 95, however. Windows 98, Windows NT 4.0 and Windows 2000 include Winsock 2. Older OSes (NT 3.x and Windows 3.x) cannot support Winsock 2.
1.3 - What does Winsock 2 have that Winsock 1.1 doesn't?
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 (QoS) and multicasting. These technologies will become increasingly important as bandwidth requirements become more regimented and intense. For example, QoS allows 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. Multicasting allows that videoconferencing application to send audio and video streams to many participants without duplicating data any more than absolutely necessary.
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/2000's overlapped I/O
mechanisms can now be used with sockets. Winsock 2 on Windows 9x also
implements overlapped I/O with sockets, but because there is no native
support in the Windows 9x kernel for overlapped I/O, the mechanism is
completely emulated by Winsock.
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.
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.
1.4 - When is the next rev of the specification due out?
The current revision (2.2) looks pretty durable to me. There are two things that could force Microsoft to create a new version of Winsock:
- A new transport protocol comes out that Microsoft wants to support. Currently, Winsock supports all the common transport protocols, and there seems to be no serious competition to replace frontrunners like TCP/IP.
- Major changes to an existing network protocol.
This is due to happen once IPv6 takes off, because it requires changes
to a lot of Winsock-level functionality, especially all the functions
that depend on
sockaddr_in.
Windows 2000 was the most likely source of changes to the Winsock spec. Winsock support under Win2K did change, but not so that it required a new revision of the Winsock spec. Since Win2K will be with us until about 2003, and Microsoft's consumer OSes won't change Winsock, it's a pretty sure bet that we've got at least a few years of stability to look forward to.
1.5 - Can Winsock speak { DECNet, IPX/SPX, etc. }?
Winsock 1.1 only provided real support for TCP/IP. Microsoft, Novell and a few other vendors did provide NetBIOS, IPX/SPX and support for other transport protocols 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 the DECNet, IPX/SPX and OSI transport protocols. I've heard that ATM's native transport has some semi-official Winsock support as well. (It requires Winsock addons from your ATM card's vendor.) Support for other LAN/WAN transports are likely to follow as demand dictates.
1.6 - Where can I get Winsock?
Windows 95 and Windows NT 3.5 shipped with Winsock 1.1. Windows 98 and Windows NT 4.0 and up shipped with Winsock 2.
Winsock is available as an add-on for Windows 3.1. Probably the two most popular options 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 as part of a "network suite", but these products are becoming extremely hard to find. (Microsoft's free stacks coupled with shareware and freeware applications have made this software category obsolete.)
Keep in mind that you can't copy a Winsock DLL to another machine and expect it to work. You have to get and install a complete network stack, including its proprietary Winsock layer.
1.7 - Can I get Winsock 2 for...?
...Windows 98, Windows NT 4.0 or Windows 2000?
These platforms already come with Winsock 2.
...Windows 95?
Windows 95 ships with Winsock 1.1, but you can get the Winsock 2 SDK as part of the Windows Platform SDK. (Sorry, there's no longer a place where you can get just the Winsock SDK.) You may also need the Winsock 2 Update package; you will definitely need to tell your users about this, if they wish to use your program on Windows 95.
...Windows 3.1? Windows NT 3.5x?
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. (See above for
a list of what Winsock 2 includes 
you may not need
Winsock 2's advanced features for your application.)
1.8 - Is there a version of Winsock for...?
...DOS?
DOS cannot support Winsock, because Winsock depends greatly on Windows' messaging and DLL mechanisms.
(Before I discuss alternatives to Winsock for DOS programmers, I want to clear up a common confusion. Command-line windows under Windows 95/98/NT/2000 are sometimes called "DOS boxes". This is a historical term, and is now inaccurate. In Win32, there's a new class of programs called "console mode programs". These console mode programs run in these "DOS boxes" and can look and feel like old DOS programs, but they can call any Win32 function, including Winsock. Note for example that all of the examples in the FAQ are console programs.)
Erick 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. The manual is available for $50; if you plan on using this package to develop serious applications, trust me, this is a worthwhile investment. (If you're just puttering around, you can probably figure things out by messing around with the example programs.)
Another option is JSB's Virtual Socket Library. It implements a common BSD sockets API for DOS, among other systems. This is probably a better option than Waterloo TCP if you need BSD sockets compatibility and multiplatform support. I've not used it, though, so I can't actually endorse it.
NetManage (formerly FTP Software) offers the PC/TCP Software Development Kit for DOS. This appears to be roughly the same thing as the JSB product, but since I haven't used this library either, I won't comment further on it.
Finally, Async Systems offers the Socket Library SDK
for DOS. This is a pure BSD-sockets workalike for DOS, with a few
curious Winsock-isms like closesocket() instead of
close(). You can download it for a free 90-day
evaluation.
There is 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.
I personally dislike the WSock option unless you're stuck on Windows 3.1 and can't buy a commercial compiler. If you 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 with the Cygwin tool set, which is essentially the same thing as DJGPP except for Win32.
...Unix?
Essentially all Unixes offer the BSD sockets API for TCP/IP programming, which is the ancestor of Winsock. Some older Unix versions also offer a competing API called XTI (or TLI in its older form), which is similar enough to Winsock and BSD sockets that you won't have much trouble learning it if you know the sockets API.
...OS/2?
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.
...NetWare?
NetWare has had Winsock support since September of 1998. It's included in NetWare 5, and can be had for NetWare 4 in Support Pack 8. Novell has a porting guide that tells you what works and what doesn't in their implementation with respect to Microsoft's.
...Win32s?
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.