On Fri, Feb 4, 2022 at 8:21 AM Marc-André Lureau <marcandre.lureau@xxxxxxxxx> wrote: > > Hi > > On Mon, Jan 31, 2022 at 8:18 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> For the record: >> >> https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: >> > MSVCRT […] Works out of the box on every Microsoft Windows versions. >> >> This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. >> The original Windows 95, with or without the only service pack released for >> it (SP1, because OSR 2 was not released as a service pack, only as an "OEM >> service release" for new computers), shipped only the even older CRTDLL.DLL >> (which MinGW stopped supporting years ago) out of the box, MSVCRT.DLL had to >> be installed through a redistributable (which was included with many >> applications including Microsoft Office, but it was not part of the >> operating system). >> >> But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version >> numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the >> box, UCRT is not. Is it really a good default to depend on a runtime library >> that is only included in Windows ≥ 10? > > > This proposal doesn't change the default. Although we can discuss whether deprecating msvcrt support in Fedora-MinGW would make sense today. > > Fwiw, given that the primary use case for a cross-toolchain is for developer needs, I think it is reasonable to have only UCRT target in the future. > > Projects releasing for Windows should probably natively build and test their releases with Msys2, and they can do so for msvcrt targets. > > But there is at least one user that may legitimately want to keep a msvcrt 32bit target: mingw-wine-gecko. > Unfortunately, there hasn't been a ton of incentive for Windows developers to switch to 64-bit. Heck, Visual Studio itself only switched a couple of years ago. A lot of the extended Windows dev ecosystem hasn't gotten to 64-bit either, yet :( I think it's good to have the UCRT target, but dropping the existing ones would be extremely painful. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure