查看[MSDN.Blogs]: Introducing the Universal CRT（以及它引用的其他 * URL *）。重点是我的：
去年6月，我们发布了两篇文章，讨论了我们对Visual Studio 2015的**Visual C++ C运行时（CRT）**所做的主要更改。
...

• • AppCRT和DesktopCRT已被重新组合成一个库，我们将其命名为通用CRT**。新的DLL命名为ucrtbase.dll（发行版）和ucrtbased.dll（调试版）;它们不包括版本号，因为我们将就地为它们提供服务。
    从[MS.DevBlogs]: The Great C Runtime (CRT) Refactoring
    为了统一这些不同的CRT，我们将CRT分成三部分：
    1.* * 录像运行时间**（录像运行时间140.dll）...
    1.* * 应用程序显示列表**（应用程序显示列表140.dll）...
    1.* * 桌面显示器**（桌面显示器140.dll）...
    根据[MS.Support]: Update for Universal C Runtime in Windows：
    使用Windows 10 Software Development Kit (SDK)生成应用程序时，Microsoft Visual Studio 2015会创建对通用CRT的依赖项。
    以及从[MS.Dev]: Windows 10 SDK：
• • 注意**：针对Windows 10版本1803（或更高版本）的Windows 10开发需要Visual Studio 2017。以前版本的Visual Studio将不会发现此SDK。

因此，UCRT * 严格绑定到 * VStudio 。通用：表示它不依赖于 * VStudio * 版本（所有 * VStudio * 版本都将使用一个通用版本（ 只能有一个 ））。
个人观点：***UCRT * 是 * Nix * 的 * libc的 * Win （想要）等价物。
我查看了SDK * 包含 * 目录**（* 例如**" % ProgramFiles（x86）%\Windows工具包\10\Include\10.0.15063.0\ucrt *"）：

• 每个公共文件（例如 * stdio. h *）都有一个#include <corecrt.h>
• • 校正. h * 有一个#include <vcruntime.h>

没有***#ifdefs，所以没有办法（至少没有容易的办法）克服这个问题。
但是，当到达 * link * 阶段时，事情就更清楚了。如果您的 * C * 代码包含 * UCRT * 头，它将（最有可能）链接到 * SDKlibdir * 中的文件（例如，" %程序文件（x86）%\Windows工具包\10\Lib\10.0.15063.0\ucrt\x64"），这些文件由***VStudio***生成，而失败的可能性很大。例如：

• 代码00.c *：

//#include <stdio.h>

int main()
{
    //printf("Dummy.... sizeof(void*): %d\n", sizeof(void*));
    return 0;
}

• • 输出**：

[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

2个（生成的）文件不兼容：

[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

现在，我知道 * lld *（我记得我以前构建过它，但是为了测试我的语句，我找不到它了）能够链接 * ELF * 和 * COFF * 文件格式，但是我怀疑它是否能够将它们结合起来。

• • 结论**

基于上述内容，以下是（我能想到的）您的问题的答案：

• 我想是的--虽然这是一个不受支持的方法（声称某事是不可能的几乎总是错误的）.但是，会有很多限制（考虑上面的文件格式匹配），而且很可能需要一些肮脏的技巧或（蹩脚的）变通方法（* gainarii *），比如（我现在能想到的一些）：
• 修改它（编辑其头文件-删除不需要的#include）
• 创建一个伪 * vcruntime. h * 文件（以跳过编译阶段）
• 在名称中添加 * VStudio （或其他任何东西，事实上）将自动**降低其" 普遍性级别 *"**。

而这仅仅是第一步：它已经从 * VC运行时 * 中分离出来了。把它想象成一个婴儿。假以时日，它会变得成熟（而且更稳定，），也许其他编译器/构建工具链最终也会支持它（不需要遵循斯巴达规则，把它扔下悬崖：）...至少现在不会）。
但是，我认为只有MS可以对此给出答案（尽管他们很有可能不会提供更清晰的答案）

较新版本的mingw-w64使用它们自己的头文件和LIB文件支持UCRT，因此UCRT可以工作（使用Clang或GCC），而不需要安装Windows SDK或Visual Studio。你甚至可以编译应用程序在Linux或MacOS等其他平台上使用UCRT。当然，这种场景不太可能得到微软的“官方支持”，但现在许多项目都依赖它，微软员工已经（非正式地）给出了mingw-w 64项目反馈，证实了他们的方法。
如果您使用的是mingw-w 64的MSYS 2发行版，Clang默认使用UCRT（对于32位和64位x86，以及64位ARM）;对于64位x86，GCC有两个不同的发行版，一个基于UCRT，另一个基于MSVCRT;32位x86的GCC仅适用于MSVCRT。请参见MSYS2 Environments。