Drop legacy Windows support

@Richard Levitte (individual) I would contrain this vote about changing the default for _WIN32_WINNT: what windows version the default build options should support.The PR is draft and will be updated once decision will be made.

And for a topical post - AWS-LC on Windows 7 - code about to go in to make sure it works. See https://github.com/aws/aws-lc/issues/1997

There is also a PR for the change. And commentary around it.

And Rust when updating OS PRNG usage code ensured that Windows 7 still works.

https://github.com/rust-lang/rust/pull/121337

And if you want a set of platform definitions to look at and a set of tiers that make it clearer the sort of platforms still in widespread use:

https://doc.rust-lang.org/beta/rustc/platform-support.html

The Rust platform policy is also nicely written IMHO.

https://doc.rust-lang.org/beta/rustc/target-tier-policy.html

I mention these mostly for some broader context.

There are at least two details that need to be taken into account:

• minimal required version where OpenSSL library and tools will be running (a,k.a. runtime)

• minimal required version for MSVC (compiler and tools) required to build OpenSSL source code

the runtime requirement is controlled by _WIN32_WINNT macro which is explained here. OpenSSL currently uses value 0x0501, which constrains resulting binary to WinXP APIs. Anyone can change (override) default value defined by OpenSSL at build time by passing option '-D_WIN32_WINNT=0x0A00` to `Configure` command. Doing this changes minimal required version where OpenSSL binaries will run to Windows 10. The only difference I'm aware of in OpenSSL is that library uses `BCryptGenRandom()` in ossl_pool_acquire_entropy() (see: providers/implementations/rands/seeding/rand_win.c). So my personal preference here is to just change OpenSSL default for _WIN32_WINNT to 0x0A00 so default build settings produce OpenSSL library Windows 10 and later. The users who wish to procude OpenSSL library which will run on older Windows than 10 will have to use -D_WIN32_WINNT=... with desired value at build time to obtain OpenSSL suitable for older versions. Keeping code which allows OpenSSL run on older windows costs OpenSSL nothing it can stay. I would just change the default value.

The Microsoft Visual Studio tool chain version is determined by macro _MSC_VER macro. It can be used to restrict minimal Visual Studio required to build OpenSSL sources. Given OpenSSL has moved from ANSI-C to C-99 I feel the project should consider to move minimal Microsoft Visual Studio compiler to more recent version. My persnal preference is to require Visual Studio 2017 (_MSC_VER >= 1911) My only reason is that we can expect more modern C99 language features to gradually sneak in to OpenSSL-4.0 and I'm just concerned it may caught older tools in surprise. hnece I prefer to be honest upfront saying your tool must be _MSC_VER at least 1911. Whether to keep or drop code for branches we have for older studio version is yet another question.

given the question is wher WinXP should be supported, then I think yes it should but not as a default compile time settings.

Our code should dynamically detect the runtime version and use the latest RNG stuff available. Then this is a "non-issue" and a better result. There are three interfaces in recommended order - and by default we use only the oldest. Making it runtime check is the right outcome - but we haven't yet done that.

Moving forward Visual Studio versions is a major issue - like the OS - and we aren't planning to use any C99 features that aren't widespread - so I would be seriously hesitant to leap forward. I have active customers from Visual Studio 2005 up to Visual Studio 2026 (and there are reasons of course for each customer to decide at what point in the Visual Studio series they are stuck. VS 2010 started C99 features. VS2019 is mostly complete. So we have already basically orphaned older VS compiler users for OpenSSL 4.0.

https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170 is the "official" reference for that.

@Tim Hudson I agree runtime detection is better option.

Speaking of Visual Studio version, I wonder why people are stuck on old tool to build OpenSSL. Is it because Visual Studio (let's say 2017) produces code which is so much different to output from VS 2005? It feels like people are relying on some feature/bug in VS 2005. I'm just being curious here.

IMO, OpenSSL should shift to Windows 10 as the default and remove support for Windows XP/7. As mentioned by @Neil Horman , builds are already failing (from 3.0 to 3.6, except for 3.5, which itself shows segmentation faults in all test cases, note: reasons unknown). If the intent is to keep supporting these legacy systems, then proper support should be added and tested against them. However, doing so without knowing the actual user base does not seem reasonable, especially considering there have been no concerns raised on github or other platforms (not 100% sure, please mention if someone has) regarding issues or errors on Windows XP/7 systems related to OpenSSL 3.x releases.

If there are users still relying on these legacy systems, they are likely either using very old OpenSSL LTS versions or maintaining their own downstream changes. In either case, it does not make much sense for OpenSSL to continue supporting them upstream.

Second, I also agree with @Nicola Tuveri that making a decision on this matter is quite late for the 4.0 release, and I believe this idea should instead be considered as part of a subsequent release.

I'm going to close the PR/draft so windows bits are kept as they are now. I don't feel strongly about the change, I just saw upcoming 4.0 release as opportunity to make those changes as I feel changes like this should be landing to major release only.

Also quick look at poll shows there is no strong desire to change that currently 33 out of 123 people participated in poll.

I am not going to make a specific choice, because I haven't built any code for Windows for quite some time now, and haven't looked at what it takes to support Windows in general, or any specific version of Windows in OpenSSL. So any choice I'd make would be entirely uninformed.

That said, if there's a cutoff at which:

• We'd be able to shed a substantial body of code or build complexity

• The abandoned versions are unsupported by Microsoft and by open-source projects that use OpenSSL.

Then I'd be inclined to support that cutoff.