Stop supporting Windows XP and Windows Server 2003 from OpenSSL 3.1

[mattcaswell]

Background:

Our platform policy makes no reference to old versions of Windows. The primary Windows platforms are listed as "VC-WIN64A" and "mingw64" both on Windows 10. There are no community supported Windows platforms. There are a number of Windows platforms in the "unadopted" list - but none of them specify a specific Windows version that they apply to.

In the code we define the macro _WIN32_WINNT to the value 0x0501:

https://github.com/openssl/openssl/blob/4c149cf9f6a2ba665d74dbd4cf44f080816c900b/include/internal/e_os.h#L85-L100

According to the Microsoft documentation this corresponds to Windows XP:

https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170

This means that (by default) we are unable to use functions introduced later than that in the code. We do have some conditionally compiled code which checks the value of _WIN32_WINNT and, if it is sufficient high, uses more recent functions. It is possible to override the default value at Configure time (e.g. perl Configure -D_WIN32_WINNT=...) - but this possibility does not seem to be documented and it seems unlikely that many people do this.

PR openssl/openssl#18270 proposes updating the default value of _WIN32_WINNT to 0x0600 which would exclude Windows XP and Windows Server 2003 users. Microsoft ended support for Windows XP in April 2014 and for Windows Server 2003 in July 2015.

According to this tweet, 5.6% of Windows curl users say they use it on Windows XP:
https://twitter.com/bagder/status/1534465987269083136

Proposal:

This issue is proposing the following vote text in order that PR openssl/openssl#18270 may proceed:

"We will no longer support Windows XP or Windows Server 2003 from OpenSSL 3.1"

(Note: I am not actually calling this vote yet - just gathering feedback).

[t8m]

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

[hlandau]

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.

[vdukhovni]

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).

[hlandau]

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.

[mattcaswell]

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?

[hlandau]

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

[rsbeckerca]

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.

[paulidale]

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

[mattcaswell]

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.

[mattcaswell]

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.

[hlandau]

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.