系統(tǒng)理解Win32 API和MFC(上)
作者: 溫昱
作者主頁: lcspace.diy.163.com
Win32 API是微軟的操作系統(tǒng)Windows提供給開發(fā)人員的編程接口，它決定了我們開發(fā)的Windows應(yīng)用程序的能力。MFC是微軟為開發(fā)人員提供的類庫，在某種意義上是對Win32 API的封裝。本文試圖從全局角度對Win32 API和MFC進行理解──給出二者的概念模型。
本文使用UML描述概念模型。Win32 API本不是面向?qū)ο蟮?，我用面向?qū)ο蟮挠^點去理解它，無非是想表達其全局。
本文參考了MSDN、相關(guān)書籍和網(wǎng)上的一些資料，在此一并感謝。
一、Win32 API的概念模型Win32 API的object有3種：user obj，gdi obj，kernel obj。但是，如果一點不考慮OS本身的支持，就會在有些問題上疑惑，因此，我這里把“operation system負責(zé)將中斷封裝成message”加上。
1、user obj、gdi obj、kernel obj、system 4者的關(guān)系 由于是kernel obj部分負責(zé)將另外3者聯(lián)系起來，因此我們在下圖中直接深入到kernel obj部分內(nèi)部。
從圖中看到，在內(nèi)存中運行的，除了“負責(zé)將中斷封裝成message”的system支持部分，還有另外3類object：kernel obj、user obj和gdi obj，每個obj都有一個句柄handle與之對應(yīng)。其中，gdi obj建立了待開發(fā)的Windows 應(yīng)用和外部輸出設(shè)備的聯(lián)系，kernel obj中的file建立了內(nèi)存和永久存儲設(shè)備的聯(lián)系。具體說，內(nèi)存中的file從可以從硬盤上來，如果這個file是可執(zhí)行文件，它將生成module，module運行起來就是process，process可以包含多條thread，而thread的運行映象最終還是來自于file。thread是kernel obj中最重要的一個，因為消息隊列就是thread擁有的，只有thread才能夠接受message。對gdi obj、urser obj和file的操作，也是發(fā)生在thread中的。所以書都講，process至少擁有一個thread。
2、展開“system負責(zé)將中斷封裝成message”部分下面展開“system負責(zé)將中斷封裝成message”部分，盡早解除對“message到底是怎么形成的”的困惑。
3、展開“gdi obj”部分
開發(fā)人員可以通過gdi obj將app的信息反饋給User。
從圖中看到，gdi obj有8種，其中7種為：bmp，brush，pen，region，font，palette，path。另一種比較特殊的是DC，它可以被理解為一種容器，程序員通過調(diào)用SelectPallette()將pallte放入容器，通過調(diào)用BeginPath()和EndPath()將path放入容器，其它5種gdi obj，是通過調(diào)用SelectObject()放入容器的。DC又具體分為4種，其中DisplayDC就是最常用的用來支持我們“畫Window”的DC。 另外，如果覺得不好理解，請參考composite設(shè)計模式。
4、展開user obj部分
4.1 第1次迭代
window在Windows應(yīng)用開發(fā)中占有重要地位。
從圖中看到，window可分為3種：desktop，top-level window，child window。所有window被OS組織成tree，有專門的數(shù)據(jù)結(jié)構(gòu)來管理。desktop就是樹根，desktop的子節(jié)點是top-level window，top-level window的子節(jié)點是child window，child window仍然可以有子節(jié)點，同樣歸屬于child window。tree數(shù)據(jù)結(jié)構(gòu)中還記錄了4種重要信息，是4種指針：parent指針、child指針、brother指針、owner指針。這樣，從任何一個window就能很容易地找到其它window了。
好了，暫且得到 window = desktop + topLevel + child 的結(jié)論，看看全局先。畢竟，一步到位有時候并不好。
從圖中看到，window確實占有重要地位。從邏輯是講，thread是window的擁有者；但是，所有window一起決定了屏幕看起來是上面樣子，何況點擊任何一個window都會使window得相互覆蓋關(guān)系發(fā)生變化，對所用window進行統(tǒng)一管理是必須的，所以O(shè)S又不得不統(tǒng)一用window tree來管理window，反映復(fù)雜的window關(guān)系。每個window都必須有一個且只能有一個客戶區(qū)，還可能有一個title bar。
再來看看CreateWindow()函數(shù)的interface spec透露了哪些信息。
從圖中看到，CreateWindow()負責(zé)為window建立與窗口類的聯(lián)系。每個window都有一個窗口類與之對應(yīng)，而一個窗口類可以對應(yīng)多個window。窗口類中記錄了窗口函數(shù)和菜單等資源信息，而由file生成的module正是窗口函數(shù)和資源的老家。
4.2 第2次迭代
考察消息種類。
從圖中看到，每個message都是發(fā)送給某個window的。注意，msg可由SYS代碼產(chǎn)生，也可以由API函數(shù)產(chǎn)生。
進一步考察window，深入topLevel和child。
從圖中看到，OVERLAPPED風(fēng)格的window是top-level window的一種，而另一種POPUP風(fēng)格的window從本質(zhì)上(行為上)是特殊的一種OVERLAPPED風(fēng)格的window，雖然我們從coding的角度常常不這么認為。
還是不好，因為當我們調(diào)用CreateWindow() API函數(shù)時，明明感覺CHILD、OVERLAPPED、POPUP是“window style”。我再畫一張圖。
從圖中看到，control必須是CHILD風(fēng)格的，dialog必須是POPUP風(fēng)格的，而一般性的window卻可以是任意風(fēng)格的。
4.3 第3次迭代
總結(jié)user obj:
CreateDialog()函數(shù)示意:
從圖中看到，CreateDialog()和CreateWindow()最大的區(qū)別就是，它有對話框模板支持方便地定制dialog界面。注意，Dialog是特殊的window，窗口類它一定也是有的。