Stop supporting Windows XP and Windows Server 2003 from OpenSSL 3.1 about general-policies HOT 11 OPEN

I don't think we should drop XP support yet.

I think adding extra CI for 0x0501 to prevent bitrot is the right thing to do.

from general-policies.

What about defaulting to _WIN32_WINNT=0x0600 but still allowing to override it with perl Configure -D_WIN32_WINNT=0x0501 ?

from general-policies.

Note that I don't think it follows that defining _WIN32_WINNT as 0x0600 means we can't support XP, it just means we can use Vista features. So if we probe for availability of those features at runtime and have fallback code, we can still support XP. My code does this.

Probably the best option here is to default _WIN32_WINNT to 0x0600 but have an extra CI build with it set to 0x0501 so we can demonstrate it still works without the functionality only available in later OSes. So strictly speaking, we don't need to end support for XP.

from general-policies.

A user selecting an outdated OS can surely also select an outdated OpenSSL release. Dropping XP support in OpenSSL 3.1 seems quite reasonable to me if there's a tangible benefit to raising the minimum supported OS version (i.e. API improvements that simplify or improve the code).

from general-policies.

The reason we want to do this is to use WSARecvMsg which was introduced in Vista. But we have to have a fallback to sendto/recvfrom for other platforms anyway, so we don't simplify the code by doing this. In fact requiring Vista wouldn't even let us remove the dynamic probing for this functionality, because peculiarly in order to use WSARecvMsg, you have to invoke an ioctl on a socket to get a function pointer to it (...). It's not exported as a symbol. So we already have to do the work to load it dynamically.

If there were sufficiently compelling reason to drop support for XP that might be one thing, but I don't see any reason to just for this. I think we can bump to 0x0600 and continue to support XP, which is what I suggest.

from general-policies.

Since you have to probe to get a function pointer - why is that impacted by _WIN32_WINNT anyway? Isn't that more about what is exposed in the header files?

from general-policies.

We do need the structures and function pointer typedefs exposed in the header files.

To be specific, we need it for WSASENDMSG, LPFN_WSASENDMSG and WSAID_WSASENDMSG. It is not required for WSAMSG, LPFN_WSARECVMSG or WSAID_WSARECVMSG.

https://github.com/hughbe/windows-sdk-headers/blob/e83bf2af3df09ec5420725bd79ccfe1bb534722c/Include/10.0.18362.0/um/MSWSock.h#L510
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/include/mswsock.h#L216

from general-policies.

Just as an observation, I think you might find that Windows 2003 Server SBS is still used rather widely based on licensing and hardware support changes from Microsoft over the years.

from general-policies.

If we drop XP support, we ought to consider dropping a lot more: HP's PA-RISC is of a similar vintage e.g.

from general-policies.

Note that I don't think it follows that defining _WIN32_WINNT as 0x0600 means we can't support XP, it just means we can use Vista features.

Another observation here is that there is a difference between what machines we build on, and what machines we run on. Presumably increasing _WIN32_WINNT will mean that we will no longer build on XP because we need the header file typedefs etc that were not available on XP?? We would still be able to run on XP because of the runtime detection that @hlandau has in his PR.

from general-policies.

If we up the default _WIN32_WINNT it may mean that it will still work on XP due to the run time detection - however unless we test that it is likely to rot and break over time.

We could add a CI build that defines a lower value for _WIN32_WINNT at Configure time to check that it still builds. But if we do that are we effectively making XP/Windwows Server 2003 primary supported platforms? If so, should we be doing that? Or instead do we just say that XP/Windows Server 2003 are unadopted and therefore not tested. That might inspire a community member to step forward as an XP platform maintainer - or alternatively no one in the community cares and it withers away and dies.

from general-policies.