MS Visual C ++运行时库中有什么？我的意思是，我google了它，我总是发现像帮助，app xxxx给我MS Visual C ++运行时库错误，没有解释。
我认为Windows C运行时库附带Windows？不是用VC ++？感谢。
编辑： 首先，谢谢你的回答。我现在对Windows中的运行时库不太了解。我的意思是，第一部分，Windows内部有它的win32 API，所以，没关系，我知道。此外，Win32API来自内核和用户部分。
但我一直认为像GDI这样的函数是作为DLL访问的（我仍然认为它们是）。但我认为甚至像printf这样的函数都在某些Windows文件中。
所以，我是对的，当我知道“printf之类的”简单“函数需要直接链接而不是直接使用OS的内核部分时，更复杂的Windows API函数作为dll链接因此，不是与编译器一起分发但是与OS一起分发？他们随后访问内核？
我的意思是，让我们说GDI，我告诉它绘制图片，它在用户模式下完成所有的工作，而不是调用将其全部放在帧缓冲中的内核函数？
最后想到，为什么这样就解决了？我的意思是，如果VC ++运行时只是C和WinAPI之间的层，为什么VC ++不能直接调用WinAPI？
答案 0 :(得分：6)
这是过于简单化，但它会给你一个要点。 MSVCRT是一组实现C ++语言部分的DLL。这些DLL中实现了printf，memcpy等函数。
使用特定编译器编译并动态链接到C ++运行时的每个程序必须以某种方式在目标计算机上具有 CRT二进制文件的正确版本。因此，发送给最终用户的应用程序通常（通常是？）也附带这些DLL的包。这个包被称为“可再发行”（或“redist”），并且对于确切的编译器版本和目标平台的每个组合都有不同的包。例如，以下各项都有单独和不同的红色标记：
等等。
是的，Windows通常会“附带”某些版本的CRT。但是，它附带了运行Windows附带的应用程序所需的版本。如果Windows及其所有应用程序都是在MSVC8 SP2中编译的，并且您的应用程序是在MSVC10中编译的，那么您的所需的CRT 将不会出现在框中，因为它正在运行Windows。
这就是将应用程序与redists一起发布的常见做法。
通过像魔术一样的Houdini，我预测你的下一个问题将是“我在哪里得到红人？”
答案是来自MicroSoft。尝试谷歌搜索“msvc 9 x64 redist”，你会发现：
答案 1 :(得分：2)
简要回答是MSVS C / C ++运行时实现了malloc / free，stdio，iostream和一些c ++等函数，比如dynamic_cast和异常处理。这些在visual studio版本之间有所不同，因此不同版本的运行时间不同。
Windows主要使用C API（Win32 API），它与C / C ++标准库有很大不同。 MSVS C / C ++运行时调用此API来分配内存等等。
（我想Windows中包含的一些应用程序是用MSVS和C ++编写的，因此它们确实包含该版本的MSVS运行时。）
此外，运行时会随着新的Visual Studio版本的发布而更改。 Windows版本的持续时间要长得多。
答案 2 :(得分：2)
使用Visual C ++编译的程序需要“运行时” - 这是一些处理应用程序启动/关闭，内存分配/释放，支持读写文件等的代码。
这不是操作系统的一部分，也不是最终应用程序的一部分 - 因为所有C ++应用程序都可以共享它，所以默认情况下运行时是一个单独的安装。
此外，每个版本的Visual C ++都有自己的运行时安装程序，因为每个版本在所有这些工作方式上都存在细微差别和改进。对于不同平台（例如x86和x64）
，运行时也有不同的验证因此，Microsoft提供了许多“Visual Studio XXXX运行时安装程序（YYY）”下载，其中XXXX是visual studio版本（2005,2008,2010等），YYY通常是“x86”或“x64”。
大多数需要运行时的应用程序会在需要时自动安装它，因此通常最终用户不太了解这些可再发行组件。
答案 3 :(得分：2)
它们是实现C和C ++标准库函数的库。诸如printf之类的标准函数在这些库中实现。
核心Windows库仅提供系统调用的接口，即Win32 API，因为这就是构建功能齐全的Windows应用程序所需的全部内容。 VC ++库主要是围绕此API的包装器，类似于Linux上的glibc库。
例如，来自C库的malloc可能会依次使用VirtualAlloc API来分配内存。