CRT原先是指Microsoft開發(fā)的C Runtime Library(C語言運行時庫)，用于操作系統(tǒng)的開發(fā)及運行。后來在此基礎(chǔ)上開發(fā)了C++ Runtime Library，所以現(xiàn)在CRT是指Microsoft開發(fā)的C/C++ Runtime Library。在VC的CRT/SRC目錄下，可以看到CRT的源碼，不僅有C的，也有C++的。

CRT原先的目的就是支持操作系統(tǒng)的運行。因為Windows操作系統(tǒng)除匯編部分外，都是用C/C++編寫的，所以內(nèi)核及許多關(guān)鍵服務(wù)都在CRT上運行(它們都采用dll技術(shù)動態(tài)鏈接)。此外，用VC編寫的C/C++程序也用到它們(可以動態(tài)鏈接，也可以靜態(tài)鏈接，前者運行時需要系統(tǒng)中已安裝CRT的dll，后者不需要)?？梢哉f，CRT就是Microsoft編寫Windows時使用的低層類庫。然后，它又被當(dāng)作C++標(biāo)準(zhǔn)庫的一個實現(xiàn)包含在了VC系列中；我們在VC中使用的C++標(biāo)準(zhǔn)庫，其實就是CRT的一個真子集(少了C++標(biāo)準(zhǔn)所不包含的代碼，特別是大量的低層C代碼)。

至于CRT與WINDOWS API的關(guān)系，與許多人理解的相反，WINDOWS API作為Windows的一部份，是在CRT的基礎(chǔ)上開發(fā)的。你可以將Windows(及其API)看作一個項目，而這個項目使用的語言是匯編/C/C++，使用的類庫就是CRT。所以，離開CRT，Windows API也無法使用的。

(相關(guān)資料圖)

C++標(biāo)準(zhǔn)，是C++的通用語言規(guī)范，指導(dǎo)所有C++使用者。而CRT的其中一部分可以看作是Microsoft開發(fā)的一個C++標(biāo)準(zhǔn)庫實現(xiàn)(其實也確實如此，Microsoft在開發(fā)CRT時，參考了正在標(biāo)準(zhǔn)化過程中的C++語言規(guī)范)。它與C++標(biāo)準(zhǔn)有一定的差距，部分原因是，在C++沒有完成標(biāo)準(zhǔn)化之前，CRT已經(jīng)開發(fā)并投入使用了。為了向下兼容以前的Windows代碼，早期的CRT與C++標(biāo)準(zhǔn)總有一定的差距。但是CRT確實在不斷的改進中。VC6帶的CRT與C++標(biāo)準(zhǔn)還有比較大的差距，而VC8的幾乎完全符合C++標(biāo)準(zhǔn)了。

