kuanhung c

PHP 之父 Rasmus Lerdorf 說，一開始他發明 PHP 是為了在 HTML 裡面提供可以呼叫 C 的接口， 但是偏偏沒有人在乎這個功能，引起其他人注意的反而是其他的功能 XD 這次在 ModernWeb 2015 也聽到 Rust 這個名詞被帶過了兩三次， 雖然沒有人真正介紹他，可是卻引起了我的興趣.... Rust 是 Mozilla 所推廣的新 system level programming language， 他也完成過了自舉，用 Rust 寫的 compiler 去 compile Rust source code. 在 Ruby 裡面也可以呼叫使用 Rust export 出來的 dll ， 看到這，感覺好像是當初 PHP 和 HTML 的故事阿! Rust會有搞頭嗎? Google 所推廣的 Go  lang 似乎比較容易找到相關的消息， 但是找資料的過程看到一個論點是說， 一個新的語言有沒有未來，要看團隊和背後的公司自己是不是有大量和實際的使用， 以免變成有好的構思卻因為曲高和寡，而無法持續獲得社群力量支持... Google 推的 AngularJS 和 React 相較是不是也是一樣的故事？ 有好多新的東西可以學習，可是選擇卻也變得很困難． 還是繼續打好C的基礎，把 Rust 和 React 當成零食閱讀吧!

Microsoft Advanced Threat Analytics 公開預覽現已推出！ 看起來是一個分析 AD 網路封包並且做行為分析的 solution... 一個內建官方知識的 endpoint sensor? 果然官方自己跳下來做的都比較 imba .... XD

終於可以開始 debug DLL project 了! 之前根據 Debugging DLL Projects 的設定， 設定好 debug property 的 caller 並且在 DLL project 裡面設定中斷點， 但是 caller 一被叫起來後，馬上就 exit code 1， 並沒有 hit 到在我在 DLL project 裡設定的中斷點． 原本以為可能是我設定的中斷點不是 entry point ，程式提早結束所以沒有 hit 到． 想一想拿 sample code build 出來的 DLL 去測試，發現 entry point 是對的， DLL debug 的中斷點在 sample code project 裡面也可以正常的 hit 並且停止． 想了很久後再看一次 caller 的文件，發現可以提高 caller 的 debug level ， 所以可以驗證我的另一個猜測，看是不是我指定的 DLL 其實並沒有被載入? 結果 debug log 顯示， DLL 應該是有被正確載入． 但是為什麼 caller log 會一直顯示載入 entry point function 失敗呢? 突然想到，我的 DLL 真的有 export 該 function 嗎? 用 Dependency Walker 去分析我的 DLL ， 發現 x86 build 確實有 export function，但是 x64 build 卻是空白的? 這時候我開始想說，難道是 build configuration 有問題？ 但是 x86 build 的 DLL caller 也是無法正確載入啊? 那先不管 x64 build 好了，感覺 x86 build 比較有機會突破阻礙． 那再來比較 x86 build export 的 function 和 sample code 的有什麼不一樣 仔細一看，原來是 function name 被 mangling 處理過，多了 "_" prefix． 設定好 DLL project 的 def 檔重 build 後， caller 果然可以載入成功並且 hit 中斷點． 而神奇的 x64 DLL export function 是空白的現象也恢復正常了!

在 Visual Studio 裡面 compile 一個原本只有 win32 configuration 的 project． 當新增一個 x64 configuration 並且 Re-build 的時候， 在 linking stage 出現: machine type 'x64' conflicts with target machine type 'X86' 理論上 Visual Studio 會自動幫你複製並且轉換相關的 Win32 > x64 的設定， 例如：VC++ Directories, Library Path 等等... 依照 stackoverflow 上最佳答案建議的四點 一一檢查後，也沒有發現異常． 後來終於發現是在新增 x64 configuration 的時候，additional option 並不會被自動轉換． 所以如果原本 win32 的 additional option 有覆蓋掉其它 option 的設定時， 在新增 x64 configuration 的時候，該 option 也會被複製過來． 而剛好如果該 option 是像 Machine:I386 這種時，悲劇就會發生了.... 分析原因是，舊版的 Visual Studio project 可能會有些 option 要用 additional option 來設定． 而新版的則是變成 內建property ，內建的 property Visual Studio 有辦法去做一些自動化的轉換 像是前面提到的 VC++ Directories 等等 而這個答案是在 stackoverflow 同一個問題的 第二高分的答案 ， 偏偏我是不小心喵到後 linker > advanced 最後的 link command 時， 才瞄到最底下的 additional option .....lol... 不過也好像慢慢的熟悉 Visual Studio 的操作邏輯了....

當你在Visual Studio 裡的 win32 DLL project 開發一個讓別人呼叫的 DLL Adaptor 要怎麼 debug 呢? 因為我們沒有呼叫端程式的原始碼以及 symbol file 唯一有的只有 DLL project source code． 我們只要修改這個 project 的 debugging property， 讓他在我們點下DEBUG的時候去觸發呼叫端的程式， 這樣子當呼叫端使用到 dll 時， 我們就可以藉由在 visual studio 裡設定的中斷點來 dubug 了! Reference: MSDN: Debugging DLL Projects