前言

其實the Universal CRT（通用C執行時庫）已經不能算是“下一代”，因為它已經在前兩年伴隨著Visual Studio 2015和Windows10釋出。但是由於之前使用VS2015開發的應用還較少，關注的人也少，相關的文章更少。所以筆者想幹脆用一篇文章，深入淺出的介紹一下Universal CRT。

什麼是CRT？

CRT，也就是“C Runtime”，中文譯為：C執行時。我們一直稱為C Runtime Library（C執行時庫）。它主要負責實現C程式在執行時的各種抽象功能實現。不同的C編譯器會有不同的具體實現程式，比如Windows下常見的微軟的VC編譯器的msvcrt.dll；GCC/Glibc的crt0.o、crti.o等。具體到二進位制表現形式，可以是動態庫，也可以是靜態庫。

CRT一般會至少負責以下功能：

• 實現C庫函式。比如：printf、fopen等
• 初始化程式啟動所需要的一些功能
• 異常處理
• 多執行緒處理

CRT也可以看成是一個作業系統抽象層。大家都知道，每一種作業系統都有自己的API或者是系統呼叫。像C語言之所以能夠跨平臺（程式碼級），就是因為我只需要用C庫函式寫程式，CRT會轉化為相應平臺的具體實現的API來處理。

下面我們要著重討論的是Windows下的開發工具Visual C++配套的CRT，以下將統稱為“VC執行時庫”。

VC執行時庫的歷史

（注：上表中的劃代是作者自己的劃代方式）

第一代

我記得我最早學C語言還是上大二（2002年）的時候，那時可是VC的黃金年代。額~~應該說是鑽石年代。大家都在學習VC++6.0，一個堪稱經典的版本。VC++6.0是為了配合Windows98的應用軟體開發而釋出的，釋出的年代也差不多就是98年前後，所以內部有些檔案又稱之為VC98。

到這個時候，VC執行時庫檔案只有一個叫msvcrt.dll的，一般在c:\windows\system32下，大家發行軟體產品的時候，基本上不需要考慮是否需要帶個什麼庫，因為預設作業系統都會自帶的。

逐漸的，大家發現一個非常棘手的問題，那就是隨著功能的增多，不同版本的msvcrt.dll支援的功能和函式不同，版本的識別和相容成了難題。當時很多安裝包為了自己的需要，會不停的覆蓋系統的msvcrt.dll，導致執行不穩定。如果把WinXP系統的msvcrt.dll覆蓋了Win98的，那會導致WinXP不穩定。所以後來就發展除了第二代的CRT。

第二代

自從微軟釋出Visual Studio.Net 2002/2003開始，為了解決日益增長的功能和DLL版本相容性問題，微軟給現有的執行時庫加上了版本號，並且把執行時庫拆分為多個檔案，比較常見的是msvcrXXX.dll和msvcpXXX.dll。其中XXX是版本號。

版本號的定義和檔案命名如下表所示：

其中msvcrXXX.dll（注意不是msvcrtXXX.dll）一般負責實現C語言的基礎特性，如程式啟動、異常處理、庫函式等功能。msvcpXXX.dll負責標準C++庫的相關實現。大家可以看看其中的匯出函式就能明白。

在這一階段中，開發者想要釋出軟體產品，就必須確保目標計算機上必須已經安裝了相應版本的執行時庫。一般情況下，微軟推薦大家使用執行時庫安裝包來進行安裝。對於大型軟體為了預防萬一，都會附帶vcredist.exe安裝包。但是這種方法很不受待見。因為現在大多數軟體都是通過網際網路進行分發，對安裝包大小很敏感。每次打包附帶一個執行時庫包，既增加了使用者的下載時間，又增加了推廣成本。

現在大部分軟體的做法是將這兩個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

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”。

API Sets for Universal Windows Platform (UWP) apps

令很多人吐槽的是，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來間接呼叫。

基於UCRT程式的部署方法

什麼程式是基於UCRT的？

如果你是用Visual Studio 2015和2017來編寫C或C++程式，那麼就已經是基於UCRT的。

需要關注的程式模組

VCRuntime140.dll 這是VC執行時庫和編譯器相關的必備模組，必須存在。

msvcp140.dll 如果你寫的程式含有C++標準庫的程式碼，那就必須存在。

ucrtbase.dll和api-ms-**.dll 必須存在。

部署方法

第一種

微軟強烈推薦使用vcredist.exe來給目標機安裝相應的檔案。它會安裝所有對的UCRT檔案和必備元件。這是最省事兒便捷的方法。

但是vcredist_x86.exe和vcredist_x64.exe就各有近14MB的體積！大型程式釋出的時候可能無所謂，而很多很多基於網際網路釋出的程式，卻不可能這麼幹。網際網路程式對安裝包的大小很敏感，這直接影響終端使用者終端的到達率和推廣成本。

可參考PHP7.1的Windows版的下載頁面和安裝包。

第二種

程式自帶VCRuntime140.dll和msvcp140.dll,再給系統打基於msu的KB2999226補丁。KB2999226補丁會給系統安裝UCRT。一般情況下，Windows10已經自帶了UCRT，不需要額外打補丁。

這種方法不適用於WinXP系統。而在中國WinXP系統還有很大保有量，大家都不會輕易放棄這個龐大的使用者群的。

可參考Python 3.5的Windows安裝包。

第三種

現在網際網路程式大多使用的是app-local的部署模式，意思就是把依賴庫放在自己程式目錄下，既不會跟別的應用軟體衝突，又方便了軟體分發。

起初，微軟並沒有打算針對UCRT程式繼續這樣的部署模式。但是後來大家反響比較強烈，所以在Windows 10 SDK釋出的時候，把UCRT和UMP的相關dlls都一起釋出了。這個目錄一般是“C:\Program Files (x86)\Windows Kits\10\Redist\ucrt”。

你也可以在Visual Studio 2015的安裝目錄下找到VCRuntime140.dll和msvcp140.dll。這個目錄一般是“C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x86\Microsoft.VC140.CRT”。

有些開發者一開始可能會被ucrt目錄下的四十幾個檔案嚇到，不過還好都不大，打包壓縮以後都很小。

可參考Visual Studio 2015配套的Remote Debugger 除錯工具。這個工具由於要求是“standalone”的，所以就是用此方法部署的。可以在這裡找到：“C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86”。

UCRT展望

UCRT的確給我們帶來了很多全新的概念，也給我們帶來了少許的不適應。但這畢竟是未來的發展方向。基於UCRT的Visual Studio 2015給我們帶來的眾多新的C、C++語言標準的支援，我相信以後C++程式會變得更加強大。按照網上的一些說法，未來不排除會對VCRuntime模組再次優化重構的可能性，這個我們只能拭目以待了。Visual Studio 2017即將釋出，我們也將繼續跟進UCRT的發展方向。

[1] CTP 即Community Technology Preview，譯為社群技術預覽版，一般是微軟開發軟體的早期對內測試版

作者簡介：陳建明，目前就職於上海愷英網路科技有限公司，C++專業組組長。十多年來，儘管各種程式語言均有涉獵，但主要一直致力於Windows C++平臺的各種應用架構、開發和前沿技術的研究。

責編：何永燦（[email protected]）