Winsock for Non-Windows Systems

by Warren Young

This FAQ is about using Winsock, with the focus of using Winsock on Windows. However, networking is inherently multiplatform, so many people writing Winsock programs also need to write programs for another platform. This article is about Winsock work-alikes on other platforms, and the alternatives to Winsock on these platforms.

Before I begin, I want to point out that the Winsock API depends greatly on Windows' messaging, DLL, and I/O mechanisms. All of the Winsock work-alikes mentioned below have limitations with respect to Winsock. Most of the solutions below are a subset of Winsock, and others manage to emulate Windows mechanisms, with an associated speed hit.

DOS

Before I discuss alternatives to Winsock for DOS programmers, I want to clear up a common confusion. Command-line windows under 32-bit versions of Windows 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 most of the FAQ's examples are console programs. If at all possible, I urge you to use Winsock under Win32. The only way I can think of that this is not possible is if you need to use pure DOS, or if you are somehow stuck running DOS box programs under Windows 3.1. (Poor souls!)

Still not deterred? Okay, you have several options.

Your first stop should probably be Richard Dawe's dossock Mailing List page. Aside from letting you subscribe to a mailing list about using sockets in DOS, it also has lots of very useful-looking links.

The dossock mailing list is centered around two rather interesting libraries that interface to the VxD drivers used by Microsoft's Windows for Workgroups 3.1 and Windows 9x Winsock stacks. (They can also work under Windows NT with a bit of help from a shim you can find via the mailing list link above.) These drivers only work while Windows is running, so you can't use these interfaces in pure DOS mode, unlike the options below. The first of these interface libraries is the WSock library, and the second is called libsocket. The latter was written because WSock reportedly is not being maintained any more, does not work with Winsock 2, and has some other lesser problems.

There are several other options if your DOS program cannot run under Windows:

Erick Engelke's Waterloo TCP package is a freeware TCP/IP stack that runs under DOS. I used this library myself years ago, 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 library itself is free to use, but they charge you if you want a programmer's manual. 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 spending lots of time messing around with the example programs.)

There is an extended version of WatTCP called Watt-32. Among other things, this adds support for 32-bit protected mode DOS and a BSD sockets API. I haven't used this version, so I can't comment further on it.

There used to be several commercial BSD sockets libraries for DOS. The only one I'm aware of that's still available is Async Systems's Socket Library SDK. You can download it for a 90-day trial. I've not used it, so I have no idea how well it works compared to Waterloo TCP. However, the fact that it offers the BSD sockets interface, a professional package, and support has to be a plus.

WatTCP and Async System's library both use Crynwr packet drivers to access your network card. Becuase of this, you can't run these stacks under Windows NT derivatives, and it requires jumping through some hoops to make them run under Windows 95 derivatives.

There is one final mechanism that I recently stubled across. Trumpet Software, the makers of a popular alternative Winsock for Windows systems, has documented a method for using TCP under DOS, with an emphasis on using the Internet via SLIP, rather than a LAN connection. This approach looks a little sketchy to me, but it may be useful for you.

Unix

All modern Unixes offer BSD sockets, the ancestor of Winsock. All of the calls not beginning with "WSA" are in BSD sockets, either directly or with some small name change. See this FAQ article for details.

Older versions of System V Unix had a competing API called XTI. (Also called TLI in its older form). XTI is similar enough to Winsock and BSD sockets that you won't have much trouble learning it if you know the sockets API, but you should only use it if BSD sockets are unavailable or broken on your system. XTI is a dead API.

There's also the WINE option. WINE is a clean-room reimplementation of the Win32 API for Unix/Linux including nearly-complete Winsock 1.1 support. Winsock 2 support lags somewhat behind, but it's getting better.

Macintosh

OS X is based on BSD Unix, so naturally it has BSD sockets support.

The original stack for MacOS was called MacTCP; as I recall, it first came out when System 7 was current. Then in later versions of the OS, Apple replaced that with OpenTransport. These two APIs aren't exactly like BSD sockets, but I'm sure the concepts translate reasonably well.

NetManage used to sell a version of Winsock for Macintoshes. If you must have Winsock compatibility, it might be worth talking to them to see if they can sell you a license to this now defunct product. Last I heard, a license for this cost big money and there was no support.

PalmOS

Palm OS has a native network library that uses different function names from BSD sockets, but newer SDKs have a wrapper that lets you use plain old sockets calls. Most of these are #defines in the SDK file Core/System/Unix/sys_socket.h. There are a few other calls (e.g., select()) that are implemented in a glue function. If you're using the PRC-Tools toolchain, you get this in your program by linking with the libNetSocket.a library.

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.

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