[Proposal] Switch to the Universal CRT on Windows.

[Adam Wilson]

On Wednesday, 1 July 2026 at 01:24:05 UTC, Adam Wilson wrote:
> I have posted a PR 
> [here](https://github.com/dlang/dmd/pull/23345). This PR 
> deprecates (but still allows) the msvcr120 fallback path as 
> well as updating various detection routines to include the 
> latest versions of VS and deprecate anything prior to VS2015. 
> If no WinSDK or VS installation is detected then the compiler 
> throws an error.

I thought it would be good to post an update on this work since 
it turned into quite the adventure.

The good news is that UCRT is now the default for all build paths 
in DMD on Windows. Including the MinGW build path. the 
`-mscrtlib` option is retained so that you can specify different 
variants of the CRT in Windows. You can also use it to specify 
older versions of the MSCVRT if you need to.

However, while I was working on this PR, I ran into a number of 
"begats". The first was that the the nightly builds were broken, 
which prevented me from doing end-to-end testing of the UCRT 
support. So I fixed that with a liberal application of Opus 4.8. 
I even upgraded the script to upload the builds that succeeded 
even if one or more individual platform builds failed.

The reason I made *that* change is because The FreeBSD build had 
been broken since April 8th. JMD kindly tracked down the actual 
brokenness in the FreeBSD build and fixed it in the DMD repo, 
then showed me the rest of the places where the fix would need to 
applied. While there was some help from Gemini to update the 
scripts to account for system level changes by GitHub, most of 
this work was by hand.

Finally, I've also updated the Visual Studio / Build Tools 
detection logic in the Windows Installer to detect newer versions 
of the VS (which has irritated me for a while). We also made a 
change to the installer to be architecture sensitive. If you are 
still on a 32-bit machine, the options to install VS2026 (64-bit 
only) will be disabled and an option to install the VS2019 Build 
Tools (last 32-bit release) will be enabled. The reverse is true 
on 64-bit machines. These changes will be live in tomorrows 
nightly build.

The reason I went to all of this trouble is that originally I was 
working on a PR to add some new features to the CodeView 
debugging symbol emitter on Windows to add some new types of 
information that have been made available since the last major 
update. And during testing of these changes `build.d` decided 
that it couldn't find the UCRT libraries so defaulted to the 
ancient MSVCR120 library that shipped with MinGW. Which 
incidentally segfaults when you try to use the `%zd` format in 
`printf`. Walter has since decided to remove `%zd` from DMD, but 
even so, upgrading to UCRT will be a major improvement in 
interoperability and security for D on Windows.

The new CodeView data includes some nice quality-of-life 
improvements.
1. Complete Stack Frame information. Enables the debugger to more 
accurately traverse the stack.
2. UDT location information. The debugger will now be able to 
locate the source code for UDT's and navigate to them when you're 
stepping through code.
3. Environment info. Language and Compiler version info to inform 
the debugger to use the D dialect. Also include the original 
build path to the source file to help the debugger locate the 
source file on disk.
4. File content hashes. Now the debugger can detect when a file 
has change and inform you that the code your are debugging does 
not match what the debugger is seeing.

While none of these changes are going to change your life, I 
think you'll find them to make the debugging experience a bit 
smoother.

While the compiler may get all the attention and effort, the 
infrastructure we use to deliver D to other programmers has a 
strong "first impression" effect on how they perceive us. Broken 
nightlies, an installer that can't find the latest version of 
Visual Studio, outdated versions of the CRT libraries. All of 
these boring non-glamorous details reflect poorly on us.

Which gets to another point. Part of the reason that these things 
are neglected is because the are difficult to work with and get 
absolutely no recognition when they work correctly but everybody 
notices when they don't. I think this is one area where the 
application of LLM's can be significantly beneficial to D. I 
didn't know anything about NSIS scripts or GitHub Actions before 
I started this project, but after watching the LLM do it's work, 
I do know more about those things, and how we use them in D 
(although some of our build system is literal madness).

I was able to get done in a week what would've easily taken me a 
month or more to work out by hand. I firmly believe that D's 
"curb appeal" matters quite a bit, and hopefully the time that 
Rainer, JMD, Rikki, Nic, and I spent this week on improving that 
curb appeal will pay dividends in the future. That you to all you 
fantastic gentlemen for you help this past week!