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

Windows Console Mode

Before I discuss alternatives to Winsock for DOS programmers, I want to clear up a common confusion. Command-line windows under modern versions of Windows are sometimes called “DOS boxes.” This is a historical term, and is now inaccurate. Modern Windows supports a class of programs called “console mode programs.” Such programs run in these “DOS boxes” and can look and feel like old DOS programs, but they can call any Windows API function, including Winsock. Note for example that most of the FAQ’s examples are console programs.

If you have a choice, I urge you to use real Winsock in a console mode program rather than one of the truly DOS-based alternatives that follow. The only ways I can think of that this is not possible is that you are either building a system that boots purely into DOS with no Windows at all, or that you are somehow stuck running DOS box programs under Windows 3.1. (Poor souls!)

Real DOS Alternatives

Still not deterred? Okay, you have several options.

Your first stop should probably be Richard Dawe’s dossock Mailing List page. There are many useful-looking resources here.

I have personal experience with only one of the options mentioned on that page, Erick Engelke’s Waterloo TCP package. This 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. I’m not aware of any that are still available, alas.

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

One final method I’ve found that looks interesting enough to call out by name is offered by Tattam Software Enterprises. These are the same folk behind Trumpet Winsock, which was at one time one of the more popular third-party implementations of Winsock for Windows 3.x systems.

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 Windows API for Unix/Linux including Winsock support. Years ago when I looked at this, they hadn’t gotten around to finishing their Winsock 2 support, but I expect that this has changed. I tried to verify it, but couldn’t find the tables showing the implementation status for the various parts of the Windows API. If anyone can point me to such resources, drop me a line.

Mac OS and iOS

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

iOS, being based on OS X, also supports BSD sockets.

The original stack for MacOS was called MacTCP, which first came out for System 6 (?) back in 1988. It was replaced in 1995 with Open Transport, which first shipped with System 7.5.2 and was available through Mac OS 9. Neither API is BSD-compatible, though since both were built to support TCP/IP, the concepts should transfer reasonably well.

Palm OS and webOS

The modern “Palm” OS is webOS, which is based on browsewr technologies. The nearest thing to Winsock you would expect to see in such a platform is WebSockets, which were not yet supported on webOS the last I checked. Lacking such support, the best you can do is use web protocols like HTTP and FTP.

webOS does have a Plug-in Development Kit which supports both BSD Sockets and a higher-level wrapper API. It means you have to write in C/C++ instead of JavaScript, however.

The “classic” Palm OS had a native network library that used 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.