跳到主要內容

發表文章

wxWidget with Visual Studio

wxWidgets Compile Option:     UNICODE=1 SHARED=1 VENDOR=xxx MONOLITHIC=1 Visual Studio x64/Release Project Properties: C/C++ > General > Additional Include Directories:     "C:\wxWidgets-2.9.4\lib\vc_x64_dll\mswu";     "C:\wxWidgets-2.9.4\include"; C/C++ > Preprocessor > Preprocessor Definitions:     WXUSINGDLL; _UNICODE Linker > General > Additional Library Directories:     "C:\wxWidgets-2.9.4\lib\vc_x64_dll" Linker > Input > Additional Dependencies:     "wxmsw29u.lib" Hints:     Include path 記得要設定到對的path, 因為 setup.h 在很多個目錄都可能會出現,在我的環境裡我要使用的是 " C:\wxWidgets-2.9.4\lib\vc_x64_dll\mswu\wx\setup.h ",如果設錯的會,compiler 會抱怨找不到  wxbase294.lib ... 但這個檔案應該是錯誤的,他真的不存在,選到正確的 path 後就不會該 error  了       如果沒有設定正確的 Additional Dependencies 會出現 unresolved external symbol 如下的 compile error.... error LNK2019: unresolved external symbol "__declspec(dllimport) pub...

windows 7 瘦身

為什麼喜歡用 OSX ? 我想有一半以上的原因是因為它的字體吧! 雖然 windows 的瀏覽器可以用微軟正黑體或者 Google Noto Fonts 但我還是很不習慣 windows 系統預設過於纖細且不平衡的字體.... 以前勤奮的時候還會用 GDI++ or MacFonts 去渲染系統的字型 但是 OSX 一裝好就都不用再做其他調整真的讓我很開心... 但有時候還是得要用 windows 例如公司專案的 Microsoft Visual Studio...選者 vSphere Client 在 Parallels 裡面用 Garena 打 LoL...etc... Windows VM 要怎麼瘦身呢? 關閉系統還原點 關閉 Hibernation: powercfg /h off 討人厭的 winsxs: 清理磁碟空間的時候,點選清理系統檔案  ( KB52386 ) 刪除%systemroot%/software distrobution/download 裡面的暫存檔 不過這樣我的 winsxs 還是有將近 10G... 我想還是要等 windows 10 出來後,看能不能讓 windows 不要再越用越肥大了... 或說我把用了一年的 Mavericks 升級到 Yosemite 瞬間多了 30多G 的可用空間出來... OSX 真的是太強大了.... Ref:  Disk Cleanup Wizard addon lets users delete outdated Windows updates on Windows 7 SP1 or Windows Server 2008 R2 SP1

Dell U2415 Power Save Mode

換下舊的 VK266H 把 U2415 接上 HDMI port 做雙螢幕輸出, 螢幕卻總是顯示 Power Save Mode. 原本以為是 HDMI 線不合,後來再搜尋了一下文章 發現 Dell 的客服有教一些特別的步驟 1. 關閉螢幕電源 2. 拔除螢幕上所有的線材 3. 按電源鍵 8 秒 4. 接回 HDMI 線 5. 接回電源線 登登~ 螢幕就正常了~ 讓我覺得有趣的是步驟 3, 沒電源的狀況下還是要按著觸控感應的電源鍵 8 秒? 另外步驟 4 和 5 也和我平常習慣的順序不一樣... Ref:  U2415 goes into Power Save Mode?

Interoperability between Rust and Ruby

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 當成零食閱讀吧!

Export DLL Symbols

終於可以開始 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 是空白的現象也恢復正常了!...

build fail: machine type 'x64' conflicts with target machine type 'X86'

在 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 的操作邏輯了....