Windows 以外のシステムの Winsock

Warren Young 著

このFAQは、Windows 上の Winsock に注目した、Winsock の使い方についてのFAQです。しか し、ネットワーキングというものは本質的にマルチプラットフォームな ものです。なので、Windows 以外でも、いくつかのプラットフォーム向 けには Winsock が存在するのです。Winsock が無いものでも、たいて いは似たような機構があります。

ここでの話に入る前にあらかじめ注意しておきますが、Winsock は、 Windows のメッセージ、DLL、I/O機構に非常に依存しているものです。 以下で述べる解決法には全て、Winsock に関する何らかの制限がありま す。以下の解決法のほとんどは Winsock のサブセットです。その他に ついては Windows の機構をエミュレートするための仕掛けで、これは 処理速度に影響が出るでしょう。

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.

I'm at a bit of a loss as to why you'd want to write DOS programs today unless you were stuck with legacy tools under Windows 3.1, since there is usually a migration path to 32-bit versions of these tools. For example, if you were using the DOS port of the GNU C compiler (DJGPP), you should be able to move to DJGPP's 32-bit relative Cygwin, which will let you write Win32 console programs. All of this FAQ's console-based basic Winsock examples are tested with Cygwin, in fact.

Still not deterred? Okay, you have several options.

Your first stop should probably be Richare 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 mainly 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 over Crynwr-style packet drivers. 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 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 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, though.

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. These libraries are therefore incompatible with Windows NT/2000, and may be difficult to make work under Win9x.

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

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.

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. Since the philosophy of WINE is that nothing gets added until someone needs it to support some program, WINE has almost no Winsock 2 support.

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 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 MacOS X is derived from BSD Unix, it will have native BSD sockets support.

PalmOS

Palm Platform devices can use sockets. The native Palm network library is somewhat reminiscent of 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. For CodeWarrior, I'm sure there is an equivalent library, but I don't know what it is called. (Probably NetSocket.lib, but that's just a guess.)