On Wed, Feb 25, 2026 at 3:42 PM Zephyrus Lykos via mingw <[email protected]> wrote: > > Hi all, > > Since most upstream projects (mingw-w64, Wine, Mono, Microsoft SDKs, and > .NET) switched to the UCRT runtime by default, I propose we also follow their > choice on Fedora's side. > > This should not break most OS support, since: > - XP: The vcredist installer automatically deploys UCRT stub DLLs > (apisetstub). > - Vista ~ 8.1: API Set resolution implemented in NTDLL. UCRT is available as > system update packages (KB2999226). > - 10 and onwards: Integrated in the base OS. > Any OS preceding XP will not be supported with UCRT. > > If people want their executables to work without installing UCRT, they need > to ship the redistributable binaries (apisetstub + ucrtbase.dll) from MS's > SDK, located in: > C:\Program Files (x86)\Windows Kits\10\Redist\%SDKVER%\ucrt\DLLs\ > like how one has to ship msvcp##.dll for builds linking with CRT other than > libmsvcrt-os.a. > > Read mingw-w64-doc/howto-build/crt-libraries.txt for more info. > > --- > > Many projects now want a Windows on ARM target. We'd also like to build Wine > using Fedora's toolchain and libraries. > This could be the opportunity to add the toolchain for ucrtarm and ucrtarm64 > (names TBD). >
This is something that we would like to see for further work in Fedora Asahi Remix Windows application compatibility. > The toolchain might need a patched GCC and binutils; please see the patchsets > at https://github.com/Windows-on-ARM-Experiments. > Otherwise we could use Clang, like what MSYS2 does now. However, we don't > want to default to libc++, unlike MSYS2. > > We might or might not want to add a target for ARMNT (32-bit ARM on Windows): > Good: > Wine and Wine Mono have ARMNT and WoW support, which requires a toolchain. > Bad: > Microsoft already sunsetted their support. SDK 26100 removed ARM32 libraries, > and OS 26100^ removed ARM32 UWP app support. > There isn't support for ARMNT in GCC/binutils. > Fedora doesn't target 32-bit ARM. We also don't have CONFIG_COMPAT=y on all > flavors of kernel. > > ^: actually should be an earlier canary build, but i forgor > > Additionally, there could be support for generating code with ARM64EC ABI > (https://learn.microsoft.com/en-us/windows/arm/arm64ec). > This can be further improved by producing CHPEV2 fat binaries > (https://learn.microsoft.com/en-us/windows/arm/arm64x-pe) > LLVM should already have preliminary support for ARM64EC codegen and ARM64X > linking in llvm-21, but GCC and binutils still do not have much support. > My understanding is that there are some non-upstream patches related to this for the GNU toolchain. We could carry these and also maybe work with the Red Hat toolchain folks who maintain the native toolchain stack to help accelerate the path to upstreaming those. > --- > > We might also want to lower the support tier for MSVCRT or just drop it. > Otherwise, we will have too many targets to maintain. There are a surprising number of people who use Fedora's MinGW toolchain for retro-computing development, so I would prefer we didn't completely drop it. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ mingw mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
