我經常遇到Windows程序捆綁在MSVCRT（或其更多的當前等價物）與程序可執行文件。在典型的PC上，我會找到相同的.DLL的許多副本。我的理解是，MSVCRT是C運行時庫，有點類似於* nix下的glibc/libc.so。Windows下的MSVCRT是否像* nix下的glibc（libc）？
爲什麼Windows程序必須帶着它們的C庫，而不是僅僅共享系統範圍的libc？
更新：感謝Shog9，我開始閱讀有關的SxS，這進一步打開了我的眼睛到DLL聯繫的問題（DLL地獄） - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx是一個有用的介紹這個問題...
[我在微軟的本地的SxS技術當前的維護者]
MSVCRT新版本的新發布版本的Visual Studio，並反映對C++工具集的更改。因此，在特定版本的Windows繼續發佈的版本中編譯的程序可以繼續工作（例如Windows XP上的VS 2008項目），MSVCRT可以再發行，因此可以在那裏安裝。
CRT安裝會將庫丟入％windir％\ winsxs \，這是一個全局系統位置，需要管理員權限才能這樣做。
由於某些程序不希望隨安裝程序一起提供，或者不希望用戶需要管理員權限才能運行其安裝程序，因此他們將CRT直接捆綁在與應用程序相同的目錄中，以供私人使用。所以在一臺典型的機器上，你會發現很多選擇這個解決方案的程序。
程序與特定版本的運行時間相關聯，並且所需的版本是而不是保證存在於目標機器上。此外，匹配的版本曾經有問題。
在Windows環境中，期望用戶出去找到並安裝單獨的庫以使用您的應用程序是非常不禮貌的行爲。確保應用程序中包含不屬於主機系統的任何依賴項。
在Linux世界中，這並不總是那麼簡單，因爲主機系統的外觀可能會有很大的變化。
簡答題？因爲，直到SxS，MSVCRT 不可靠版本！你能想象如果編譯和測試針對libc 5的程序默默地開始使用libc 6，那麼將會產生瘋狂嗎？這就是我們在Windows上多年所處的情況。我們大多數人只想儘快從未再次打破保持了變化的一個版本，相信MS
SxS並不保證您將使用您編譯的相同版本：（默認是遵循策略，默認策略是自動升級 – 2008-12-29 05:50:22
在Windows中並沒有真正的「系統範圍的libc」。
在* nix中，通常有一個編譯器，一個鏈接器，並且有一個定義良好的對象文件格式，調用約定和名稱修飾規範。這些東西通常伴隨着操作系統。編譯器的半特殊狀態（加上強調跨不同* nixes的可移植性）意味着某些東西可以在之前存在，並且可以通過程序可以輕鬆找到並使用它的方式進行命名和/或版本化。
在Windows中，事情更加分散。編譯器不會隨操作系統一起提供，所以人們需要自己定製。每個編譯器都提供自己的CRT，它可能與MSVCRT中的功能相同或不同。關於調用約定也沒有一個真正的規範，或者名稱應該如何出現在庫中，所以不同的編譯器（使用不同的方式做事）可能無法在庫中查找函數。
順便說一句，這個名字應該是一個線索; MSVCRT是「MicroSoft Visual C++ RunTime」的縮寫。它不是真正的「系統範圍」庫，就像kernel32一樣 - 它只是MS編譯器使用的運行時庫，它們在構建Windows時可能使用。其他編譯器可能會與之相鏈接，但（1）可能存在許可問題; （2）編譯器會將他們的代碼綁定到MS - 意味着（2a）他們不再有任何方法可以添加到運行時或修復錯誤，但希望MS能夠修復它們; （2b）如果MS決定改變RTL中的內容（他們可以隨意進行，並且可能在VC++的每個新版本中都有），或者名稱如何出現，那麼其他程序可能會中斷。
似乎MS的解決方案將編譯器+ c運行時庫版本連接在一起。 – 2012-08-23 04:01:14