摘要： 虛擬內存， 物理內存，工作集， 頁文件， 堆棧，堆 閱讀全文

摘要： 總之，無論學什么，先深入一個平臺， 從C++編譯器到CRT運行庫， 再到操作系統， 從用戶態API到內核和驅動，越深越好，然后再跳出這個平臺，接觸其平臺，會發現各個平臺基本都是大同小異。 閱讀全文

摘要： 誰知道Windows為什么不用UTF8，非要搞得和其他平臺不一樣？ 閱讀全文

摘要： 盡管我N次吐槽基于GDI的DirectUI界面庫會隨著XP的淡出而逐漸失去市場， 但是實際工作中還是要經常和GDI打交道，外面招聘單位還是有不少Windows客戶端的開發崗位。 在這"移動互聯和"Web前端"橫行的"大數據"時代，很多同事開始向移動App和大數據轉型， 盡管這幾年PC客戶端的開發人員是只出不進， 但是只要Windows存在一天，我們的工作就還是有價值的.. 閱讀全文

摘要： Window上我們常見的資源泄露包括內存和對象句柄泄露， 下面討論下對各類泄露的檢測方法。 閱讀全文

摘要： 一個基本的圖形引擎要包括幾個方面的支持：位圖繪制，文字繪制，矢量繪制(如矩形，線條)。 可惜GDI這個20多年前發明的老古董，對這幾項的繪制， 除了位圖繪制可以通過AlphaBlend支持alpha通道，其他繪制都不支持alpha通道。 閱讀全文

摘要： 工作中有個需求是關于抓取揚聲器的聲音， 為什么會有這個需求？ 試想我們在共享遠程桌面時，如果能夠把本地桌面應用程序的聲音也一起發給對方，然后播放出來， 用戶體驗該是多么棒。 閱讀全文

摘要： 最近工作中有個需求是將Icon轉成帶Alpha通道的Bitmap, 雖然網上有不少這方面的文章，但很多都是錯的， 這里記錄下，或許對后來人有用。 閱讀全文

摘要： 對于客戶端架構設計，個人覺得最大的原則就分層設計， 每層都封裝一個概念并保持獨立， 同時根據依賴倒置的原則， 站在上層客戶的角度提供接口。軟件工程里面的一條黃金定律:“任何問題都可以通過增加一個間接層來解決。 閱讀全文

摘要： 計算機的好處是它永遠不會欺騙你， 它只會按部就班的執行， 所以很多看似奇怪(甚至看似不可思議的問題)， 只要你理解了程序背后的機制原理，都是可以找出根本原因的。 閱讀全文

摘要： 簡單總結下，我們從C++的內置數組講到標準庫提供的vector， 最后談到C++11新增的array, 數組這個最基本的數據結構在C++中終于有了完整的支持。 閱讀全文

摘要： 簡單總結下，操作系統通過一層層的封裝，隱藏了太多的東西， 很多看似簡單的行為， 實際上背后都有很復雜層層調用。理解這些原理，可以讓你的知識達到一定的深度，幫助你更好的解決問題。 閱讀全文

摘要： 如果說以前XP時代我們還有理由不關注高DPI， 那么在移動設備時代和大顯示器的高分辨率時代， 我們就沒有理由不關注高DPI了， 比如Surface Pro的分辨率是1920x1080， 這種情況下如果系統我們不設置高DPI， 基本上就沒法觸摸和操作了，所以現在普通程序對高DPI的支持已經成為趨勢了。 閱讀全文

摘要： 在XP時代我們的程序沒有響應后只能通過任務管理器強制殺掉，但是Vista之后情況變了， 我們仍然可以拖動失去響應的窗口，甚至可以嘗試最小化和關閉窗口， 我們把這個特性叫住Window Ghosting。 閱讀全文

摘要： 最后簡單總結下 ， 我們可以看到Windows系統上基本沒有一種通用的抓屏技術可以高效的抓取所有的系統（XP/Win7/Win8）， 很大一部原因是操作系統的顯示驅動模型在從XPDM向WDDM轉變， 應用層的API也在從GDI向D3D轉變 。 相對于Linux的穩定， Window的不斷發展和進步， 對開發人員究竟是喜是悲？ 閱讀全文

