以下是作者的一些猜想：
1. 我们在用VC编程时，会在执行我们的main函数前，系统先通过Kernel32调用一些函数，执行一些C的初始化准备工作，我们一般叫C运行时库的初始化。那么这些初始化的作用是什么？是否是必要的？不知道大家有没有思考过这个问题。
以下是我对这个问题的一些看法，不一定对，仅供参考。
我认为，C运行时库，在windows程序执行的时候，其实可以没有，也就是说，不要执行C的运行时库，照样可以很好的运行Windows程序。那么肯定有人要问，那微软为什么还有加前面一段C运行时库的初始化代码呢？这个问题我认为是这样的，因为微软不知道你写的程序，到底用没有C的库函数（也就是C标准中规定的，C编译器必须实现的函数，例如Allocate内存分配函数，openfile的文件打开函数，还有一些其他的函数，就是标准C中规定的可以直接调用的函数）。因为微软不知道程序员到底是否调用这些函数，如果调用，那么，此时必须进行C运行时库的初始化工作，否则这些函数将无法调用。大家在我的另一片文章中看见，在Windows中的C运行时库的初始化中，有准备函数跳转表的初始化工作，笔者猜测，这个表中，就包含了C运行时裤中的函数地址，在程序调用这些C标准库函数时，那么程序就可以顺利找到这些函数，正确执行。这些函数跳转表的初始化工作，就放在了微软的C初始化代码中。另外，对于C++来说，还有全局类的实例化，这期间，必须执行类的构造函数，这些都是在程序执行前进行的。当然，没有这个运行时裤的初始化，C++类的构造器什么时候执行呢？这似乎与我前面说的，可以没有运行时库，而正确执行Windows程序相矛盾。这个不要紧，微软可以把C++类构造函数的执行放在Kernel32中，在调用main前，就执行，不一样可以实现吗？所以说，如果VC编译器不去支持C/C++标准中规定的标准库函数，这个运行时库根本没有必要，也不必去初始化！
这个问题其实涉及到一个很根本的问题，到底windows操作系统先有编译器，还是先有操作系统呢？一般人看这个问题，最终会转化成一个先有鸡还是先有蛋的问题。其实不然，微软的Windows操作系统，肯定实现与VC编译器之前！而Windows最终的内核关键代码，指定不是用严格意义上的VC编译器编译的（这个说法有些绝对，微软可以对编写Windows操作系统的编译器进行扩展，最终形成VC编译器）。如何对VC编译器的前身进行扩展，使得他可以编译windows可以运行的程序，那么C/C++运行库就是一个办法。
我上面说的，有些人看了，可能会认为是一些自相矛盾的话，但其实里面的东西是统一的。因为我不知道微软具体使用的那种方法。
我现在来猜想一下，微软实现Windows和VC编译器的流程。
首先，要编写一个操作系统，必须有一个编译器，那么这个时候，可能先要实现一个编译器，或者使用现成的编译器。以微软的实力，实现一个编译器，不是什么难事，至于这个编译器符合那个标准，采用什么语言，微软当然可以有自己的决策，这么说，他可以使用任何语言，甚至自己重新发明一种语言，然后重新实现这个语言的编译器，但微软肯定不会这么做，因为现在的编译器，语言都很成熟，没有必要（此外，这个语言是否符合标准，相信也不是微软首先考虑的问题，因为这个编译器只在微软内部用，既然是自己用，当然自己说了算。最应该考虑的问题，是，这个语言是否可以方便的开发操作系统，是否好用等等，至于这个编译器是否会流行，微软此时根本没有必要考虑这个问题）。此时，微软很可能选择一种开源的编译器，开始用C和汇编，编写自己的操作系统内核部分。
在操作系统的核心部分实现基本完成后，是不是就要考虑操作系统的发布，以及操作系统开发平台的问题了？此时，又有决策需要给出，第一个，windows操作系统的二次开发平台如何设计？平台可以采用什么语言，支持什么功能等等。如果微软够毒，那么他完全可以新设计一种语言，与现在流行的语言完全不同，这种语言专门针对Widows操作系统的二次开发。他们会这么做吗？傻子才这么做！第一个，这种决策影响了操作系统的流行，影响了二次开发，与当前技术主流不相匹配，结果就一个字，死！显然，支持现在流行的编程方式，是最佳选在，如何支持？此时微软就必须考虑流行语言的标准了，例如C99标准，C++标准，等等一系列标准，如何实现这些标准，方法也很多，微软采用了运行时库的办法进行实现，也就是做，VC时基于windows操作系统的，符合C/C++标准的一个编译器。
