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 <windows.h> 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

Reply via email to