This is a separate layer from the CRT source, which is why you didn't find it there. It's maintained separately, versioned separately, and deployed separately.

This also doesn't actually appear to have any commits corresponding to any released compiler versions- commit history only goes back a couple of weeks. I suspect they'll show up once an actual release has shipped out of this repository.

Our commit history is stretched across multiple Microsoft-internal source control systems. In my career (2007+ in MSVC), that’s Source Depot, two databases of Team Foundation Server, and currently Git in Azure DevOps.

Unfortunately, we will not be making the history prior to the GitHub “Initial commit” public. It would be a huge amount of work, would bloat the git repo, and would be of little utility. (We occasionally have to perform programmer-archaeology, but rarely more than a year, and usually it’s only something that the developer who made the change can do due to personal memories.)

Consider this a fresh start. We will figure out a way to tag commits corresponding to shipped releases.

When you select the windows sdk version you want to use in visual studio it switches you over to the version of ucrt in that sdk. It's not dependent on compiler version

I’d suggest this is the opposite, this is Microsoft changing their ways for the better. It’s really hard to open source legacy code, this new code should be the restart of open source releases going forward, and who knows, maybe they’ll upload historical tags at some point in future. Personally I think there will be a lot tighter integration between open source git repos and Microsoft’s newer developer tools efforts, including eventually cross-platform versions.

>It’s really hard to open source legacy code

Of course, but my point about the new Microsoft was in relation to UCRT source, which used to be part of the standard VC runtime library and distributed with the compiler.

This new release of the c++ stdlib is fine and I'd actually be fine with the entire C/C++ runtime (including UCRT) being on github. At least there'd be just one place to look for it.

As other posts pointed out, I believe it moved from the compiler to Windows SDK, because it was not considered compiler-specific any longer. Not sure if that addresses all of the complaint. I’d be first in line to say that the mess Microsoft has in distributing proprietary tool chains and SDKs is pretty terrible. The fact that I have to have Visual Studio installed for certain msbuild features, though legacy ones, still bugs me. But then, it could be worse (see Xcode).

The sources for debugging are included with the product; these sources are more or less the same as in $/VC/Tools/MSVC/ (version) /crt/src/stl

Parts of the CRT are closed source, headers are shippped as a part of MSVC.

(Edited after correction)

The source is also shipped as part of the Windows SDK.