以下是作者的一些猜想：

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++標準的一個編譯器。