On 31.12.2020 21:31, Martin Storsjö wrote:
On Thu, 31 Dec 2020, Jacek Caban wrote:
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.
Fair enough, yes, that's a correct distinction to make here I guess.
I guess that was the core part of my doubts regarding this, so with
that cleared, I won't object to this change.
I still think there's a risk that it'll break (or more subtly, affect)
a handful of projects (I need to revisit VLC's configure, for
instance), so some general headsup to e.g. the msys2 project probably
is warranted though.
FWIW, I think that the attached patch should do the right thing on VLC
(but I don't really have setup to test it). If I'd choose the way to
handle it myself, I'd set it always to win10 and have separated macro
like VLC_MIN_WIN32 which I'd use internally, but current use should be
perfectly fine with something like the patch.
It sounds lime msys2 will not be affected. I don't mind waiting with
committing this patch if helps. I only think that it would be good to
commit relatively early in release cycle so that we have time to address
feedback.
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.
Yeah, that's probably a separate discussion. And before doing it, I
guess we should quantify what we actually gain from it, instead of
just doing it for the sake of doing it. Being able to rely on more
features in msvcrt.dll (for setups that use it) probably would be one
thing.
I'd be tempted to consider defaulting to UCRT, but I realize that it has
serious compatibility implications. If we decided to do it, it would
make msvcrt.dll setup much less important (and maybe even a way to keep
optional compatibility with older Windows). It seems to me that
llvm-mingw is successful defaulting to UCRT, do you think it makes sense
for upstream default?
Thanks,
Jacek
diff --git a/configure.ac b/configure.ac
index 96e47b1969..45b26bf8f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -264,11 +264,6 @@ case "${host_os}" in
AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
[[#ifdef _WIN32_WINNT
# error _WIN32_WINNT already defined
- #else
- # include <windows.h>
- # if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0601
- # error _WIN32_WINNT toolchain default high enough
- # endif
#endif
]],[[;]])
],[
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
