change minimal supported Windows version for OpenSSL 4.0
There is a draft PR #29585 which suggests a minimum supported Windows version to be Windows 10 and Visual Studio 2017. I think the decision whether OpenSSL should go for it should be made at advisory board.
The supported Windows version is driven by macro `_WIN32_WINNT`, which controls binary compatibility with the Windows API. It basically defines the minimal required version for the runtime.
The required compiler can be determined by `_MSC_VER`, which is typically checked at build time (it's part of the build environment)
People on github seem to lean towards combination Windows 10 (_WIN32_WINNT 0x0a00) and microsoft visual studio 2017 (`_MSC_VER` 1910) to be versions required for 4.0
This yeilds two questions:
what should be minimal required version to run OpenSSL:
a) do nothing keep WindowsXP a default, meaning OpenSSL with default build settings will continue to run on WindowsXP
b) change `_WIN32_WINNT` macro defintion in OpenSSL such that Windows 10 will be the default. meaining OpenSLL with default build settings will run on Windows 10 and later. Users will still be allowed to override OpenSSL default by providing `_WIN32_WINNT` defintion at compile time.
c) drop support for WinXP completely, the new minimal version to run OpenSSL 4.0 will be windows 10
d) something else.
SImilarly for build environement. What should be the `_MSC_VER` for openssl. 4.0? the list is here
https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170
is 1910 (Microsoft Visual Studio 2017) acceptable?
Sasha Nedvedicky Wed 14 Jan 2026 1:16PM
It looks like there are no issues for OpenSSL to keep WinXP supported as we currently do. The only thing we need to be aware of is the case I'm describing here https://github.com/openssl/openssl/pull/29614 (the current defaults keep around code we don't compile in CI)
From technical perspective there is no issue to keep WinXP supported as we do know. I'm just asking because the upcoming major release is good opportunity to change that.
From developer perspective we should perhaps move to more modern tool chain (Visual Studio 2017) as C-99 constructs tend to sneak in occasionally. I have no idea how those are supported in older studio versions so here I would prefer to require ate least Visual Studio 2017 to build openssl 4.0.
Sasha Nedvedicky Wed 14 Jan 2026 1:24PM
@Tomas Mraz this is fine with me. I hope someone with real case scenario for OpenSSL@Windows will show up to bring some light here.
Nicola Tuveri Wed 14 Jan 2026 1:45PM
I am expecting the major users of OpenSSL on winxp are maintainers of industrial and safety critical appliances. As mostly I still see winxp machines operating in specialized machinery in factories and hospitals.
Nuclear plants also infamously run on windows xp, allegedly 🤣
I am just wondering what is the best channel to reach those stakeholders, maybe the OpenSSL Corporation through its support channels has the most visibility and ability to reach these users? Not sure how likely it is that this platform has a chance to reach them.
Richard Levitte (individual) Thu 15 Jan 2026 4:06PM
Dropping support for WinXP is one thing.
Making Windows 10 the minimum supported version is a whole different thing.
There are a lot of folks and organisations that still run (covet, really) Windows 7. That version is somewhere between WinXP and Windows 10.
Sasha Nedvedicky Fri 16 Jan 2026 4:12PM
IMO tje value _WIN32_WINNT should be changed to 0x0A00 so default build configuration for openssl produces library and tools which require at least windows 10. The code which allows OpenSSL to run on older versions should be kept, Anyone can enable that at build time. There is more detailed answer/explanation here
Peter Gutmann Sat 17 Jan 2026 1:11PM
The issue isn't the client, it's the server. There are quite a few places still on Server 2008.
Marcel Raad Mon 19 Jan 2026 9:56AM
In my experience, targeting Windows 10 via `WIN32_WINNT` is problematic. For the Windows SDK, it means "only the latest version of Windows 10/11 the Windows SDK supports" (see sdkddkver.h in the Windows SDK), which often comes as a surprise, especially in CI builds when the Windows SDK is automatically updated and older Windows 10/11 target versions are not tested anymore.
That's why we still target Windows 8.1 (`_WIN32_WINNT=0x0603`) even if we don't support it anymore. There is the alternative of using `NTDDI_VERSION`, but the last time I checked, that led to compile breaks in parts of the Windows SDK and in other libraries which didn't support it properly.
Matt Caswell · Wed 14 Jan 2026 11:36AM
@Sasha Nedvedicky Are you able to describe what the impact of continuing to support Windows XP is? Why is it a bad thing to continue to support it?