原文地址：http://hi.baidu.com/freedomknightduzhi/blog/item/a0504560d1277555ebf8f8ff.html
1：神馬是Dll和Lib，神馬是靜態(tài)鏈接和動(dòng)態(tài)鏈接
大家都懂的，DLL就是動(dòng)態(tài)鏈接庫(kù)，LIB是靜態(tài)鏈接庫(kù)。DLL其實(shí)就是EXE，只不過(guò)沒(méi)main。
動(dòng)態(tài)鏈接是相對(duì)于靜態(tài)鏈接而言的。所謂靜態(tài)鏈接就是把函數(shù)或過(guò)程直接鏈接到可執(zhí)行文件中，成為可執(zhí)行程序中的一部分，當(dāng)多個(gè)程序調(diào)用同樣的函數(shù)時(shí)，內(nèi)存里就會(huì)有這個(gè)函數(shù)的多個(gè)拷貝，浪費(fèi)內(nèi)存資源。而動(dòng)態(tài)鏈接則是提供了一個(gè)函數(shù)的描述信息給可執(zhí)行文件（并沒(méi)有內(nèi)存拷貝），當(dāng)程序被夾在到內(nèi)存里開(kāi)始運(yùn)行的時(shí)候，系統(tǒng)會(huì)在底層創(chuàng)建DLL和應(yīng)用程序之間的連接關(guān)系，當(dāng)執(zhí)行期間需要調(diào)用DLL函數(shù)時(shí)，系統(tǒng)才會(huì)真正根據(jù)鏈接的定位信息去執(zhí)行DLL中的函數(shù)代碼。
在WINDOWS32系統(tǒng)底下，每個(gè)進(jìn)程有自己的32位的線性地址空間，若一個(gè)DLL被進(jìn)程使用，則該DLL首先會(huì)被調(diào)入WIN32系統(tǒng)的全局堆棧，然后通過(guò)內(nèi)存映射文件方式映射到這個(gè)DLL的進(jìn)程地址空間。若一個(gè)DLL被多個(gè)進(jìn)程調(diào)用，則每個(gè)進(jìn)程都會(huì)接收到該DLL的一個(gè)映像，而非多份的拷貝。但，在WIN16系統(tǒng)下，每個(gè)進(jìn)程需要擁有自己的一份DLL空間，可以理解為何靜態(tài)鏈接沒(méi)啥區(qū)別。
2：DLL和LIB區(qū)別和聯(lián)系。
DLL是程序在運(yùn)行階段才需要的文件。
LIB是程序編譯時(shí)需要鏈接的文件。
DLL只有一種，其中一定是函數(shù)和過(guò)程的實(shí)現(xiàn)。
LIB是有兩種。若只生成LIB的話，則這個(gè)LIB是靜態(tài)編譯出來(lái)的，它內(nèi)部包含了函數(shù)索引以及實(shí)現(xiàn)，這個(gè)LIB會(huì)比較大。若生成DLL的話，則也會(huì)生成一個(gè)LIB，這個(gè)LIB和剛才那個(gè)LIB不同，它是只有函數(shù)索引，沒(méi)有實(shí)現(xiàn)的，它很小。但是這倆LIB依然遵循上個(gè)原則，是在編譯時(shí)候是需要被鏈接的。若不鏈接第一個(gè)LIB的話，在程序運(yùn)行時(shí)會(huì)無(wú)法找到函數(shù)實(shí)現(xiàn)，當(dāng)?shù)簟Ｈ舨绘溄拥诙€(gè)LIB的話，在程序運(yùn)行時(shí)依然會(huì)無(wú)法找到函數(shù)實(shí)現(xiàn)。但第二種LIB有一種替代方式，就是在程序里，使用LoadLibrary,GetProcAddress替代第二個(gè)LIB的功能。第一種LIB生成的EXE文件會(huì)很大，因?yàn)長(zhǎng)IB所有信息被靜態(tài)鏈接進(jìn)EXE里了。第二種LIB生成的EXE文件會(huì)比較小，因?yàn)楹瘮?shù)過(guò)程實(shí)現(xiàn)依舊在DLL內(nèi)。
（啰嗦了一堆，某志希望大家能夠明白兩個(gè)LIB的區(qū)別。要再不行的話，我們可以將靜態(tài)編譯的LIB稱(chēng)為 靜態(tài)鏈接庫(kù)。但動(dòng)態(tài)編譯的LIB稱(chēng)為
引入庫(kù)。可能會(huì)比較好一些。）
靜態(tài)鏈接LIB的優(yōu)點(diǎn)是免除掛接動(dòng)態(tài)鏈接庫(kù)，缺點(diǎn)是EXE大，版本控制麻煩些。
動(dòng)態(tài)鏈接DLL的優(yōu)點(diǎn)是文件小，版本更換時(shí)換DLL就好了，缺點(diǎn)是多了點(diǎn)文件。動(dòng)態(tài)鏈接若是被多個(gè)進(jìn)程使用，會(huì)更加方便和節(jié)省內(nèi)存。
3：為什么編譯DLL時(shí)總會(huì)同時(shí)生成一個(gè)LIB？這個(gè)LIB有用嗎？
若我們不是用靜態(tài)鏈接，而使用DLL，那么我們也需要一個(gè)LIB，這個(gè)LIB的作用是被鏈接到程序里，在程序運(yùn)行時(shí)告訴系統(tǒng)你需要什么DLL文件。這個(gè)LIB里保存的是DLL的名字和輸出函數(shù)入口的順序表。它是有意義的。
當(dāng)然，若我們的應(yīng)用程序里不鏈接這個(gè)LIB，則可以使用LoadLibrary,GetProcAddress來(lái)告訴系統(tǒng)我們?cè)谶\(yùn)行時(shí)需要怎么著DLL以及其內(nèi)的函數(shù)。
4：DLL意義。
1：DLL真正實(shí)現(xiàn)了跨語(yǔ)言。各種語(yǔ)言都可以生成DLL，而對(duì)系統(tǒng)以及應(yīng)用程序來(lái)說(shuō)，哪種語(yǔ)言生成的DLL是沒(méi)有區(qū)別的。
2：DLL有足夠的封裝性，對(duì)于版本更新有很大好處。因?yàn)镈LL是運(yùn)行期間才會(huì)使用，所以，即使DLL內(nèi)函數(shù)實(shí)現(xiàn)有變化（只要參數(shù)和返回值不發(fā)生變化），程序是不需要進(jìn)行編譯的。大大提高了軟件開(kāi)發(fā)和維護(hù)的效率。
3：DLL被多個(gè)進(jìn)程使用，因?yàn)橛袃?nèi)存映射機(jī)制，無(wú)需占用更多內(nèi)存。
5：創(chuàng)建DLL。（注意：某志就不再講解使用MFC AppWizard[dll] 方式創(chuàng)建DLL了。有興趣的自己去百度。這里創(chuàng)建DLL只指使用Win32
Dynamic-link Library創(chuàng)建Non-MFC DLL。呃，DLL的三種類(lèi)型就不解釋了，依舊那句話：百度一下你就知道。）
每個(gè)應(yīng)用程序必須有一個(gè)main或者winmain函數(shù)作為入口，DLL一樣，有自己的缺省的入口函數(shù)，就是DllMain。函數(shù)如下
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID
lpReserved)
{
switch (ul_reason_for_call)
{
case
DLL_PROCESS_ATTACH: // 進(jìn)程被調(diào)用
case DLL_THREAD_ATTACH: // 線程被調(diào)用
case
DLL_THREAD_DETACH: // 線程被停止
case DLL_PROCESS_DETACH:
// 進(jìn)程被停止
break;
}
return TRUE;
}
一般情況下，我們不需要對(duì)這個(gè)缺省的入口函數(shù)進(jìn)行什么修改，它就會(huì)使動(dòng)態(tài)鏈接庫(kù)得到正確的初始化。但是，當(dāng)我們的DLL需要額外分配內(nèi)存或者資源的時(shí)候，或者，DLL希望對(duì)調(diào)用自己的進(jìn)程或線程進(jìn)行初始化或清除的額外操作時(shí)，可以在上述代碼case中加一些自己感冒的東東。（懶……不想細(xì)寫(xiě)了-
-Orz，現(xiàn)在是晚上2點(diǎn)了，明天還一堆的事情）
DLL對(duì)于導(dǎo)出類(lèi)和導(dǎo)出函數(shù)沒(méi)啥不同。只要加上 __declspec( dllexport ) 修飾函數(shù)或者類(lèi)就好了。
但是有查看過(guò)DLL代碼的人員都會(huì)經(jīng)常見(jiàn)到這么一段代碼
#ifdef FK_DLL_EXPORTS
#define FK_DLL __declspec( dllexport )
#else
#define FK_DLL __declspec( dllimport )
#endif
意義很明顯，但是，問(wèn)題是 FK_DLL_EXPORTS 這個(gè)宏是應(yīng)該在哪兒定義呢？在DLL項(xiàng)目?jī)?nèi)，還是在使用DLL的應(yīng)用程序內(nèi)？
這點(diǎn)某志曾迷糊很久，呵呵~其實(shí)后來(lái)想想，還是蠻明確的。export是導(dǎo)出。import是導(dǎo)入。對(duì)于DLL來(lái)說(shuō)，是要導(dǎo)出這些函數(shù)給其他應(yīng)用程序使用的，所以應(yīng)當(dāng)定義
FK_DLL_EXPORTS 宏。對(duì)于使用DLL的應(yīng)用程序來(lái)說(shuō)，是導(dǎo)入，是無(wú)需定義的。
使用時(shí)候也很簡(jiǎn)單。
class FK_DLL CMyDllClass{} ;
則整個(gè)類(lèi)被導(dǎo)出。
FK_DLL void MyTestFun( int a );
則該函數(shù)被導(dǎo)出。
但是有時(shí)我們可以見(jiàn)到這樣的代碼
extern "C" FK_DLL void MyTestFun2( float b );
其中extern "C"的原理就是標(biāo)示該函數(shù)要求以C形式去進(jìn)行編譯，不要以C++形式去編譯。具體的編譯原理就不羅嗦了，簡(jiǎn)而言之，被extern
"C"定義函數(shù)，可以被C以及其他語(yǔ)言進(jìn)行DLL調(diào)用，而未被extern "C"定義的函數(shù)，C是無(wú)法訪問(wèn)DLL中這個(gè)函數(shù)的。
在VS中開(kāi)發(fā)DLL還有一種方式，使用.def文件。
新建個(gè)文本文檔，改后綴為FKDll.def，加入到工程里。
FKDll.def里加入以下代碼
LIBRARY FKDll
EXPORTS
MyTestFun@1
MyTestFun2@2
就可以了。其中，LIBRARY語(yǔ)句是說(shuō)明.def文件是屬于FKDll這個(gè)Dll的。EXPORTS下面是我們需要導(dǎo)出的函數(shù)名。后面加的@+數(shù)字，是表示導(dǎo)出函數(shù)的順序編號(hào)。這樣就足夠了。（詳細(xì)的自己百度，好困，zzzZZZ）
6：使用DLL
使用DLL有兩種方式。顯式鏈接和隱式鏈接。
隱式鏈接很容易。直接#progam comment(lib, "FKDll.lib")
就可以。當(dāng)然，也可以在項(xiàng)目工程->屬性->鏈接庫(kù)里加上庫(kù)和路徑（相對(duì)路徑和絕對(duì)路徑都可以）。
顯式鏈接則麻煩些。在程序中使用LoadLibrary加載DLL，再GetProcAddress獲取函數(shù)實(shí)現(xiàn)，在程序退出之前，調(diào)用FreeLibrary來(lái)動(dòng)態(tài)釋放掉鏈接庫(kù)。
例如：
void Main()
{
typedef void (*FKDllFun1)(int a);
FKDllFun1 pFun1;
HINSTANCE hDLL = LoadLibrary("FKDll.dll"); // 若hDll為空則讀取Dll失敗。
pFun1 = (pFun1)GetProcAddress(hDll, "MyTestFun1" ); //
從應(yīng)用程序中的DLL鏡像中獲取名為 MyTestFun1 的函數(shù)指針
pFun1( 100 );
FreeLibrary(hDll);
}
當(dāng)然，我們剛才.def里面還指定了導(dǎo)出函數(shù)的導(dǎo)出順序，那么我們可以修改里面獲取函數(shù)指針那一段為
pFun1 = (pFun1)GetProcAddress(hDll, MAKEINTERSOURCE(1) ); // 1
是剛才指定的MyTestFun1函數(shù)導(dǎo)出順序編號(hào)。
這樣可以更快，但是別將編號(hào)記混了，會(huì)導(dǎo)致詭異的錯(cuò)誤。
7：比較顯式鏈接和隱式鏈接。
可能的話，盡量使用顯式鏈接。
顯式鏈接可以在程序執(zhí)行時(shí)動(dòng)態(tài)的加載DLL和卸載DLL文件，隱式鏈接是做不到的。
顯式鏈接LoadLibrary，GetProcAddress時(shí)能獲知是否加載失敗，我們可以對(duì)其進(jìn)行檢查錯(cuò)誤處理。而顯式鏈接可能是一個(gè)很惡劣的提示或是程序崩潰的結(jié)果。
對(duì)于有些Ex類(lèi)型的加強(qiáng)函數(shù)，顯式鏈接可以允許我們找到替代方案。也包括選擇D3d9.dll和OpenGL.dll時(shí)也可采用同樣處理。
例如：
if( GetProcAddress( hDll, "FKDllFunEx") == NULL )
{
pFun = GetProcAddress( hDll, "FKDllFun"); // 然后使用pFun進(jìn)行處理
}
8：導(dǎo)出類(lèi)和導(dǎo)出函數(shù)
類(lèi)和函數(shù)的導(dǎo)出方式上面給出了說(shuō)明，原本極其類(lèi)似的。
我們說(shuō)下使用導(dǎo)出類(lèi)。
若我們隱式的使用了一個(gè)導(dǎo)出類(lèi)，則我們?cè)趹?yīng)用程序里繼承它的時(shí)候，就如同該類(lèi)就在應(yīng)用程序代碼里一樣，無(wú)需任何處理。
例如：
class FK_DLL CMyDllClass{} ; // Dll文件內(nèi)的代碼
-----------------------
class CAppClass : public CMyDllClass // 應(yīng)用程序內(nèi)代碼，無(wú)需做任何處理。
{
....
}
也可以直接使用DLL導(dǎo)出類(lèi)
void main
{
CMyDllClass* pClass = new CMyDllClass ();
}
但是，若應(yīng)用程序聲明或者分類(lèi)一個(gè)DLL中導(dǎo)出類(lèi)的對(duì)象時(shí)會(huì)存在一個(gè)很討厭的問(wèn)題：這個(gè)操作會(huì)使內(nèi)存跟蹤系統(tǒng)失效，使其錯(cuò)誤的報(bào)告內(nèi)存分配和釋放情況。
為解決這個(gè)問(wèn)題，我們可以給出兩個(gè)接口函數(shù)對(duì)DLL導(dǎo)出類(lèi)進(jìn)行創(chuàng)建銷(xiāo)毀支持，就可以使內(nèi)存跟蹤系統(tǒng)正常了。例如
class FK_DLL CMyDllClass{} ;
額外增加倆函數(shù)
FK_DLL CMyDllClass* CreateMyDllClass(){ return new CMyDllClass(); }
FK_DLL void DestoryMyDllClass( CMyDllClass* p_pClass ){ delete p_pClass;
}
-----------------------------------------------
上面的方法可以正確進(jìn)行內(nèi)存跟蹤了，但是，因?yàn)镈LL導(dǎo)出類(lèi)CMyDllClass依舊是導(dǎo)出的狀態(tài)，用戶(hù)同樣可以跳過(guò)我們提供的接口直接使用。那么怎么辦呢。方法是不再對(duì)類(lèi)進(jìn)行DLL導(dǎo)出，而對(duì)類(lèi)內(nèi)的函數(shù)全部進(jìn)行DLL導(dǎo)出即可，
-----------------------------------------------
但是若僅僅提供上面兩個(gè)接口函數(shù)以及類(lèi)內(nèi)全部函數(shù)，的確功能可以實(shí)現(xiàn)，卻無(wú)法進(jìn)行類(lèi)繼承了。若這個(gè)類(lèi)繼承很重要，必須開(kāi)放，那么就需要使用新的內(nèi)存跟蹤程序替換應(yīng)用程序內(nèi)的原有內(nèi)存跟蹤程序。或者使用下面的一個(gè)方法。（見(jiàn)模塊9：復(fù)雜問(wèn)題）
-----------------------------------------------
同樣，我們也可以發(fā)現(xiàn)，在不導(dǎo)出DLL類(lèi)本身，而只導(dǎo)出DLL類(lèi)內(nèi)函數(shù)也有一些好處，一些我們不希望外界知道的函數(shù)可以不設(shè)置導(dǎo)出標(biāo)記，這進(jìn)一步保護(hù)了DLL內(nèi)函數(shù)的安全性。
9：復(fù)雜問(wèn)題。
若我們使用LoadLibrary顯式加載一個(gè)DLL，并嘗試在應(yīng)用程序中調(diào)用一個(gè)類(lèi)內(nèi)成員函數(shù)的話，無(wú)論該函數(shù)是否在頭文件中有聲明，VS會(huì)給出一個(gè)"unresolved
external symbol（未解析的外部符號(hào)）"的錯(cuò)誤。我們此時(shí)可以將項(xiàng)目屬性中的內(nèi)聯(lián)函數(shù)擴(kuò)展選項(xiàng)修改為"Only __inline"或"Any
Suitable"即可。但，我們可能在調(diào)試連編的時(shí)候期望關(guān)閉內(nèi)聯(lián)函數(shù)擴(kuò)展，那么另一種解決方案是，將希望導(dǎo)出的函數(shù)聲明為虛函數(shù)，例如
class CMyDllClass
{
FK_DLL virtual void MyTestFun( int a ){ dosth(); }
// 用上面代碼替換 FK_DLL void MyTestFun( int a ){ dosth(); }
}
這樣做還有一個(gè)額外的好處。將導(dǎo)出的類(lèi)成員函數(shù)設(shè)置為虛函數(shù)之后，該虛函數(shù)所在的類(lèi)在應(yīng)用程序中也如同被聲明一樣，可以接受繼承。
例如若是上面的做法，應(yīng)用程序就可以進(jìn)行順利繼承，而不必要求CMyDllClass 被標(biāo)示為導(dǎo)出。（原理不知，希望精通底層的高手協(xié)助解釋。）
class CAppClass : public CMyDllClass // 應(yīng)用程序內(nèi)代碼，無(wú)需做任何處理。
{
....
}