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:
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?
Were they perhaps the same in the past but starting with Windows 10 or with 64-bit they're not? And if so when?
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?
Were they never the same and it was a total fluke this code ever worked? And if so how?
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?)
but Visual Studio 2022 on Windows 11 is throwing up a huge amount of warnings that
socket()
andaccept()
returnSOCKET
notint
.
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()
andclose()
for the return values ofsocket()
andaccept()
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()
andclosesocket()
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 thatsocket()
andaccept()
return different types, but simply castingSOCKET
toint
is necessary and sufficient for sayclose()
to be used instead ofclosesocket()
? 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
notSOCKET
? 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 calledclose()
, or perhaps were logging thatclose()
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 readSOCKET
's withread()
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).