应用软件发生异常 下一代VC运行时库系统 the Universal CRT(2)

现在大部分软件的做法是将这两个dll放在软件目录下发行。但是问题又来了，光是VC2008的msvcr90.dll的就有N个版本，不同语言有不同版本，随着update增加的修正版本也很多。大部分情况应该不会有问题，但笔者就曾经遇到过加载错误版本的运行时库而程序崩溃又查不出问题的经历。应用软件发生异常这个时候微软要求必须使用manifest文件来指定加载的VC运行时库版本。直到VC2010，由于编译器内置了manifest，所以就不需要额外提供。

自Visual Studio 2010开始，微软大力改进了很多C++特性，陆续在2012、2013、2015版本中增加了对C99、C++11、C++14、C++17等标准的支持，使得C++库的功能成倍增加。这种小步快跑的更新模式，使得如何有效的让VC运行时库向前和向后兼容而不破坏现有的软件组件的问题变得异常突出。再加上让VC运行时库能够更好的支持Win8/10提倡的PC和移动设备并举的理念，微软团队决定在Visual Studio 2015对VC运行时库进行重构。然后“the Universal CRT”就应运而生了。

the Universal CRT（以下简称UCRT），顾名思义，意思为“通用C运行时库”。关键就在“通用”这两个字上。早期的设计理念就是要把相对通用的功能独立出来。这个概念最早在Visual Studio 14 （即vs2015）的CTP1 [1] 发布的时候提出来 [2] 。VS很神奇的跳过了13.0这个版本，直接从12.0（vs2013）跳到了14.0（vs2015），估计是因为欧美人把13这个数字认为是不吉利的有关。尽管UCRT的版本号称是1.0，但真实的VCRuntime还是14.0。

当vs2015还在CTP阶段时，微软的设想是将VC运行时库拆分成三部分

。

vcruntime140.dll 包含运行期需要处理的功能，如：进程启动、异常处理、以及耦合到相关编译器的功能。

appcrt140.dll包含所有平台上都可用的所有功能，且以后保持这部分CRT的向后兼容性。包括：堆、数学库、stdio库、locale库、大多数字符串操作函数、时间库和一些其他功能等。

desktopcrt140.dll包含所有只能由桌面应用程序使用的功能，且以后保持这部分CRT的向后兼容性。包括：处理多字节字符串、exec和spawn进程管理函数、direct-to-console I/O函数的功能等等。

在最终发布正式版的时候，微软将appcrt140.dll和desktopcrt140.dll合并为一个不带版本号的程序库：ucrtbase.dll。它对应的Debug版本的命名是ucrtbased.dll。这个后来被正式命名为“the Universal CRT”

令很吐槽的是，UCRT并不只是一个DLL，它还附带了一堆以“api-ms-”开头的DLL程序文件，且有40个之多！可以看到，这些DLL导出了几乎所有的win32api。这其实是微软在Windows10中大力推动的“Universal Windows Platform (UWP) apps”即“通用Windows平台应用”的api接口 [3] 。这些dll有些默认为“delay load”，也就会是被延迟加载。一般基于UCRT编译的程序，不是直接调用ucrtbase.dll，而是调用VCRuntime140.dll和UWP apis来间接调用。

如果你是用Visual Studio 2015和2017来编写C或C++程序，那么就已经是基于UCRT的。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-68942-2.html