On Sat, 26 Dec 2020, Jacek Caban wrote:
Signed-off-by: Jacek Caban
---
I think it's reasonable to assume that the current default value of Windows
XP does not reflect reality. The new value deserves some considerations. I
propose to go all the way to Windows 10 and match Windows SDK.
The main concern about this is compatibility. This value is commonly mistaken
with 'minimum version supported in runtime', which is simply not the case.
It's only a version that headers will provide declarations for. As long as
the application does not use new APIs, its compatibility with older Windows
will not change.
In addition to hiding declarations, it can also affect how APIs that used
to exist are accessed.
A concrete case is psapi.h: I can include psapi.h and call
EnumProcessModules. If NTDDI_VERSION >= NTDDI_WIN7 when including the
header, the call to EnumProcessModules gets redirected to
K32EnumProcessModules which exists in kernel32.dll from win7. If I include
the header with a lower version defined, it ends up calling
EnumProcessModules in psapi.dll instead.
Likewise, the optional IPv6 APIs end up called via GetProcAddress based
wrappers. At least in official WinSDK (if I remember correctly and read
the headers right), these end up skipped if _WIN32_WINNT targets a high
enough version (but I think mingw-w64 headers always end up using the
compat wrappers).
A second concern is that the existing practice of build systems/configure
scripts probing for function availability, expecting the declarations to
be hidden if they aren't supposed to be used - VLC is one prime such
example, and many others work the same way.
And e.g. for that case, there's many different components that all can set
the version, with varying levels of precedence:
- The toolchain defaults. (E.g. in the case of llvm-mingw, the default is
Win7, as libc++ on windows requires that, so there's no point in targeting
anything below that.)
- The user's preference (if e.g. passing CFLAGS="-D_WIN32_WINNT=0x602" to
configure)
- The project's configure script. At least for the case of VLC, currently
it doesn't IIRC set anything if it's already predefined e.g. in CFLAGS,
but sets a higher version if the toolchain's default is lower than what
the project itself strictly requires. If the toolchain's default is higher
than the project required level, the version is not overridden to a
lower version.
So at least VLC would need some amount of tweaks to cope with the
toolchain defaulting to a higher version, or require everyone building it
to override the desired target version in CFLAGS.
But yeah, in practice this only affects projects that have optional
codepaths that can use newer features - except for the cases with e.g.
psapi.h.
I think that the change reflects expectations of majority of users.
I'm not entierely sure I agree with this - I think different ecosystems
have different expectations here. (It'd be interesting to e.g. rebuild all
of msys2's mingw package repository with such headers, and see how many of
them fail to run on the previous minimum version.)
If users still want headers to not provide Win10-only declarations, they
may just set _WIN32_WINNT explicitly in build system to the exact
version they want. If packagers prefer it the old way, they can use the
configure stitch for that.
Yeah, it's good that we're able to override the default - I think I'd
still keep doing that. But I think there's at least some amount of
projects (mingw centric projects primarily, as the default in MSVC is
different) that expect and rely on the current norm of it being set to the
minimum.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
