How to circumvent Windows Universal CRT headers dependency on vcruntime.h - c

Question

In trying to evaluate Clang on Windows, utilizing the Windows Universal C Run-Time (...\Windows Kits\10\Include\10.0.15063.0\ucrt) I was immediately facing unexpected wall, in the form of an undisclosed and unexpected dependency on Microsoft's Visual Studio. Apparently even the simplest C program will not be able to compile as soon as you include any standard C header, because they all seem to end-up attempting to #include vcruntime.h (which is not part of the UCRT).
My questions are:
Is there a way to utilize the Windows Universal C RTL SDK withOUT Visual Studio?
If it is not intended or possible, why then is it not called "Windows CRT for Microsoft VC" - what am I missing?

Answer 1

Check out [MSDN.Blogs]: Introducing the Universal CRT (and also the other URLs that it references). Emphases are mine:
In June of last year we published a pair of articles discussing the major changes that we had made to the Visual C++ C Runtime (CRT) for Visual Studio 2015. ...
The AppCRT and DesktopCRT have been recombined into a single library, which we have named the Universal CRT. The new DLLs are named ucrtbase.dll (release) and ucrtbased.dll (debug); they do not include a version number because we’ll be servicing them in-place.
From [MS.DevBlogs]: The Great C Runtime (CRT) Refactoring
In order to unify these different CRTs, we have split the CRT into three pieces:
VCRuntime (vcruntime140.dll) ...
AppCRT (appcrt140.dll) ...
DesktopCRT (desktopcrt140.dll) ...
According to [MS.Support]: Update for Universal C Runtime in Windows:
Microsoft Visual Studio 2015 creates a dependency on the Universal CRT when applications are built by using the Windows 10 Software Development Kit (SDK).
and from [MS.Dev]: Windows 10 SDK:
Note: Windows 10 development targeting Windows 10, version 1803 (or later) requires Visual Studio 2017. This SDK will not be discovered by previous versions of Visual Studio.
So, UCRT is strictly bound to VStudio. Universal: means that it's not dependent on VStudio version (all VStudio versions will use a common one (there can be only one)).
Personal opinion: UCRT is the Win (wannabe) equivalent of Nix's libc.
I took a look in SDK include dir (e.g. "%ProgramFiles(x86)%\Windows Kits\10\Include\10.0.15063.0\ucrt"):
Every common file (e.g. stdio.h) has an #include <corecrt.h>
corecrt.h has an #include <vcruntime.h>
no #ifdefs, so there is no way (at least no easy one) to overcome this.
But, things are even clearer when reaching link phase. If your C code includes UCRT headers, it will (most likely) link to files from SDK lib dir (e.g. "%ProgramFiles(x86)%\Windows Kits\10\Lib\10.0.15063.0\ucrt\x64"), which are generated by VStudio, and there's a great chance for that to fail. Example:
code00.c:
//#include <stdio.h>
int main()
{
//printf("Dummy.... sizeof(void*): %d\n", sizeof(void*));
return 0;
}
Output:
[cfati#CFATI-5510-0:e:\Work\Dev\StackOverflow\q045340527]> sopr.bat
### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ###
[prompt]> dir /b
code00.c
[prompt]> "c:\Install\x86\Microsoft\Visual Studio Community\2015\VC\bin\cl.exe" -nologo -c -Focode00.obj code00.c
code00.c
[prompt]> "c:\Install\Google\Android_SDK\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang.exe" -c -m64 -o code00.o code00.c
[prompt]> dir /b
code00.c
code00.o
code00.obj
The 2 (generated) files are incompatible:
[prompt]> "C:\Install\x86\Microsoft\Visual Studio Community\2015\VC\bin\amd64\dumpbin.exe" -nologo code00.obj
Dump of file code00.obj
File Type: COFF OBJECT
Summary
80 .debug$S
2F .drectve
7 .text$mn
[prompt]> "C:\Install\x86\Microsoft\Visual Studio Community\2015\VC\bin\amd64\dumpbin.exe" -nologo code00.o
Dump of file code00.o
code00.o : warning LNK4048: Invalid format file; ignored
Summary
[prompt]> "c:\Install\x64\Cygwin\Cygwin\AllVers\bin\readelf.exe" -d code00.o
[prompt]> "c:\Install\x64\Cygwin\Cygwin\AllVers\bin\readelf.exe" -d code00.obj
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
Now, I know that lld (I remember that I built it in the past, but I can't find it, in order to test my statement) is able to link both ELF and COFF file formats, but I doubt that it can combine them.
Conclusion
Based on the above, here are the answers (that I could come up with) to your questions:
I suppose it is - an unsupported one though (claiming that something is impossible is almost always false). But, there would be lots of restrictions (consider the above file format matching), and would most likely require some dirty tricks or (lame) workarounds (gainarii) like (some that I can think of now):
Altering it (editing its header files - to remove the unwanted #includes)
Creating a dummy vcruntime.h file (to get past the compile phase)
Adding VStudio (or anything else, as a matter of fact) in the name would automatically decrease its "universality level". And this is only the 1st step: it has been separated from VC Runtime. Think of it as of a baby. In time, it will become mature (and more stable,) and maybe other compilers / build toolchains will end up supporting it as well (no need to follow the spartan rules, and throw it off the cliff :) ... at least not right now). But, I think only MS could have an answer to this (although there's a great chance that they won't provide a clearer one)

Answer 2

Newer versions of mingw-w64 do support UCRT, using their own headers and LIB files, so UCRT works (with Clang or GCC) without either the Windows SDK or Visual Studio being installed. You can even compile apps to use the UCRT on other platforms such as Linux or macOS. Of course, this scenario is unlikely to ever be "officially supported" by Microsoft, but many projects now rely on it, and Microsoft employees have (unofficially) given the mingw-w64 project feedback validating their approach.
If you are using the MSYS2 distribution of mingw-w64, Clang uses UCRT by default (for both 32-bit and 64-bit x86, and for 64-bit ARM); for 64-bit x86, GCC comes in two different distributions, one UCRT-based and the other MSVCRT-based; GCC for 32-bit x86 is MSVCRT-only. See MSYS2 Environments.