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 <[email protected]> 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ö <[email protected]> > *Wysłano: *czwartek, 31 grudnia 2020 21:32 > *Do: *Jacek Caban <[email protected]> > *DW: *[email protected] > *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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
