感謝軟體作者給了這麼好的一個工具，文件也寫得好。我下載了一個影片Codec的開源專案，由於我只需要解碼（decode）部分，那些龐大繁複的“編碼（encode）”過程可以不要，所以用這個工具試了一下，可以看出軟體是強大的，可惜卡在系統標頭檔案（ windows.h 之類）上了，雖然可以用 -include 引數來補充，但是不妨這樣想，一來 這類系統標頭檔案本身就不允許改寫的，你去掃描分析並沒有現實意義。二來系統自帶的標頭檔案 總是呼叫系統SDK的，這類SDK檔案同樣也是 分析出來也不能改寫，所以完全可以略過不管，應該把軟體設定為“僅掃描專案dir下的檔案”，這樣既簡單又安全。
其實想最佳化SDK標頭檔案是很簡單的，我們只需手工加上 // 註釋掉 include <windows.h> 語句，然後看看編譯會否出錯就行了，如果出錯，老老實實 include 吧，難道我們還敢開啟 windows.h 去改它嗎？？另外還有一個實際情況，SDK裡面基本就是 結構/類 定義，然後就是大量呼叫系統DLL函式，也就是一條一條的宣告語句而已，實際上並沒有多少執行程式碼。反之，如果有執行程式碼，那麼往往就是很常用的，例如 printf 之類，所以SDK的“最佳化”並沒有現實意義。
另外，這個軟體不能識別 def 檔案，對於 DLL 專案是一個缺陷。譬如在 def 檔案中我 只需 輸出 2個 DLL函式，這樣 dll.cpp 裡面其它“無關”的函式是可以最佳化的。當然折衷辦法還是有的，可以另外寫一個 fake.cpp，裡面僅包含這兩個函式，然後單獨最佳化這個 fake.cpp 即可。
所以我建議作者優先解決“略過 系統SDK檔案”的問題，讓這個軟體在“自然狀態”下能夠跑起來，而不是頻繁中斷在 windows.h 等一堆 SDK 之下，丟擲一個接一個error，使用者被迫不斷修改命令列（變得“水蛇春咁長”），意興闌珊。
感謝軟體作者給了這麼好的一個工具，文件也寫得好。我下載了一個影片Codec的開源專案，由於我只需要解碼（decode）部分，那些龐大繁複的“編碼（encode）”過程可以不要，所以用這個工具試了一下，可以看出軟體是強大的，可惜卡在系統標頭檔案（ windows.h 之類）上了，雖然可以用 -include 引數來補充，但是不妨這樣想，一來 這類系統標頭檔案本身就不允許改寫的，你去掃描分析並沒有現實意義。二來系統自帶的標頭檔案 總是呼叫系統SDK的，這類SDK檔案同樣也是 分析出來也不能改寫，所以完全可以略過不管，應該把軟體設定為“僅掃描專案dir下的檔案”，這樣既簡單又安全。
其實想最佳化SDK標頭檔案是很簡單的，我們只需手工加上 // 註釋掉 include <windows.h> 語句，然後看看編譯會否出錯就行了，如果出錯，老老實實 include 吧，難道我們還敢開啟 windows.h 去改它嗎？？另外還有一個實際情況，SDK裡面基本就是 結構/類 定義，然後就是大量呼叫系統DLL函式，也就是一條一條的宣告語句而已，實際上並沒有多少執行程式碼。反之，如果有執行程式碼，那麼往往就是很常用的，例如 printf 之類，所以SDK的“最佳化”並沒有現實意義。
另外，這個軟體不能識別 def 檔案，對於 DLL 專案是一個缺陷。譬如在 def 檔案中我 只需 輸出 2個 DLL函式，這樣 dll.cpp 裡面其它“無關”的函式是可以最佳化的。當然折衷辦法還是有的，可以另外寫一個 fake.cpp，裡面僅包含這兩個函式，然後單獨最佳化這個 fake.cpp 即可。
所以我建議作者優先解決“略過 系統SDK檔案”的問題，讓這個軟體在“自然狀態”下能夠跑起來，而不是頻繁中斷在 windows.h 等一堆 SDK 之下，丟擲一個接一個error，使用者被迫不斷修改命令列（變得“水蛇春咁長”），意興闌珊。