在乙個純win32程式裡，假如我們只使用標準的api，那麼編譯出來的程式依然需要執行時的庫，原因很簡單，因為windows預設的winmain函式是由執行時函式startup呼叫的，所以在這種情況下必然會用到msvcrt80、90的庫。解決的辦法是
方法一：
修改專案屬性－》c/c++->**生成->執行時庫 （將除錯dll或dll修改為相應版本的非dll），這種方法就相當於將動態連線修改為靜態鏈結。當然了這麼做會使程式本身體積變大。
方法二：
利用巨集#pragma comment(linker,"/entry:startup")
這個巨集修改了函式的入口點函式，這樣，windows載入程序時就不會先進入crt函式了。
以上兩種方法都存在一些侷限性。比如方法二中的**必須不能使用任何crt函式，而面對mfc編寫的程式兩種方法就都無能為力了，下面介紹一種萬能的方法：
方法三：
通過使用wdk或者ddk對程式進行編譯。驅動編譯的優點是我們可以指定所有的鏈結lib庫，通常情況大家都會選擇系統使用的庫。而如果是mfc的類庫在vc8或vc9中是根本不能自由選擇的，編譯都是設定死的。而採用驅動編譯，就可以將這些庫統統修改為mfc42.dll的依賴，這樣就不存在高階版本靜態鏈結和打包執行庫的痛苦了。當然了採用這種方法時，一些vc6沒有帶的高階的方法是呼叫不了的。所以，其實也都或多或少的存在些不足。
vc8 與 vc6效能有無差異？
把原來的工程從vc6改寫到vs2005 vc8下，暈頭暈腦的看了半天vs2005的設定，現在最想知道的是vc8與vc6，那個編譯出來的程式效能高？不知道有沒有相關的結論。為此專門寫了兩個工程，有大量的網路操作 檔案io 大記憶體 整數計算 似乎效能相近。乙個連線 今天測試了一早上，基本可以肯定 vc...
公升級VC7專案到VC8的注意事項
posted on 2005 12 20 23 34 vince yuan 在2005年年中的時候，公司就準備轉移到visual studio 2005上開發產品。本人有幸參與了公升級的過程，成功的把30個左右solutions 幾百個projects公升級到了vc8。由於專案眾多，並且專案還在持續...
現在才知道TR1的錯誤在VC9的SP1中解決
習慣了用boost庫的function，今天使用vs2005 sp1編譯乙個程式，用到了std function,結果出現了 error c2039 function 不是 std 的成員的錯誤，但是我已經 include 了啊！上網搜了搜，初步判斷是vs 2005並不支援std function。...