Winsock Programmer’s FAQ
Articles: BSD Sockets Compatibility
by Warren Young
So you say you’re a long-time Unix hacker who’s new to
Windows programming? And you’ve heard of this great API called
Winsock that’s compatible with your beloved BSD sockets, but try
as you might, you just can’t find the
readv() call? Well
bunky, this is the article for you.
In the beginning, there was chaos in the world of Windows TCP/IP APIs. A program written for, say, FTP Software’s TCP/IP stack wouldn’t run on JSB’s stack.
Then, sometime in 1990, a bunch of people got together and decided to make one nice, big, compatible API called Windows Sockets that would allow a single program to run on any vendor’s stack. They decided to base this API on the popular BSD sockets model of network programming, but for various reasons, there are still many differences between Winsock and BSD sockets. This article points out how Winsock differs from BSD sockets, and how to translate BSD sockets programs to use similar Winsock functionality.
The Winsock API documentation has a section called Porting Socket Applications to Winsock that covers many of the same issues that this article does, and a few others besides.
Under BSD sockets, there are quite a few different header files you need to include, depending on what sockets calls you use. A typical BSD sockets program has a block of #includes near the top like this:
For Winsock, you don’t need any of these. Instead, you just need to include winsock.h. (Or, if you need Winsock 2-specific functionality, winsock2.h.)
WSAGetLastError() is essentially the same thing as
errno global variable. The error constants and
their values are different; there’s a table in the Winsock
spec where it lists all the error constants, one column of which
shows the equivalent BSD error constant for a given Winsock error
constant. Usually the difference is just the addition of "WSA" to the
beginning of the constant name for the Winsock versions. (E.g. WSAEINTR
is the Winsock version of BSD’s EINTR error constant.)
Another thing to keep in mind is that, although the
call exists in most Windows compilers' run-time libraries, it
doesn’t work for Winsock calls. (This is a consequence
of Winsock not returning its error codes in the
variable.) There is a function called
in the basic Winsock examples area of
the FAQ that you can use to build a
It’s in the ws-util.cpp module.
Many Unix programs, especially those with System V roots, check
for the EAGAIN value in the global
errno variable when
a non-blocking call fails. This is the same thing as BSD’s
EWOULDBLOCK and Winsock’s WSAEWOULDBLOCK errors. You’ll
have to check your system’s header files, but all Unixes
I’ve checked on this matter #define EAGAIN and EWOULDBLOCK
to the same value, so you may want to get into the habit of using
EWOULDBLOCK instead of EAGAIN under Unix, to make transitions to and
from Winsock easier.
Under Unix, the I/O system calls work with file descriptors and
socket descriptors equally well. For example, the only reason to call
recv() on a socket instead of
read() is when you need to set
one of the flags allowed in the fourth parameter to
The situation is the same under all
modern versions of Windows, except
that the functions are named differently:
ReadFile() instead of
read(), for example.
That said, if you need portability between BSD sockets and Winsock,
it’s much easier to rewrite a program using
read() and such
with sockets to use portable functions like
recv() than it is to
arm-twist the Windows port to work with Unix idioms.
Winsock defines a different function for closing sockets because not all versions of Windows have file descriptor and socket descriptor equivalency like Unix. See the discussion in the previous item for more on the file/socket handle mismatch issue.
Unix provides the
ioctl() call to allow you to set and get
various bits of info on a file descriptor, which includes socket
descriptors. Winsock replicates some common Unix ioctls in the
ioctlsocket() call, but much is missing.
If you use the
SIOCGIFCONF ioctl on Unix to
get information about the system’s network interfaces,
Winsock 2 provides very similar functionality with its
SIO_GET_INTERFACE_LIST option for
fcntl() call has no direct equivalent
under Winsock. Where necessary, similar functionality exists
ioctlsocket() call. For example, the
equivalent of using Unix’s
fcntl() to set a socket’s
O_NONBLOCK flag is setting the FIONBIO flag with
There are several wrappers for
select() out there. Here’s
one. It doesn’t attempt to implement any of the special
poll() features found in a true System V system, such as
STREAMS support. Also, the code is rather old, written in a K&R
C style that some newer compilers might reject. Finally, since
it is built directly on top of
select(), it has the same
Another option is to dig the implementation
poll() out of Jarle Aasa’s Win32 port of the adns
library. This implementation has three limitations: 1) It’s GPL’d, which
means you can’t use the code in your program unless your program
is also licensed under the GPL; 2) it’s built on the Win32 event
object mechanism, which has a hard
64-object limitation; and 3) it is reportedly not written in a
way that is easy for third-party programmers to extract and use.
Winsock 2’s overlapped I/O mechanism includes scatter/gather
functionality similar to that provided by
dup() function duplicates a file handle, and
of course also works for sockets. Under Winsock 2, you can do the
same thing with
WSADuplicateSocket(). It’s a bit more
involved, but the
WSADuplicateSocket() documentation in MSDN has a good step-by-step
example showing how to use this mechansim.
There is partial support for this feature under Winsock, though the
mechanism is dissimilar to the
dup2() feature. Under Unix,
dup2() takes a handle and duplicates it like
dup() does, but
with a twist: it assigns the new file handle a value that you specify.
This is usually used to map a socket to the C language’s stdin or
stdout file descriptors so that you can use standard I/O functions like
fgets() with the socket.
Item KB190351 in the Microsoft Knowledge Base documents a method by which you can redirect a child process’s standard descriptors to a socket. The limitations are that you cannot do this to your own process’s descriptors, you cannot redirect arbitrary descriptors to a socket (i.e. you can only do it with stdin, stdout and stderr), and not all processes are fully compatible with this API feature. Still, it at least makes an inetd-like program possible under Win32.
Under BSD Unixes, if the remote peer closes its connection
and your program is blocking on
recv(), you will get
a 0 back from
recv(). Winsock behaves the same way,
except that it can also return -1, with
WSAESHUTDOWN, to signal the detectable flavors of
Under Unix, if you’re blocking on
send() and your
program is ignoring the
SIGPIPE signal, it will return
with a -1 when the remote peer disconnects, and
EPIPE. Otherwise, your program will be sent the SIGPIPE
signal, which will terminate your program if you don’t handle
it. Under Winsock, the SIGPIPE/EPIPE functionality does not exist at
send() will either return 0 for a normal disconnect or -1
for an abnormal disconnect, with
the same errors as in the
recv() discussion above.
According to Ilpo Ruotsalainen, "...most BSD socket implementations
do not pass delayed UDP errors (ICMP port unreachable at least, maybe
others too) to
recvfrom() while Winsock 2 [under Windows 2000
but not Windows 98] does. Linux [behaves like Windows 2000] too,
but provives SO_BSDCOMPAT
setsockopt() for being compatible
with the BSD style."
In other words, a portable program has to be prepared for
the possibility of error codes for non-immediate problems from
recvfrom(), but it can’t depend on receiving them.
<< The Straight Dope on Packet Sniffers
||WsControl() Revealed >>|
This article is copyright © 1998-2016 by Warren Young, all rights reserved.
|Updated Thu Mar 24 2016 12:31 MDT||Go to my home page|