Drop legacy Windows support
Igor Ustinov
Thu 15 Jan 2026 9:43PM
Public
Seen by 78
The pull request #29585 was published on GunHub, this pull request proposes keep OpenSSL support only for Windows starting from Windows 10, i.e. drop the support of Windows XP and Windows 7.
As your representative in the Foundation TAC, I ask you to express your opinion on this proposal. Is it acceptable in 2026 not to pay attention to WinXP and Win7, or are these systems still in use and should be supported?
Matthias Kraft Thu 15 Jan 2026 9:57PM
May I remind everyone that even Windows 10 is already out of support. OpenSSL 3.5 still accommodates this legacy stack, and as an LTS release it will remain available for a while. This provides a window of opportunity to finally move away from these operating systems. At this point, absolutely nothing should be running on these Windows versions in any networked environment. Not even air‑gapped.
This is, of course, my personal opinion.
Maikel Mardjan Thu 15 Jan 2026 9:57PM
From a security and maintenance point of view: I can not think of a valid reason that someone still should support MSWindows <10 versions. Migration should be done for companies/people still using such an old MS platform.
Santosh Pandit Thu 15 Jan 2026 9:57PM
Active encouragement to users to move to Windows 11 and we should support until they do so.
Tim Hudson Fri 16 Jan 2026 1:25AM
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.
Sasha Nedvedicky Fri 16 Jan 2026 3:49PM
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.
Tim Hudson Fri 16 Jan 2026 10:17PM
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.
Sasha Nedvedicky · Tue 20 Jan 2026 6:34AM
@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.