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()
• sen

Answer 1

For the sake of completeness, one should notice that whether it was about networking, files, time / dates or any other part of the ANSI C / POSIX APIs, MICROSOFT has spent a great deal of energy to make sure that its proprietary generations of Windows APIs are incompatible with the Unix APIs (that existed far before Windows).

The same strategy is used by MICROSOFT with HTML (IE), HTTP (IIS), OpenDocuments (MS-Word), etc. so the usual excuse that it is accidental (or only motivated by the desire to 'innovate') is more than doubtful.

Look at how much C# is a (bad) copy of Java - while at the same time managing to be completely incompatible (the function names are very close if not identical, but the number of parameters -or their order- is different).

Now you know why you had to ask this question in the first place.

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.

Answer 3

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 4

This is written in the MSDN documentation:

Renamed Functions

In two cases it was necessary to rename functions that are used in Berkeley Sockets in order to avoid clashes with other Microsoft Windows API functions.

Close and Closesocket

Sockets are represented by standard file descriptors in Berkeley Sockets, so the close function can be used to close sockets as well as regular files. While nothing in Windows Sockets prevents an implementation from using regular file handles to identify sockets, nothing requires it either. On Windows, sockets must be closed by using the closesocket routine. ON Windows, using the close function to close a socket is incorrect and the effects of doing so are undefined by this specification.

Ioctl and Ioctlsocket/WSAIoctl

Various C language run-time systems use the IOCTLs for purposes unrelated to Windows Sockets. As a consequence, the ioctlsocket function and the WSAIoctl function were defined to handle socket functions that were performed by IOCTL and fcntl in the Berkeley Software Distribution.