摘要： 我們可以看到數組new[]和delete[]的關鍵是， C++編譯器在數組起始地址之前的4個字節保存了對象的數量N，后面會根據這個數量值進行N次的構造和析構 。 我們可以看到C++ 編譯器在背后干了很多事情，可能會內聯我們的函數， 也可以修改和產生其他一些函數， 而這是很多C開發者受不了的事情， 所以在內核級別， 很多人寧愿用C來減少編譯器背后的干擾。 閱讀全文

摘要： 探討Windows上各種Hook技術：SetWindowsHookEx， SetWinEventHook， API Hook， COM Hook 閱讀全文

摘要： 我們知道Windows的窗口消息處理函數是C方式， 面向過程的， 所以窗口框架的基本任務就是將它轉成面向對象的方式， 確切的說如何將消息處理函數第一參數HWND轉成對象指針。 閱讀全文

摘要： 最近工作 中有個需求是抓取桌面截圖， 這里的桌面是指點了“顯示桌面”之后看到的桌面， 截圖內容包括桌面背景和圖標以及任務欄 閱讀全文

摘要： 記錄一些Windows 安全相關的概念， 分享自己對Windows安全機制的一些理解。 閱讀全文

摘要： 簡單總結下， 語言不在多，在精。經常使用你覺得有價值的語言。深入掌握一門腳本。 閱讀全文

摘要： 很多人說COM過時了， 也許”純正的標準COM“確實是使用的人越來越少了， 但是COM的思想卻一直在后續的軟件開發中被使用和發揚， 可以說COM技術是微軟技術框架的“根”（之一）。 閱讀全文

摘要： 很多人說跟著微軟跑真累，確實如此。 但是回頭來想想， 那是因為你一直落后， 你一直在追趕， 你一直是被趕著走的， 所以你會覺得累。如果你一直是與微軟起頭并進， 甚至領先與微軟（微軟新加的東西是你意料到的）， 你就不會有累的感覺，有新東西出來， 研究下原理， 寫些測試代碼，就大概知道怎么回事了。 閱讀全文

摘要： 越抽象的東西離底層機器就越遙遠， C++隔著復雜的編譯器， Java/C#隔著虛擬機， 腳本語言隔著解釋器， 這就是高級語言的代價。 閱讀全文

摘要： 最近有機會看號稱是公司最核心的代碼， 因為這個代碼以前一直是美國那邊保密的， 這么重要的代碼會是啥樣子？ 真正拿到手大致看了一下后卻挺失望的，因為該代碼風格基本上是我剛畢業時的C++風格----帶類的C，單從代碼上看寫的挺濫，里面沒啥設計模式， 也沒有用模板， 代碼里面甚至一個函數可以寫上近千行。 這么重要的代碼， 竟然是這種風格， 由此思考好的C++程序應該是什么風格？ 閱讀全文

摘要： Windows的API封裝了太多細節， 盡管大部分時候我們只要知道如何使用它們，而不用關心它們的內部如何實現。 但是當你寫一些相對底層的東西，比如開發自己的DirectUI界面庫時， 還是需要真正理解某些API的內部實現原理，才能繼續深入下去。 閱讀全文

摘要： 個人嘗試山寨了下STL， 對STL的6大組件(containers, algorithms, iterators, functors, adaptors, allocators)都有涉及。 當然山寨STL不是為了重復造輪子，而是為了更好的理解和擴展STL。 閱讀全文

摘要： 通過WinDbg結合AppVerifier， 我們可以詳細的跟蹤堆中new出來的每一塊內存。 很多時候在沒有源代碼的Release版本中，在程序運行一段時間后，如果我們發現有大內存或是大量同樣大小的小內存一直沒有釋放， 我們就可以用上面的方法進行分析和快速的定位問題。 閱讀全文

摘要： 盡管這個概念已經讓人說濫了 ，還是想簡單記錄一下， 以備以后查詢。 閱讀全文

摘要： 從編譯時到運行時，從面向對象到普通泛型編程再到模板元編程，C++復雜得讓人無語， 也強大得讓人無語， 而且C++語言本身是在不斷發展的(C++11)， 同一問題在C++中往往有多種解決方案，這些解決方案有的簡單，有的復雜，有的高效， 也有的低效， 而我們的目標就是利用C++這把利器尋找簡單而高效的解決方案。 閱讀全文

