剛接觸Windows開發時，為了快速入門查了不少資料，沒想到看的越多，腦袋越糊涂。因為寫同一種功能的程序，找到的例程風格截然不同。拿C程序來說，有些API的名稱都很長，都是沒見過的變量類型而且全大寫；有些跟熟悉的Linux環境C開發差不多，標準短小的C函數名。再比如某些C++程序，用的標準類也會有不同。后來專門花了點功夫，才了解Windows平臺下的開發有多個不同的體系：標準C，Windows API，MFC，STL。這些都是預先編寫好的庫，實際開發時選哪個，取決于項目的規模和性質、程序的風格，還有個人的喜好。
一、自由世界中的C\C++
1. CRT
運行時庫就是C Run-Time Library，是C而非C++語言世界的概念。取這個名字就是因為你的C程序運行時需要這些庫中的函數。
C語言是所謂的“小內核”語言，就其語言本身來說很小（不多的關鍵字，程序流程控制，數據類型等）；所以，C語言內核開發出來之后， Dennis Ritchie 和 Brian Kernighan 就用C本身重寫了 90% 以上的 UNIX 系統函數，并且把其中最常用的部分獨立出來，形成頭文件和對應的 LIBRARY，C run-time library 就是這樣形成的。
隨后，隨著C語言的流行，各個C編譯器的生產商/個體/團體都遵循老的傳統，在不同平臺上都有相對應的 Standard Library，但大部分實現都是與各個平臺有關的。由于各個C編譯器對C的支持和理解有很多分歧和微妙的差別，所以就有了ANSI C；ANSI C（主觀意圖上）詳細的規定了 C 語言各個要素的具體含義和編譯器實現要求，引進了新的函數聲明方式，同時訂立了 Standard Library 的標準形式。所以C運行時庫由編譯器生產商提供。至于由其他廠商/個人/團體提供的頭文件和庫函數，應當稱為第三方 C 運行庫（Third party C run-time libraries）。
C Run-Time Library里面含有初始化代碼，還有錯誤處理代碼(例如divide by zero處理)。你寫的程序可以沒有 math庫，程序照樣運行，只是不能處理復雜的數學運算，不過如果沒有了C Run-Time Library，main()就不會被調用，exit()也不能被響應。因為C Run-Time Library包含了C程序運行的最基本和最常用的函數。
2. Standard C++ Library
到了 C++ 世界里，有另外一個概念:Standard C++ Library，它包括了上面所說的C Run-Time Library和STL。包含C Run-Time Library的原因很明顯，C++ 是 C 的超集，沒有理由再重新來一個 C ++ run-time library。VC針對C++ 加入的Standard C++ Library主要包括：LIBCP.LIB, LIBCPMT.LIB和 MSVCPRT.LIB。
二、Microsoft的C\C++
1. Windows中的CRT
CRT原先是指Microsoft開發的C Runtime Library，用于操作系統的開發及運行。后來在此基礎上開發了C++ Runtime Library，所以現在CRT是指Microsoft開發的C/C++ Runtime Library。在VC的CRT/SRC目錄下，可以看到CRT的源碼，不僅有C的，也有C++的。
CRT原先的目的就是支持操作系統的運行。因為Windows操作系統除匯編部分外，都是用C/C++編寫的，所以內核及許多關鍵服務都在CRT上運行（它們都采用dll技術動態鏈接）。此外，用 VC編寫的C/C++程序也用到它們（可以動態鏈接，也可以靜態鏈接，前者運行時需要系統中已安裝CRT的dll，后者不需要）。可以說，CRT就是 Microsoft編寫Windows時使用的低層類庫。然后，它又被當作C++標準庫的一個實現包含在了VC系列中；我們在VC中使用的C++標準庫，其實就是CRT的一個真子集（少了C++標準所不包含的代碼，特別是大量的低層C代碼）
C++標準，是C++的通用語言規范，指導所有C ++使用者。而CRT的其中一部分可以看作是Microsoft開發的一個C++標準庫實現（其實也確實如此，Microsoft在開發CRT時，參考了正在標準化過程中的C++語言規范）。它與C++標準有一定的差距，部分原因是，在C++沒有完成標準化之前，CRT已經開發并投入使用了。為了向下兼容以前的Windows代碼，早期的CRT與C++標準總有一定的差距。但是CRT確實在不斷的改進中。VC6帶的CRT與C++標準還有比較大的差距，而 VC8的幾乎完全符合C++標準了。
2. Windows中的CRT與Windows API
至于CRT與WINDOWS API的關系，與許多人理解的相反，WINDOWS API作為Windows的一部份，是在CRT的基礎上開發的。你可以將Windows（及其API）看作一個項目，而這個項目使用的語言是匯編/C/C ++，使用的類庫就是CRT。所以，離開CRT，Windows API也無法使用的。
在編寫操作系統時，你需要一個合適的低層庫，以便完成一些基本的、多次重復的工作。于是，就有了CRT。在最低層的時候，根本連DLL這個概念都沒有的，所以CRT的源代碼只能做成lib，被靜態鏈接。然后，隨著Windows越做越復雜，Microsoft提出了API的概念，它提供Windows開發者一組接口，可以直接操作Windows，這就是Windows API了。當然，Windows API也是在CRT之上編寫的。
接著，Microsoft想給予C/C++程序員以足夠的支持，除了原始CRT之外，還要增加在Windows平臺上編程所特有的東西，如thread等等。這些東西都是和平臺相關的，只能建立在Windows API上。而這些新增內容，也被放進了CRT中。此時，CRT不僅僅包含最低層平臺無關的代碼，還包括平臺相關的部分。如你調用CRT的 _beginthread，其實內部調用了Windows API的CreateThread。加入這些東西后，CRT仍然被用作編寫操作系統；但是顯然，那些調用了Windows API的部分已經失去移值性了。
然后，CRT被封裝成產品，隨編譯器一起發布。此時CRT產品的LIB和DLL都是Windows格式的，你不能在Windows以外的平臺上使用EXE或DLL吧，這就是CRT和CRT產品的區別。Windows API的產品，或是Windows的其他許多組成部分也是一些LIB/DLL文件，這些都是表面的東西，是與Windows綁定在一起的。但是，如果你認為是先有Windows或Windows API，才有CRT的，那你就本末倒置了。除非你對CRT的定義就是那些LIB/DLL產品，而不包括用來產生它們的代碼。
當然，CRT的一些組成部分也調用了Windows API。這可能就是有人認為CRT是建立的Windows API基礎上的原因。但是實際上，這一部分剝離CRT沒有任何的問題。只不過Microsoft將在Windows平臺上可以使用的C/C++低層庫都加入到CRT中。因此，CRT中很大一部分是操作系統平臺無關的（原始的CRT），是開發Windows本身及其上一切的基礎。它們也可以作為一個C/C+ +庫在其他操作系統平臺上使用。還有一部分，則是和Windows緊密綁定的，調用Windows API來實現的，可以看作擴展的CRT。之所以將這兩部分放在一起，是因為它們都是開發Windows操作系統所需要的，也因為它們也都是Windows 平臺上的C/C++程序員所需要的。這種復雜關系是Microsoft的人為因素造成的，不能因此認為CRT是建立在Windows或Windows API基礎上的。
綜上，CRT（Microsoft's C/C++ Runtime Library）的一個真子集（主要是C++ Runtime Library）是一個符合（或至少是企圖符合）C++標準的C++庫。而Windows API（以及Windows的其他許多部分）都是在CRT的基礎上開發的。
最后再說一句，C++當然不是Microsoft的專利。但是Microsoft選擇了C++，并取得了成功，這是肯定的了：象CRT，象VC，象Windows，象Office，象 SQL Server等等。這一方面說明了C++的優勢，一方面也是Microsoft自身的因素在起作用。然后，它當然要緊抓C++的大旗，大力宣揚它自己的C++，并排斥其他的C++。這就是帝國的“風范”了。所以對Microsoft，總是即恨且愛，總希望哪天它會良心發現——當然這只是幻想罷了。不過，肯定該肯定的，否定該否定的，總是應該的。但就產品而言，Microsoft不是最好的，但大多都是最成功的，在看到它的不足的同時，也要看到它的優點。存在的即使不是合理的，也一定有它的合理性。所以，不能簡單用一兩句話評價Microsoft及它的成功。惟有一點是可以肯定的，它決定選擇C ++，真是太英明了！
原帖連接：
http://leowzj1985.spaces.live.com/blog/cns!5552BF8B7C951399!306.entry
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/MoonAndWind/archive/2009/07/03/4320022.aspx