Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On Sat, 24 Dec 2022, LIU Hao wrote: > The only issue in this thread seems to be inside GNU lib because it relies on > the default value. That's probably not good; however, given GNU lib users are > less likely to be aware of this Windows-specific macro, maybe we can propose > GNU lib should set a default, safer value, if no one is given elsewhere. BTW I > do think that `_WIN32_WINNT` should always be set when compiling Windows code. Not just gnulib, but llvm's libc++ as well. There was discussion about possibly defining _WIN32_WINNT during libc++ build to win7 to allow the packaged binaries to continue to work there, but I don't know if there was a decision to do that, revert the default to win7, or just accept that our libc++ binaries won't work on win7 anymore. (I don't care at all about win 8.0, I don't know if anyone else does...) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
在 2022-12-24 01:48, Jeremy Drake via Mingw-w64-public 写道: I recently discovered that llvm's libc++ has something similar. MSYS2 recently bumped their default _WIN32_WINNT to Windows 8.1, and the libc++ built after that no longer worked on Windows 7. I was of the understanding that that macro was intended to be set by project code, and just controlled what APIs were made available by the headers, and the project code could simply not call anything from a newer version. But it seems that some projects treat it instead as telling *them* what APIs they can call, and that results in it being a minimum supported OS version. I didn't know MS explicitly called it out as such in a doc somewhere. For MSYS2 I think that's probably desired. People who set `_WIN32_WINNT` to a specific version should be supposed to be requesting some APIs of that version. If there are newer and better APIs why not use them? There's nothing wrong with that. The commit that bumped the default value of `_WIN32_WINNT` was an attempt to match Windows SDK. There's nothing wrong with that, either. The only issue in this thread seems to be inside GNU lib because it relies on the default value. That's probably not good; however, given GNU lib users are less likely to be aware of this Windows-specific macro, maybe we can propose GNU lib should set a default, safer value, if no one is given elsewhere. BTW I do think that `_WIN32_WINNT` should always be set when compiling Windows code. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On Fri, 23 Dec 2022, Roger Pack wrote: > Ran into this. > According to > https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 > "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum > operating system version your code supports." > > Anyway, setting this value to default to windows 10 caught me > recently, suddenly compiling gnutls doesn't work for windows 7 anymore > It uses Gnulib's gettimeofday.c internally, which links against the > windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high > enough. I recently discovered that llvm's libc++ has something similar. MSYS2 recently bumped their default _WIN32_WINNT to Windows 8.1, and the libc++ built after that no longer worked on Windows 7. I was of the understanding that that macro was intended to be set by project code, and just controlled what APIs were made available by the headers, and the project code could simply not call anything from a newer version. But it seems that some projects treat it instead as telling *them* what APIs they can call, and that results in it being a minimum supported OS version. I didn't know MS explicitly called it out as such in a doc somewhere. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On Sat, Dec 26, 2020 at 6:41 AM 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. > > I think that the change reflects expectations of majority of users. 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. Ran into this. According to https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports." Anyway, setting this value to default to windows 10 caught me recently, suddenly compiling gnutls doesn't work for windows 7 anymore It uses Gnulib's gettimeofday.c internally, which links against the windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high enough. You can manually set CFLAGS=_WIN32_WINNT... but some libraries don't realize that and now everywhere that wants to support 7 is forced to set it. Just a thought. If you're comfortable basically having every package everywhere that supports windows < 10 to specify it I guess that's an option. Cheers! ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
Hi Martin, Sorry for the delay. On 04.01.2021 21:16, Martin Storsjö wrote: Hi, On Mon, 4 Jan 2021, Jacek Caban wrote: FWIW, I think that the attached patch should do the right thing on VLC (but I don't really have setup to test it). Thanks, looks like that could be enough - I'll try to get time to think through and test the potential combinations. A different case that came to mind now is ffmpeg; http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=900505756bf6fb734708da6278689037157fc53a;hb=0cd8769207f1a89fc2236aab9da1c77f5a0b490a#l5628 I guess the fix here would be to do the check without including a header first, to check whether it was defined in cflags. Then again, I just checked building with -D_WIN32_WINNT=0xA00, and the binary started on Vista, so there doesn't seem to be any configure tests for features above that anyway. ffmpeg use seems fine to me. They just make sure that it's high enough to have required declarations available. It doesn't seem to make any runtime decision based on _WIN32_WINNT value. 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. At this point, I don't think there's need to wait any more; it'd better to get it out there and see what it breaks, if anything, sooner rather than later. (And my setups already override it to win7 anyway, but I guess I could consider leaving it to the default if it's higher.) Sounds good to me, I pushed the commit. 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? Well, that comes with a bit bigger incompatibility, as it breaks most existing precompiled static libraries. In a sense, that's not new. We already caused them to be incompatible many times while changing crt. Of course we try to keep compatibility as much as possible, but it's often needed if we want to progress. An example of such changes is moving things to libmsvcrt.a to be able to better support both ucrt and classic msvcrt.dll. We already did it, so it's already true that if you mix static libraries with random toolchain versions, you may run into a problem. I'm not aware of any large scale practical problems caused by this (but I may be missing something). Of course a switch to ucrt is an order of magnitude more impactful to static libraries, but my feeling is that ecosystem can deal with such changes. I may be too optimistic about this, through. That's easier for llvm-mingw anyway, as it's mostly incompatible (due to libc++) - so it's mostly convenient where you build everything from scratch everytime. But even there, I've now started providing msvcrt.dll based builds (for people who want to target older versions where UCRT isn't guaranteed to be available, and for compatibility with precompiled non-C++ static libraries). I see, so there is still enough interest in that. It also means that it would be good to not break it on mingw-w64 crt side. I guess that keeping msvcrt.dll based crt in its current form is easy. If we want to use newer features in common (mingwex) code, we can move even more of it to lib*cr* libraries, keep old behavior in old libraries and use code depending on newer Windows versions only in ucrt. I can imagine going as far as moving entire entry point implementations, if it comes to this. This way old platforms could miss new features, but would not regress. AFAIK msys2 are considering switching to this as well, but it's in one sense a much bigger break. It will be interesting to see how it goes. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
Hi, On Mon, 4 Jan 2021, Jacek Caban wrote: FWIW, I think that the attached patch should do the right thing on VLC (but I don't really have setup to test it). Thanks, looks like that could be enough - I'll try to get time to think through and test the potential combinations. A different case that came to mind now is ffmpeg; http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=900505756bf6fb734708da6278689037157fc53a;hb=0cd8769207f1a89fc2236aab9da1c77f5a0b490a#l5628 I guess the fix here would be to do the check without including a header first, to check whether it was defined in cflags. Then again, I just checked building with -D_WIN32_WINNT=0xA00, and the binary started on Vista, so there doesn't seem to be any configure tests for features above that anyway. 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. At this point, I don't think there's need to wait any more; it'd better to get it out there and see what it breaks, if anything, sooner rather than later. (And my setups already override it to win7 anyway, but I guess I could consider leaving it to the default if it's higher.) 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? Well, that comes with a bit bigger incompatibility, as it breaks most existing precompiled static libraries. That's easier for llvm-mingw anyway, as it's mostly incompatible (due to libc++) - so it's mostly convenient where you build everything from scratch everytime. But even there, I've now started providing msvcrt.dll based builds (for people who want to target older versions where UCRT isn't guaranteed to be available, and for compatibility with precompiled non-C++ static libraries). AFAIK msys2 are considering switching to this as well, but it's in one sense a much bigger break. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
Hi, On Mon, 4 Jan 2021, Steve Lhomme wrote: In VLC, in the build script we also force the value for VLC and all the libraries it builds: https://code.videolan.org/videolan/vlc/-/blob/master/extras/package/win32/build.sh#L221 So the default value should have no impact. Ah, nice. I personally build just using the configure script instead of using the build.sh frontend script - I'll look into tweaking the behaviour within configure (possibly using Jacek's patch), but it'll be a couple days before I have time to try it out properly. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
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
- # if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0601
- # error _WIN32_WINNT toolchain default high enough
- # endif
#endif
]],[[;]])
],[
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
In VLC, in the build script we also force the value for VLC and all the libraries it builds: https://code.videolan.org/videolan/vlc/-/blob/master/extras/package/win32/build.sh#L221 So the default value should have no impact. On 2021-01-04 12:14, Mateusz Mikuła wrote: MSYS2 already overrides default Windows version for mingw-w64 packages: https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55 So no worries about the breakage here. pon., 4 sty 2021 o 12:09 Mateusz Mikuła napisał(a): MSYS2 already overrides default Windows version for mingw-w64 packages: https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55 So no worries about the breakage here. *Od: *Martin Storsjö *Wysłano: *czwartek, 31 grudnia 2020 21:32 *Do: *Jacek Caban *DW: *mingw-w64-public@lists.sourceforge.net *Temat: *Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value. 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. 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. That's true; the main motivation for specifically raising it to win7 would be if we'd generally drop support for older versions. 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. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
MSYS2 already overrides default Windows version for mingw-w64 packages: https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55 So no worries about the breakage here. pon., 4 sty 2021 o 12:09 Mateusz Mikuła napisał(a): > MSYS2 already overrides default Windows version for mingw-w64 packages: > https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55 > > So no worries about the breakage here. > > > > *Od: *Martin Storsjö > *Wysłano: *czwartek, 31 grudnia 2020 21:32 > *Do: *Jacek Caban > *DW: *mingw-w64-public@lists.sourceforge.net > *Temat: *Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as > default _WIN32_WINNT value. > > > > 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. > > > > >> 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. > > > > That's true; the main motivation for specifically raising it to win7 would > > be if we'd generally drop support for older versions. > > > > >> 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. > > > > // Martin > > > > > > > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
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. 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. That's true; the main motivation for specifically raising it to win7 would be if we'd generally drop support for older versions. 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. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
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
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On Mon, 28 Dec 2020, Jacek Caban wrote: On 26.12.2020 22:44, Martin Storsjö wrote: On Sat, 26 Dec 2020, Jacek Caban wrote: 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. Right, I missed this, I was concentrated on deciding if use win10 or something older. I think it was a mistake how MS dealt with it, esp. the version check, but if you want to link to psapi.dll, the solution is well documented and supported: –DPSAPI_VERSION=1. There is no need to touch NTDDI_VERSION or _WIN32_WINNT. Projects need to be aware of -lpsapi anyway. I realize that some projects don't do it right, but the alternative is to default to XP forever. Yeah, this particular case can be worked around, with some effort. The more open question is whether there's other similar cases hiding in the headers, where one can keep calling an API that used to work before, that ends up requiring a newer version. BTW, if impact of the problem is too bad, we could just place K32* aliases to non K32-prefixed functions inside psapi importlib. This way projects that use headers in version 2, but link to psapi will keep consistent behaviour. I'm not sure it's needed nor better. That's a neat fix, in case it ends up needed indeed! 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). I don't know about it. A quick grep in mingw-w64 didn't find that. mingw-w64 headers don't have this mechanism, but you can see it in WinSDK headers. ws2tcpip.h first declares getaddrinfo. Then at the end, there's a version specific fallback: #if !defined(_WIN32_WINNT) || (_WIN32_WINNT <= 0x0500) #include #endif wspiapi.h then contains a "#define getaddrinfo WspiapiGetAddrInfo" (which is a function that tries to GetProcAddress the real getaddrinfo, and if not found, falls back to an IPv4-only stub implementation of getaddrinfo). mingw-w64 headers doesn't have this conditional though. And it only matters for Win2k which mingw-w64 doesn't really support anyway. So it's not entirely relevant for raising the define from XP in this case, but it's another example of cases where _WIN32_WINNT acts like the minimum supported version, where raising the define can cause code that used to work before to silently break on older platforms, arguing against this part of the reasoning in the patch: 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. 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. I don't know the logic behind it, it looks buggy to me, but sounds like it would do what author meant... The alternative is to never rise it to anything higher than VLC allows us. Good point, that's a good argument. I guess this is a matter of declaring the role of the define better, and adapting that code. Right now, the define is set to the minimum value that the toolset supports (XP, or Win7 in the case of llv-mingw) and there's no point in trying to set it to a lower value in user code. If we can expect to be able to meaningfully set the define to a lower version than the default, this code will indeed need to change. 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. Yes, unfortunately it may need some adaptation. I think that wrong assumptions are spread around the ecosystem because the value was so conservative archaic for years. 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
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On 28.12.2020 03:39, Liu Hao wrote: 在 2020/12/27 上午5:44, Martin Storsjö 写道: 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. I have an impression that all projects should have defined `_WIN32_WINNT` in a similar way to how people work with feature test macros on Linux (the GNU C++ compiler on Linux defines `_GNU_SOURCE` but I think it's bad practice). The default value of `_WIN32_WINNT` doesn't matter in a sense. (And if we should catch with everything by default, why not just define it to `0x`?) I think that there are no plans for post-Windows 10 versions releases at the moment, so win10 should work just as well for foreseeable future without introducing a new value. There is also NTDDI_VERSION, which specifies win10 variant and we currently default it to 0. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On 26.12.2020 22:44, Martin Storsjö wrote: 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. Right, I missed this, I was concentrated on deciding if use win10 or something older. I think it was a mistake how MS dealt with it, esp. the version check, but if you want to link to psapi.dll, the solution is well documented and supported: –DPSAPI_VERSION=1. There is no need to touch NTDDI_VERSION or _WIN32_WINNT. Projects need to be aware of -lpsapi anyway. I realize that some projects don't do it right, but the alternative is to default to XP forever. BTW, if impact of the problem is too bad, we could just place K32* aliases to non K32-prefixed functions inside psapi importlib. This way projects that use headers in version 2, but link to psapi will keep consistent behaviour. I'm not sure it's needed nor better. 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). I don't know about it. A quick grep in mingw-w64 didn't find that. 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.) Yes, to me llvm-mingw successfully using a version newer than XP was a prove that it works fine already. - 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. I don't know the logic behind it, it looks buggy to me, but sounds like it would do what author meant... The alternative is to never rise it to anything higher than VLC allows us. 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. Yes, unfortunately it may need some adaptation. I think that wrong assumptions are spread around the ecosystem because the value was so conservative archaic for years. 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.) Yes, it would be interesting. 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
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
在 2020/12/27 上午5:44, Martin Storsjö 写道: > > 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. > I have an impression that all projects should have defined `_WIN32_WINNT` in a similar way to how people work with feature test macros on Linux (the GNU C++ compiler on Linux defines `_GNU_SOURCE` but I think it's bad practice). The default value of `_WIN32_WINNT` doesn't matter in a sense. (And if we should catch with everything by default, why not just define it to `0x`?) -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
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
[Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
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. I think that the change reflects expectations of majority of users. 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. mingw-w64-headers/configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index ca044a88..b0865e47 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -134,9 +134,9 @@ AC_SUBST([IDLHEAD_LIST]) AC_MSG_CHECKING([default _WIN32_WINNT version]) AC_ARG_WITH([default-win32-winnt], [AS_HELP_STRING([--with-default-win32-winnt=VER], -[Default value of _WIN32_WINNT (default: 0x502)])], +[Default value of _WIN32_WINNT (default: 0xa00)])], [], - [with_default_win32_winnt=0x502]) + [with_default_win32_winnt=0xa00]) AC_MSG_RESULT([$with_default_win32_winnt]) AS_VAR_SET([DEFAULT_WIN32_WINNT],[$with_default_win32_winnt]) AC_SUBST([DEFAULT_WIN32_WINNT]) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