摘要： 以前在設計DirectUI界面庫(該界面庫現已開源， 可到 這里 下載)架構時，遇到一個接口繼承相關的問題，當時沒有太好的解決方案，卻一直個耿耿于懷， 現在重新思考整理下。 最后，總結下上面三種方法： 第一種實現和接口混合繼承的方法最簡單，也最容易理解， 缺點是沒法完全基于接口編程； 第二種基于模板的方法比較難理解，實現上也比較簡單， 缺點是代碼膨脹； 第三種多重繼承的方法也比較容易理解， 缺點是我們要多做一些工作。 閱讀全文

摘要： 在上文 在C++中實現事件(委托) 中我們實現的C#里委托方式的事件處理， 雖然使用很方便，但是感覺似乎少了一點C#的味道， 下面我們嘗試把它改成真正的C#版。 其實要改成真正的C#版，我們主要要做2件事， 一是吧CEventHandler放到外面，可以讓外部直接構造， 二是實現operator +=和operator -= 閱讀全文

摘要： 在C++中實現回調機制的幾種方式一文中，我們提到了實現回調的三種方式(C風格的回調函數， Sink方式和Delegate方式)。在面向對象開發中，delegate的方式是最靈活和方便的，因此很早就有人用復雜的模板去模擬， 實現起來很復雜。但是現在借助C++11的function和bind, 我們可以很方便的去實現。 閱讀全文

摘要： 總之， 一開始我們會覺得WinRT很好奇， 但是后來我們逐步發現它其實并沒有那么神秘， 它是很多微軟現有技術的合成體。 微軟的技術更新很多時候讓人眼花潦蘭，但是底層本質的東西(比如COM,D3D,Win32)其實一直很少改變。 閱讀全文

摘要： 最后， 總結一下， 微軟在Intel處理器上開發Windows操作系統， 我們在Windows操作系統上開發應用程序，無非是一層層的封裝， 其實具體到細節， 每層都沒有太多神秘的東西。我們當然不可能掌握每層的細節， 只能理解每層的概念， 以幫助我們在應用層更好的開發。 閱讀全文

摘要： windows程序運行分為內核模式和用戶模式，內核模式可以訪問所有的內存地址空間， 并且可以訪問所有的CPU指令。一般程序運行在用戶模式， 通過系統調用切換到內核模式執行系統功能，Windows系統通過這種方式來確保系統的安全和穩定。 閱讀全文

摘要： 有些人說GP的抽象能力高于OO，這個觀點我并不認同，我感覺只是他們的抽象方式不一樣，OO是基于接口， 而GP是基于concept。OO的基于接口的抽象，在源代碼和最終運行時都能體現，源代碼中是接口，運行時是虛表，所以他們是一致的， 符合普通人的思維習慣。GP基于concept的抽象， 主要體現在源代碼中 ，只是你用來告訴編譯器你的思維方式， 在運行時他可能是一個完全不同的世界，所以比較難理解。 閱讀全文

摘要： 通過上面的分析 ，相信我們知道了為什么ATL/WTL大量使用模板，但是生成的exe還是這么小的原因 ： 不是模板不會使代碼膨脹，而是ATL/WTL在設計時就關注了這個問題 ，它避免了在可能生成很多模板實例的模板類中編寫大量代碼(有些拗口，不知道你有沒有讀懂^_^) 總結下 ，如果你想用模板，但是又不想 讓自己最終的可執行文件變的很大， 有2種方式: (1)你的模板類不會生成很多模板實例，這樣寫成模板類還有意義嗎? (2)你的模板類的代碼量或是函數個數很少，你可以仿照ATL的方式把模板無關的東西逐層剝離。 閱讀全文

摘要： 以我個人的經驗，一些東西剛開始看不太懂就放一放，先去看一些基本的東西，比如不懂COM，先去學下C++ 中的虛函數；不懂C++模板，先去學下STL；不懂Thunk，先去看一下匯編，等有了一定的積累，回頭再看，一切就覺得沒這么難了。 閱讀全文

摘要： 經過上面的比較， 我們可以得出一些結論： 消息方式的強項是耦合性和擴展性，以及監控的方便性，個人感覺比較適合于Server端的規模應用。 接口方式的強項是性能高效以及開發的方便性， 比較適用于同一進程內客戶端的小規模應用。 但是大部分時候， 對于架構師或是公司領導，他們會更關注可耦合性和可擴展性，所以他們會傾向于選擇消息方式，盡管有時可能不是那么適用。 閱讀全文