Why are there WSA pendants for socket(), connect(), send() and so on, but not for closesocket()?

Question

I'm going to try to explain what I mean using a few examples:

• socket() -> WSASocket()
• connect() -> WSAConnect()
• send() -> WSASend()
• sendto() -> WSASendTo()
• recv() -> WSARecv()
• recvfrom() -> WSARecvFrom()
• ...
• closesocket() -> WSA???()

This is nothing that matters much, but is still something that gives me a splitting headache.

Answer 1

To understand this, you have to realize that Winsock was created in the early 1990s, back when the Windows 3.x dinosaur roamed the earth.

The Windows Sockets ("Winsock") API mirrors most of the BSD sockets API: where both provide a given function, both do the same thing. So, socket() is the same call under both APIs. There are minor differences in places, but nothing bigger than the differences in network programming for other systems based on BSD sockets, such as Linux and OS X.

In addition to implementing that common base API, the Winsock API also provides many extensions to BSD sockets. Many have names similar to the original functions, but with a WSA prefix and camel-case for everything else. These are purely extended versions of the original functions, not replacements for them. You pick which one to use depending on whether you need the extended functionality and whether your program has to be portable to systems that provide only the BSD sockets API. For instance, WSASocket() takes the same parameters as socket() plus three additional ones which have to do with other Winsock extensions. If you do not need the extensions, there is no real penalty to calling socket() instead, and you get a portability benefit besides.

In addition to these simple extensions, there are Winsock extensions that have no direct BSD equivalent, such as WSAAsyncSelect(). These generally have to do with differences in the way Windows programs are written, as compared to programs for Unixy systems. In this particular case, WSAAsyncSelect() exists to make it easier to write single-threaded GUI programs that use sockets without network I/O blocking the GUI or vice versa. This is useful today, but absolutely critical to Winsock's success back in the Windows 3.1 days, which didn't have threads or other useful multiprocessing and IPC mechanisms.

That leaves only a few oddballs like closesocket() and ioctlsocket().

closesocket() is the same as close(2) under POSIX/Unix, except that it only takes sockets, not file handles. That's part of the reason for the name change, but the real reasons come from that early-1990s history issue I brought up above. In those days, some Windows compilers — there were more available then than today — included POSIX API equivalents to ease porting code from other platforms to Windows. Such features were very limited, and didn't include sockets support, but nevertheless, the close() function name was considered "taken" on Windows at that time. It isn't true any more, but Winsock is a product of its history and can't be changed now.

The story for ioctlsocket() vs. ioctl() is similar. One big difference is that ioctlsocket() is greatly limited on Windows as compared to what ioctl() can do on a Unix system. It exists only to provide Windows with a few network-related facilities that the original Winsock creators thought useful in the BSD sockets API. Over the years, much of what you can do with sockets and ioctl() on Unixy systems but not with ioctlsocket() has been added to Windows through other APIs, just one of which is WSAIoctl().

I've written an article on "The History of Winsock" for the Winsock Programmer's FAQ (which I maintain) that goes into more detail on all this. Another relevant article is "BSD Sockets Compatibility."

Answer 2

closesocket is only available on Windows, I'm not sure why they didn't follow the WSA convention there though. If it really bothers you though you can make your own wrapper that calls closesocket.

As mentioned in WSASocket a call to closesocket should be made.