綜上，CRT(Microsoft"s C/C++ Runtime Library)的一個真子集(主要是C++ Runtime Library)是一個符合(或至少是企圖符合)C++標(biāo)準(zhǔn)的C++庫。而Windows API(以及Windows的其他許多部分)都是在CRT的基礎(chǔ)上開發(fā)的。

-------------------------------------------------------------------------------------------------------------------------------------------------------

除了以上介紹的，在使用CRT的過程中，你還需要了解的是：

1、CRT的一些組成部分也調(diào)用了Windows API。這可能就是有人認為CRT是建立的Windows API基礎(chǔ)上的原因。但是實際上，這一部分剝離CRT沒有任何的問題。只不過Microsoft將在Windows平臺上可以使用的C/C++低層庫都加入到CRT中。因此，CRT中很大一部分是操作系統(tǒng)平臺無關(guān)的(原始的CRT)，是開發(fā)Windows本身及其上一切的基礎(chǔ)。它們也可以作為一個C/C++庫在其他操作系統(tǒng)平臺上使用。還有一部分，則是和Windows緊密綁定的，調(diào)用Windows API來實現(xiàn)的，可以看作擴展的CRT。之所以將這兩部分放在一起，是因為它們都是開發(fā)Windows操作系統(tǒng)所需要的，也因為它們也都是Windows平臺上的C/C++程序員所需要的。這種復(fù)雜關(guān)系是Microsoft的人為因素造成的，不能因此認為CRT是建立在Windows或Windows API基礎(chǔ)上的。

2、CRT的大部分內(nèi)容是跨硬件平臺的，但是也有一些部分，是直接用匯編寫成、基于硬件平臺、并根據(jù)特定硬件平臺做的優(yōu)化(而不是將生成機器碼的責(zé)任完全交給編譯器)。如早期對Indel的x32做了優(yōu)化，現(xiàn)在由加入對AMD64的優(yōu)化，這部分則是不跨硬件平臺的。

-------------------------------------------------------------------------------------------------------------------------------------------------------

在編寫操作系統(tǒng)時，你需要一個合適的低層庫，以便完成一些基本的、多次重復(fù)的工作。于是，就有了CRT。在最低層的時候，根本連dll這個概念都沒有的，所以CRT的源代碼只能做成lib，被靜態(tài)鏈接。然后，隨著Windows越做越復(fù)雜，Microsoft提出了API的概念，它提供Windows開發(fā)者一組接口，可以直接操作Windows，這就是Windows API了。當(dāng)然，Windows API也是在CRT之上編寫的。

接著，Microsoft想給予C/C++程序員以足夠的支持，除了原始CRT之外，還要增加在Windows平臺上編程所特有的東西，如thread等等。這些東西都是和平臺相關(guān)的，只能建立在Windows API上。而這些新增內(nèi)容，也被放進了CRT中。此時，CRT不僅僅包含最低層平臺無關(guān)的代碼，還包括平臺相關(guān)的部分。如你調(diào)用CRT的_beginthread，其實內(nèi)部調(diào)用了Windows API的CreateThread。加入這些東西后，CRT仍然被用作編寫操作系統(tǒng)；但是顯然，那些調(diào)用了Windows API的部分已經(jīng)失去移值性了。

然后，CRT被封裝成產(chǎn)品，隨編譯器一起發(fā)布。此時CRT產(chǎn)品的LIB和DLL都是Windows格式的，你不能在Windows以外的平臺上使用EXE或DLL吧，這就是CRT和CRT產(chǎn)品的區(qū)別。Windows API的產(chǎn)品，或是Windows的其他許多組成部分也是一些LIB/DLL文件，這些都是表面的東西，是與Windows綁定在一起的。但是，如果你認為是先有Windows或Windows API，才有CRT的，那你就本末倒置了。除非你對CRT的定義就是那些LIB/DLL產(chǎn)品，而不包括用來產(chǎn)生它們的代碼。

就象C++編譯器用來編譯用C++寫的編譯器自身一樣，Windows(及其上的編譯器)用來作為平臺開發(fā)和編譯CRT，并也用CRT來寫Windows自身(當(dāng)然第一個CRT和第一個用來編譯Windows的編譯器不是在Windows上開發(fā)的)。就象“我”也可以先寫一個類庫，然后在它基礎(chǔ)上寫一個操作系統(tǒng)，在這個操作系統(tǒng)上進一步擴充這個類庫，然后將它配合編譯器發(fā)布出去，發(fā)展一些我的操作系統(tǒng)的支持者，順便再賺點收入?；蛘咭粤硪环N模式發(fā)布另一個庫(只是我在原來那個庫上開發(fā)的一個產(chǎn)品，由于我獨立地發(fā)布這個新庫，許多人會不知道這個新庫與舊庫的關(guān)系。這很好，因為編程本身就是盡量隱藏細節(jié)，盡量做到對使用者透明的)，吸引不同風(fēng)格的開發(fā)者。這樣我的付出得到了最大的回報——由于我沒有發(fā)布操作系統(tǒng)的源代碼，所以許多用戶認為我不僅做了系統(tǒng)，還做了編譯器，還開發(fā)了一個類庫。做了那么多事，回報是應(yīng)該的。其實他們不知道，類庫是編寫操作系統(tǒng)所必須的，編譯器也是必須的，這些必須的東西卻可以在操作系統(tǒng)之外獲得更多的回報，真是太完美了！這是什么？這就是商業(yè)精神！當(dāng)然這些誤解對我是有好處的，我就不必到處宣揚真相了。反正我把類庫的源碼都發(fā)布了，也沒有騙過人吧。我不過是在那個原始類庫中加進了一些與我的操作系統(tǒng)相關(guān)的東西，以方便在我的系統(tǒng)上編寫程序的人們，這是我的好心吧；至于有人可能產(chǎn)生進一步的誤解，就不是我需要考慮的了……

所以還是看看CRT的源碼吧——看看那些針對硬件平臺的匯編；看看VC的標(biāo)準(zhǔn)C++庫和CRT關(guān)系；再看看其他操作系統(tǒng)的源代碼，想想CRT中的哪些部分可以支持用來寫操作系統(tǒng)，而如果我自己寫系統(tǒng)，又需要哪些東西；甚至你可以看看DOS的源代碼，想想和CRT的相似性，以及歷史淵源?？上Р荒芸吹絎indows的源代碼，否則一切就清楚了。

最后再說一句，C++當(dāng)然不是Microsoft的專利。但是Microsoft選擇了C++，并取得了成功，這是肯定的了：象CRT，象VC，象Windows，象Office，象SQLServer......這一方面說明了C++的優(yōu)勢，一方面也是Microsoft自身的因素在起作用。然后，它當(dāng)然要緊抓C++的大旗，大力宣揚它自己的C++，并排斥其他的C++。這就是帝國的“風(fēng)范”了。所以對Microsoft，總是即恨且愛，總希望哪天它會良心發(fā)現(xiàn)——當(dāng)然這只是幻想罷了。不過，肯定該肯定的，否定該否定的，總是應(yīng)該的。但就產(chǎn)品而言，Microsoft不是最好的，但大多都是最成功的，在看到它的不足的同時，也要看到它的優(yōu)點。存在的即使不是合理的，也一定有它的合理性。所以，不能簡單用一兩句話評價Microsoft及它的成功。惟有一點是可以肯定的，它決定選擇C++，真是太英明了?。?/p>

一般說來, 任何用C編寫的操作系統(tǒng), 都在內(nèi)核中實現(xiàn)了一個crt的子集, 這個子集實現(xiàn)了一些內(nèi)核需要的操作, 并且不依賴任何別的庫; 之后, 會有另一個crt的實現(xiàn), 在這個操作系統(tǒng)上, 部分功能實現(xiàn)不使用操作提供提供的API, 例如是純粹內(nèi)存操作的功能 strncmp 等, 另外一部分, 則使用操作系統(tǒng)提供的API, 當(dāng)然它想不使用也不行, 如 printf, 要是不使用Windows API, 它怎么把字符串輸出到控制臺窗口啊?~ 哈哈。在linux下, 這個操作系統(tǒng)用到的crt的子集稱為klibc, 在windows下, 稱為ntcrt；而基于操作系統(tǒng)的完整實現(xiàn)在linux下為glibc, 在windows下稱為 msvcrt。

【參考資料 感謝作者】

1、CRT與Windows