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:

1. 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.
2. 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.

1.2 - What's the difference between Winsock and TCP/IP?

Networks are made of several layers. Network people talk about those layers in terms of the OSI network model.

TCP/IP is a network protocol, meaning that it is at layers 3 through 5 in the OSI model. A network protocol provides services like addressing, data transport, routing, and logical connections across a network. Two computers must use the same network protocol if programs running on those computers are to communicate. Other common network protocols include Novell's IPX, 3Com/IBM/Microsoft's NetBIOS and Apple's AppleTalk. TCP/IP is the most popular network protocol today: virtually all computers support it.

Winsock is an API that lets a Windows program send data over any network transport protocol. There are several functions in Winsock that only work with TCP/IP (e.g. gethostbyaddr()), but there are newer generic versions of all these in Winsock 2 which allow you to use other transports.

1.3 - What newsgroups and mailing lists exist for Winsock and TCP/IP?

The main Winsock newsgroups are comp.os.ms-windows.programmer.tools.winsock and alt.winsock.programming. These only cover Windows network programming issues. Due to TCP/IP's popularity, most of the questions have to do with TCP/IP, but questions about other network protocols are appropriate.

The main TCP/IP newsgroup is comp.protocols.tcp-ip. It is much broader in scope than the Winsock newsgroups: you will find discussions on network management strategies, Unix network programming, the odd interactions between DNS client X and DNS server Y, and other things that have nothing to do with Winsock.

You may also be interested in joining the Winsock 2 mailing list. This is a low-volume mailing list (10 messages a day or so) with many true Winsock experts on it.

If you have questions about specific application protocols see this FAQ item for pointers to resources you should find helpful.

Before posting questions to Usenet newsgroups or to mailing lists, search the relevant archives to see if your question has already been asked. Newsgroup and mailing list subscribers tend to be impatient with people who don't do this: it's a waste of their time to point you to places where you could have found the answer on your own. The Winsock 2 mailing list archives go back to the middle of 1996. Usenet also has several archives, the most popular being DejaNews.

1.4 - What versions of Winsock are available?

The latest version of Winsock (as of 2000.08.10) is 2.2.2. It is usually just called "Winsock 2" because later revisions just clarify and correct items in the original spec. The other major version out there is 1.1, which is good enough for most applications. (See below for a list of what Winsock 2 includes.)

All versions of Windows since Windows 95 come with Winsock. (Other OSes are covered below.) Windows 95 and Windows NT 3.x shipped with Winsock 1.1. Windows 98, Windows ME, Windows NT 4.0 and Windows 2000 ship with Winsock 2.

You can get a Winsock 2 update for Windows 95 from Microsoft's web site. If your development suite is also old, you may also need the Winsock 2 SDK, which you can get as part of the Win32 Platform SDK. (Sorry, there's no longer a place where you can get just the Winsock SDK.)

Windows 3.1 and Windows NT 3.x cannot support Winsock 2, due to kernel limitations.

Windows 3.x does not come with Winsock, but there are many add-ons available. Probably the two most popular options are Microsoft's Wolverine stack and Trumpet Winsock. There are several tradeoffs between these two options. Wolverine is free, works only with Windows for Workgroups 3.1, and only handles LAN connections. Trumpet is inexpensive shareware, works on all Windows 3.1 flavors, and can do LAN, SLIP and PPP connections.

Another option for Windows 3.1 is to install the 16-bit version of Internet Explorer 4.0. You can find this at the Evolt Browser Archive.

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.5 - 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". 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 FAQ's examples are console programs. Nevertheless, 16-bit DOS programs are still limited to DOS mechanisms, even when running in a Win32 console.)

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 only problem I have with it is that its API is nothing like BSD sockets, which makes for more of a learning curve than is strictly necessary. 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.)

There are several commercial BSD sockets libraries for DOS: JSB's Virtual Socket Library, NetManage's PC/TCP Software Development Kit and Async Systems's Socket Library SDK. The first two are purely commercial, and the latter you can download for a 90-day trial. I've not used any of these, so I have no idea how well they work compared to Waterloo TCP. However, the fact that they all offer the BSD sockets interface, a professional package, and support have to be a plus.

The four libraries I've just mentioned all use Crynwr packet drivers to access your network card. (They may also support other packet driver standards, such as NDIS or ODI.) This implies that these libraries are incompatible with Windows NT/2000, and may be difficult to make work under Win9x.

There is one other rather interesting alternative: the WSock library for the free DJGPP C/C++ 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. 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 the low overhead of a GUI-less program by writing a Win32 console mode program with the Cygwin tool set, which is essentially the same thing as DJGPP except for Win32.

...Windows 3.x? Windows 9x/ME? Windows NT/2000?

These are all covered above.

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

...WINE?

WINE the clean-room reimplementation of the Win32 API for Unix/Linux does have nearly-complete Winsock 1.1 support. Apparently the philosophy of WINE is, nothing gets added until someone needs it to support some program. As a result, WINE's Winsock 2 support remains vestigal.

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

...Macintosh?

NetManage sells a version of Winsock for Macintoshes, though it is no longer supported. The developer kit is $495, and there's a one-time source code license fee for $7,500. I'm not sure if you must get the source license or not, but since there is no support, it's probably a good idea.

Macintosh has its own networking API, of course, called OpenTransport. I'm told that it is somewhat like System V Unix's TLI, and therefore somewhat like BSD sockets as well. Also, because Mac OS X is derived from BSD Unix, it will have native BSD sockets support.

1.6 - 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.7 - When is the next rev of the specification due out?

The current revision (2.2.2) looks pretty durable to me. There are two things that could force Microsoft to create a new version of Winsock:

1. 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.
2. 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.

Winsock is in fact evolving slowly, and Microsoft is not documenting these changes with updates to the Winsock spec. (They are documented in MSDN, however.) Windows 98 and Windows 2000 variously added new features to Winsock, implemented some optional ones previously unimplemeted, and created new APIs (e.g. IP Helper) that complement Winsock without directly affecting it. It'd be nice to see these changes collected and standardized in a formal document like the Winsock spec.

The next likely time for major changes to Winsock is when Windows 2000 gets replaced. Your humble author is of the opinion that this will happen sometime in 2003.

1.8 - 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.