Windows networking: are SOCKET's and file descriptors the same thing, such that file descriptor API can be used for sockets?

I’m compiling some old base network class code that’s always worked fine on both Linux and Windows 32-bit with older compilers, specifically Visual Studio 6.0 on Windows 95 up to 2016 or something on Windows 7. It’s had some conditional compilation to work on VMS, Solaris, Linux, and Windows (e.g., calling WSAStartup(), different headers, errno vs. WSALastError(), but it compiled without error (and without turning off all warnings) and ran fine.

Now re-compiling it for 64-bit required some changes and it passes g++ on Fedora 40 without warnings, but Visual Studio 2022 on Windows 11 is throwing up a huge amount of warnings that socket() and accept() return SOCKET not int.

My code has always worked fine in past decades on Windows using read() and close() for the return values of socket() and accept() but now I’m seeing at https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-functions that only recv() and closesocket() are documented.

The possibilities I can see are:

1. maybe SOCKET and a normal file descriptor are the same thing and interoperate perfectly and it’s just unfortunate that socket() and accept() return different types, but simply casting SOCKET to int is necessary and sufficient for say close() to be used instead of closesocket()? And if so, where does the documentation say that?

2. Were they perhaps the same in the past but starting with Windows 10 or with 64-bit they’re not? And if so when?

3. Does Windows present both API’s and I used to be getting API A and now get API B be default? So, I need to just define something before includes to get definitions where these functions return int not SOCKET? And if so what?

4. Were they never the same and it was a total fluke this code ever worked? And if so how?

5. Am I simply misremembering that this code worked? For instance, if it’s impossible for the code as written to have worked, maybe the applications with this code 15 or 20 years ago always used exit() and never actually called close(), or perhaps were logging that close() wasn’t working but no-one ever noticed since the app was running perfectly during the business day and only logging a warning or screwing things up at the point it was being shut down anyway? (I’m still nearly positive that it read SOCKET‘s with read() but maybe there was a subclass that overrode that default functionality?)

>Solution :

but Visual Studio 2022 on Windows 11 is throwing up a huge amount of warnings that socket() and accept() return SOCKET not int.

That is correct. They have never returned an int, always a SOCKET, which is an alias for UINT_PTR (unsigned int in 32bit, unsigned __int64 in 64bit).

My code has always worked fine in past decades on Windows using read() and close() for the return values of socket() and accept()

On Windows, that is not guaranteed to work, as a SOCKET is not a file descriptor.

but now I’m seeing at https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-functions that only recv() and closesocket() are documented.

Those are indeed what you should have been using all along.

• maybe SOCKET and a normal file descriptor are the same thing and interoperate perfectly and it’s just unfortunate that socket() and accept() return different types, but simply casting SOCKET to int is necessary and sufficient for say close() to be used instead of closesocket()? And if so, where does the documentation say that?

Some platforms do use file descriptors for sockets, but Windows is not one of them.

• Were they perhaps the same in the past but starting with Windows 10 or with 64-bit they’re not? And if so when?

No.

• Does Windows present both API’s and I used to be getting API A and now get API B be default? So, I need to just define something before includes to get definitions where these functions return int not SOCKET? And if so what?

No.

• Were they never the same and it was a total fluke this code ever worked? And if so how?

Yes.

• Am I simply misremembering that this code worked? For instance, if it’s impossible for the code as written to have worked, maybe the applications with this code 15 or 20 years ago always used exit() and never actually called close(), or perhaps were logging that close() wasn’t working but no-one ever noticed since the app was running perfectly during the business day and only logging a warning or screwing things up at the point it was being shut down anyway? (I’m still nearly positive that it read SOCKET‘s with read() but maybe there was a subclass that overrode that default functionality?)

My guess is that in Visual Studio, open() returns a file HANDLE casted to int, and passing an int to read() or close() will cast back to HANDLE to call ReadFile() and CloseHandle(), respectively. ReadFile() will accept a SOCKET from a Winsock provider (see Socket Handles), but CloseHandle() will not (its documentation explicitly says so).