Migrate to UCRT builds for Windows downloads on the website and Steam

[ParadoxV5]

I’m currently building a GDExtension that depends on a UCRT library, and I’m having unexpected troubles.
After some investigation, I noted that my Godot Engine – which comes from Steam – uses MSVCRT rather than UCRT.

$ objdump -p '/mnt/c/Program Files (x86)/Steam/steamapps/common/Godot Engine/godot.windows.opt.tools.64.exe' | grep msvc
        DLL Name: msvcrt.dll

According to caseih @ freebasic.net, it is undefined behavior to mix MSVC and UCRT and it’s luck if it works.
The MSYS2 Environments doc § MSVCRT vs UCRT agrees and also lists several benefits of migrating away from MSVCRT.

I would like Godot Engine Windows downloads to join the future by also migrating to UCRT.
According to that MSVCRT vs UCRT section, even Microsoft Visual Studio has switched defaults.
Because UCRT is the new MSVCRT, this should be more a convenience and less a limitation.

Intriguinly, Godot also recommends VS Community to build for Windows, but it makes no mention of MSVCRT nor UCRT and the EXE is still MSVCRT. [P.S.] The source code, however, seems aware of MSVCRT vs. UCRT in a couple of places.

I may be able to find (or build) a MSVCRT version of my dependency, but I much prefer that I don’t have to downgrade. (Same for many others as well, chances are.)

[ParadoxV5]

I originally began my development using the MinGW that shipped with CLion (paid C IDE), which I suspect [Update: indeed] is MSVC (but the dependency has always been UCRT). All went well, except I can’t print to console if I link the dependency unless I use the GDExtension API.
I’m switching IDE and I’ve downloaded a UCRT MinGW-w64. Now, not only neither can an example GDExtension print using <stdio.h>, but my project also straight up Error 126 even with all dependent DLLs in PATH. (It’s not the new IDE’s problem because I build using a script.) [Update: Looks like it isn’t necessarily the fault of MSVCRT vs. UCRT; the suggestion still stands, though.]

The sources linked can explain the printing problem, at least. IIRC, printing involves IO and FILE*, known issues to each of the sources.

[Calinou]

MSVC and GNU ABIs are not compatible with each other. This issue is not exclusive to GDExtension, but pretty much any language that can interoperate with C libraries. This is why Rust provides Windows builds for both ABIs).

I don't think switching to UCRT resolves this. One way you can work around this issue while still using an open source compiler is to use clang-cl. This is how official Google Chrome binaries are compiled, for instance.

Godot does not require users to install the Visual Studio C++ redistributable to run Godot, as official binaries are compiled with MinGW which always embeds an equivalent runtime by design. This is the case even if you compile Godot with MSVC yourself then distribute binaries, as Godot avoids linking against this runtime in the first place.

The only case where the VC++ redistributable is required is when you are using an extension that depends on it.

There's one advantage to using UCRT: it's bundled with recent Windows versions and doesn't require a separate download if your app depends on it.

However, there's also a downside: only Windows 10 and later are supported. This is less of a problem nowadays than it was a few years ago, but Godot still has a small portion of users on Windows versions prior to 10. Windows 7/8/8.1 can still run Godot's master branch right now, but support is done on a best-effort basis.

[ParadoxV5]

MSVC and GNU ABIs are not compatible with each other.

The Compiling for Windows linked states that both VS Community and MinGW-w64 are fine.

This is why Rust provides Windows builds for both ABIs

😮 I’ll take a peek.

as official binaries are compiled with MinGW which always embeds an equivalent runtime by design.

MSYS2 has both UCRT and MSVCRT environments. The webpage where I got my MinGW-w64 also has downloads for both MSVCRT-linking MinGW and UCRT-linking MinGW.

However, there's also a downside: only Windows 10 and later are supported. This is less of a problem nowadays than it was a few years ago, but Godot still has a small portion of users on Windows versions prior to 10. Windows 7/8/8.1 can still run Godot's master branch right now, but support is done on a best-effort basis.

