【转】C Runtime Library的来历

由于我看到的文章也是转载且未提供原文链接，所以这里没有提供原文链接！

msvcrt.dll（名称：Microsoft C Runtime Library）提供了printf，malloc,strcpy等C语言库函数，并且为使用C/C++(VC)编译的程序提供了初始化（如获取命令行参数）以及退出等功能。

C Runtime Library 的来历, API, STL, MFC, ATL关系

刚接触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(Standard Template Library，标准模板库)。包含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 ++，真是太英明了！