1.Dependency Walker的第一道揭秘在MFC中我們寫過(guò)很多靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)。這些dll都依賴于MFC；然后我們又交給別人使用，使得它們被依賴。 細(xì)想一下，就可能會(huì)發(fā)現(xiàn)其中的不平衡。我們生成的非組件dll，要交給別人使用，必須提供h頭、lib庫(kù)和dll庫(kù)文件；可是我們使用MFC的dll時(shí)，好像什么也沒(méi)有設(shè)置，MFC不請(qǐng)自來(lái)的加入到我們的程序中。雖然知道這個(gè)世界，每個(gè)人其實(shí)并不是平等的；但是在計(jì)算機(jī)的世界，自由平等卻是第一法則。搞清MFC如何嵌入到我們的應(yīng)用程序中，將一切黑暗中的操作暴露出來(lái)，將是我們的任務(wù)。 舉個(gè)例子，隨便用向?qū)梢粋€(gè)MFC 的對(duì)話框程序。里面測(cè)試一個(gè)組件，然后調(diào)用wcslen求一個(gè)BSTR的長(zhǎng)度。就是一個(gè)很簡(jiǎn)單的exe；通過(guò)Dependency Walker就發(fā)現(xiàn)它依賴了很多dll。如下： 
2.MFC的組成直接揭開謎底：MFC由四部分組成?？赡苓@種說(shuō)法不準(zhǔn)確，應(yīng)該說(shuō)，VC的核心底層API由下面部分組成：
如下表：  其實(shí)看看vc的目錄組織結(jié)構(gòu)大概也知道其分組。 
MFC 靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)最流行的是使用MFC作為dll，同時(shí)將自身的也作為dll。在這種情況下，如果深挖進(jìn)去，最容易發(fā)現(xiàn)的是MFC的dll。 參照 MSDN中的“Naming Conventions for MFC DLLs”，可以發(fā)現(xiàn)，基于動(dòng)態(tài)鏈接庫(kù)的MFC的命名規(guī)范為：MFC[D|O|N]x[U][D].DLL。 主要包含的屬性為：功能模塊（Core | OLE | DB | NET），版本（VC6對(duì)應(yīng)42，VS2003對(duì)應(yīng)70，VS2005對(duì)應(yīng)80，VS2008對(duì)應(yīng)90），是unicode還是Ansi，是release還是debug。 稍微注意的是：debug版本下每個(gè)功能模塊對(duì)應(yīng)一個(gè)lib；但是release版本下，合起來(lái)為一個(gè)統(tǒng)一的lib文件MFC42.lib。 其實(shí)還存在，靜態(tài)鏈接庫(kù)。但是其名字可能更不著調(diào) ：[N|U]AFXDW[D].LIB 其中包含unicode和非unicode，debug和release區(qū)分。 CRT 靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)參照MSDN中的“INFO: What Are the C/C++ Libraries My Program Would Link With?”。 當(dāng)我們調(diào)用sprintf，wcslen等此類函數(shù)時(shí)，我們就依賴了該庫(kù)。 這個(gè)可以通過(guò)編譯設(shè)置：  實(shí)際上對(duì)應(yīng)的編譯項(xiàng)是：/MD /ML /MT  3.靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)核心有關(guān)靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)的相關(guān)概念，以及連接中出現(xiàn)的一些問(wèn)題，其實(shí)所有的核心就是：
真正所謂取之與民，用之于民。 其中還經(jīng)常出現(xiàn)的一個(gè)問(wèn)題是，引用的系統(tǒng)底層庫(kù)有哪些，到底是靜態(tài)庫(kù)還是動(dòng)態(tài)庫(kù)。通常，對(duì)于MFC程序，一定會(huì)依賴于MFC庫(kù)；可以選擇性的依賴CRT庫(kù)。搞清楚使用的靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)，不要沖突就行。 幾種靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)在VC6中，對(duì)于靜態(tài)動(dòng)態(tài)庫(kù)，去除組件作為一種特殊的動(dòng)態(tài)庫(kù)外，還剩下5種類型。一一生成一個(gè)演示程序，研究設(shè)置，大概就可以看出區(qū)別。 靜態(tài)庫(kù)導(dǎo)出的是 h頭文件和lib文件。該lib文件包含著程序代碼，會(huì)比較大。源代碼編譯的時(shí)候使用頭文件，鏈接的時(shí)候使用lib文件。 動(dòng)態(tài)庫(kù)導(dǎo)出的是 h頭文件、lib和dll文件。該lib文件只包含著程序的函數(shù)索引位置，比較小。源代碼編譯時(shí)使用頭文件，鏈接時(shí)使用lib文件，運(yùn)行時(shí)需要dll文件。  以下是對(duì)各dll分析：  其實(shí)，本質(zhì)上可以看出，只有兩種庫(kù)：靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)；標(biāo)明自身是靜態(tài)庫(kù)還是動(dòng)態(tài)庫(kù)。 靜態(tài)庫(kù)由于生來(lái)是被別人使用的，所以也就不存在導(dǎo)入導(dǎo)出標(biāo)識(shí)； 而動(dòng)態(tài)庫(kù)一定要存在導(dǎo)入導(dǎo)出標(biāo)識(shí)。對(duì)于dll，存在MFC dll和普通的win dll。其實(shí)所謂的MFC dll只不過(guò)是將DllMain進(jìn)行特殊封裝，特別是為了方便資源的存取。而所謂的Extension dll，只不過(guò)是為了兼容C；要求只導(dǎo)出非MFC類的函數(shù)而已。 這些靜態(tài)庫(kù)如何使用MFC 庫(kù)，如何使用CRT庫(kù)，其實(shí)都是可以設(shè)置的。這點(diǎn)用來(lái)解決引用庫(kù)是什么庫(kù)。 對(duì)于靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)，MFC向?qū)蓵r(shí)，會(huì)自動(dòng)弄出一些編譯設(shè)置項(xiàng)。但是最根本的核心還是dsp中的： # TARGTYPE "Win32 (x86) Static Library" 0x0104 !MESSAGE "TestStaticLib - Win32 Release" (based on "Win32 (x86) Static Library") !MESSAGE "TestStaticLib - Win32 Debug" (based on "Win32 (x86) Static Library") 如果要將一個(gè)靜態(tài)庫(kù)編譯成另一個(gè)動(dòng)態(tài)庫(kù)，或者相反；只需要在dsp中統(tǒng)一查找替換為另一種格式即可。當(dāng)然，更加鼓勵(lì)的是生成多個(gè)編譯配置項(xiàng)。 避免沖突的方法對(duì)于靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)，在編譯鏈接中總是會(huì)存在問(wèn)題。這些問(wèn)題的根本原因在于：一個(gè)工程中，同時(shí)對(duì)于某一個(gè)工程，既引入了其靜態(tài)庫(kù)，又引入了其動(dòng)態(tài)庫(kù)。這樣會(huì)出現(xiàn)同名沖突。
4.如何最大化最合理利用各功能庫(kù)
原則，盡量少的依賴庫(kù)。對(duì)于同功能的函數(shù)，可能CRT有，Win API庫(kù)，MFC庫(kù)，選擇性的找到正確的庫(kù)。 |
|
|