The MSVCRT vs. UCRT section says that earlier Windows version are also supportable. It has more info linked.

[bruvzg]

I should not matter at all which CRT Godot engine is build with, GDExtension do not pass CRT objects (like FILE) and use own memory allocation code, you should be able to use MSVC extension with MinGW build engine. But all components of the extension should be built with the same CRT and same compiler.

but my project also straight up Error 126 even with all dependent DLLs in PATH.

Loading dependencies should not have CRT involved in any way, most likely caused by missing sub-dependencies. Also, Godot is setting custom library search path, so PATH might not work, place your libs in the same folder as main extension lib.

Now, not only neither can an example GDExtension print using <stdio.h>

Godot uses a lot of io redirection, so it's not necessary related to CRT.

[ParadoxV5]

you should be able to use MSVC extension with MinGW build engine. But all components of the extension should be built with the same CRT and same compiler.

I am currently trying to build my extension in UCRT.

Also, Godot is setting custom library search path, so PATH might not work, place your libs in the same folder as main extension lib.

Been there, tried that, and just retried. No (observable) difference.

Godot uses a lot of io redirection

This is what I thought when I was with my previous IDE. I couldn’t explain to myself why a test extension that #includes <stdio.h> can print, but my project can’t.

[bruvzg]

Try using something like https://github.com/lucasg/Dependencies, it often non-obvious which libs are necessary, since each one can chain load more.

[ParadoxV5]

I’ve stopped traversing at system DLLs. All non-system dependencies present. No problems found by DISM & SFC.

[ParadoxV5]

I’ve finally found out what is goïng on.
It is indeed because of missing dependencies (not sub-dependency, in fact).

Godot is setting custom library search path, so PATH might not work

This is correct, PATH doesn’t work. However, the “list missing dependencies” functionality doesn’t list dependencies that are found in PATH or working directory (which is the Godot project root).

Because of that, I was distracted into thinking that Godot can locate my dependencies (actual: in places that it can’t load from) and that the culprit is something else.

place your libs in the same folder as main extension lib.

I misread it as “the same folder as the .gdextension” and was further confused by the above quirk.

---

We should report this issue… Whether or not the inability of loading from PATH and etc. is intended, it’s a bug that the GDExtension loader and missing dependencies reporter searches different sets of locations.

As for the thread, while I’ve solved the problem that lead me here, this proposal still stands. Benefits aside, remember that I still can’t print from C (unless I switch back to linking MSVCRT) or the dependency (unless I find/build an MSVCRT version) without going through the GDScript print.

[bruvzg]

We can't switch to UCRT since it's a system component only on Windows 10+, and we are still supporting Windows 7 and 8 (it's available as a redistributable, but this will create an extra dependency).

[bruvzg]

There's no roadmap on platform support, platforms are supported until we can't support it anymore (e.g., new SDK removes deprecated headers, or we need new system API to use in the core).

Note that Macrohard put Windows 7 into EOL years ago and few people like Windows 8.

Extended support for most editions of both ended last year (in October and July), some Windows 7 editions (POS) are still getting extended security updates until October 2024.

[bruvzg]

But in this case it's not really dropping compatibility, but making it a little inconvenient, so if there are some benefits for UCRT, it might be worth switching.

[ParadoxV5]

It would be worth more dropping support for older platforms if it means we get to refactor code against features exclusive to the newer platforms (such as newer drivers, maybe?).

[bruvzg]

Also, there's 32-bit build, IIRC MinGW/GCC can use UCRT only for x86-64.

[bruvzg]

According to Steam hardware survey and some other sources, market share of 32-bit Windows 10 is essentially nonexistent (and Windows 11 removed support for 32-bit support) and Windows 7 / 8 / 8.1 combined share is less than 1-3%. And I have forgotten we now have DX12 support (which is not available on pre-Windows 10), so with this new data I'm definitely in favor of switching to UCRT (and well as dropping Windows 7/8/8.1 support and official 32-bit builds for Windows).