On 28.12.2020 23:23, Martin Storsjö wrote:
On Mon, 28 Dec 2020, Jacek Caban wrote:
As long as the application does not use new APIs, its compatibility
with older Windows will not change.
And this bit:
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.
https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt
says
The preprocessor macros WINVER and _WIN32_WINNT specify the minimum
operating system version your code supports.
Yes, but the critical part is the very first sentence, which says that
'you can specify which versions of Windows your code can run on.'. Note
the difference between *can* and *need*. When using mingw-w64 with its
defaults, you essentially *need* to do that if you're working on a
modern application. That article is about changing the value, not about
the meaning of its default value. The current difference between 'can'
and 'need' comes from toolchain defaults and all we need to do to be
precisely compatible with mentioned documentation is to change the
default to win10, like authors of this documentation did in their SDK.
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.
Those are bugs in these projects. I'm not keen to break them, but I
also don't think that we should keep current situation forever.
I'd like users, who just installed a default mingw-w64, to be able to
just #include and have the best of mingw-w64 available.
Right now, when they try to use any recent API (as in younger than 19
years), they have to learn about _WIN32_WINNT and mess with it. In my
opinion, they should not be required to do that. (Once they have some
specific expectations about OS version, they may still want/need to
do that, but mistakes of unrelated projects should not be among
reasons to mess with _WIN32_WINNT).
That sounds like a sensible goal to have - but I'm a little undecided
about the practicalities.
Then again, I can agree with the argument that projects that are built
for distribution across older versions maybe should take care to
specifically set the define themselves anyway.
Regarding the current archaic default, an alternative path (that
doesn't take us all the way, but at least a bit on the way) would be
to bump it to Win7.
I think that it's better than nothing, but it would only move the
problem. It also rises more questions like why not win8? When will we
rise it again? Will we wait until win7 becomes 19 years old? I think
that those questions are better answered individually by projects
themselves, we can't make a single choice good for all of them.
I also faintly remember somebody suggesting that we'd formally drop
support for XP altogether.
FWIW, that sounds about right to me, but I didn't want to make this
change about dropping XP support. I guess that what we're missing is
some form of discussion and formalizing it, if that's the consensus.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
