@Neil Horman Our platform list is not a list of what works - it is a list of what we are actively (in theory) supporting. Our communities run across a much larger range of platforms than we do.

@Tim Hudson I respectfully disagree here. Not specifically with the cost/benefit assertion of keeping support for older windows versions where feasible, but rather with the assertion that we truly support it at all, in any meaningful way (be that an official support statement or simply a community "you should be able to get it working" statement)

By way of evidence, I went and setup a virtual machine running windows xp and Visual studio 2010 (the latest version that ran on winxp, obtaining both of which required downloads from the internet archive, which is neither here nor there, but is somewhat amusing).

I built our various stable branches, starting at 3.0, up to 3.6. Every branch, except for openssl-3.5 fails to build, due to the use of windows or other header files that don't exist on windows xp. For the openssl-3.5 branch, which happens to have landed on a state of the source tree that does build, every single unit test segfaults when running the test suite (I didn't dig into the root cause of why there), though I think it further speaks to the lack of any meaningful support on this platform.

What that implies to me is two things:

1) That every change we make is assumed to not impact this platform (or more specifically we're not really worried about the impact we may have here)

2) Since the release of at least 3.0, users of Windows XP (a) havent noticed this breakage or (b) have been toiling on their own to keep it functional

If (2)(a) is true, then that suggests that windows xp developers aren't actually using our more recent code, in which case this becomes more of question of whether we need to keep what is already broken code around.

If (2)(b) is true (which may well be the more likely scenario), those individuals are operating in an environment in which they already know they need to maintain a pile of code on their own. There can't be an expectation on those developers part that we will do anything to make that task easier, unless, they get involved with the community to call out their need for that assistance. Without that, any statement of support (be it official, or just "yeah, it should work" isn't particularly meaningful).

To your points below, yes, aws-lc, rust, etc maintain function on older windows releases, which is great. But they're taking on the required responsibility of being able to assert that support by running the appropriate ci jobs to ensure continued function in those environments. In the absence of a community support volunteer to ensure that this platform remains viable, any statement of support is really just saying "it works...maybe", which isn't really helpful to anyone.

We could of course be our own community volunteer and commit to that work on our own. I'd in fact be supportive of such a move if the consensus was that we believe that there is sufficient need in the community for it.

Perhaps that's a better way to couch this question. Instead of "Do we want to get rid of windows xp support?" we should instead be asking "is there sufficient need to support this platform that we are willing to to ensure its viability?" Without making that commitment, any statement of support (no matter how weak/loose) just isn't really true.

@Tim Hudson see my detailed answer further below. my preference here is to change the default value we use for _WIN32_WINNT to 0x0A00 so default build settings will require Windows 10 or later. People who need OpenSSL for older version should be using their own compile time settings.

@sashan, point is, there's a reference to #29585, and in that PR, you do much more than merely update the default value.

Do you mean to say that this vote is only about this default value, or does it still imply the removal of code in that PR?