Windows DLL基本原理

Windows系統(tǒng)平臺(tái)上，你可以將獨(dú)立的程序模塊創(chuàng)建為較小的DLL(Dynamic Linkable Library)文件，并可對(duì)它們單獨(dú)編譯和測(cè)試。在運(yùn)行時(shí)，只有當(dāng)EXE程序確實(shí)要調(diào)用這些DLL模塊的情況下，系統(tǒng)才會(huì)將它們裝載到內(nèi)存空間中。這種方式不僅減少了EXE文件的大小和對(duì)內(nèi)存空間的需求，而且使這些DLL模塊可以同時(shí)被多個(gè)應(yīng)用程序使用。Microsoft Windows自己就將一些主要的系統(tǒng)功能以DLL模塊的形式實(shí)現(xiàn)。例如IE中的一些基本功能就是由DLL文件實(shí)現(xiàn)的，它可以被其它應(yīng)用程序調(diào)用和集成。一般來(lái)說(shuō)，DLL是一種磁盤(pán)文件（通常帶有DLL擴(kuò)展名，是標(biāo)準(zhǔn)win32可執(zhí)行文件－“PE”格式），它由全局?jǐn)?shù)據(jù)、服務(wù)函數(shù)和資源組成，在運(yùn)行時(shí)被系統(tǒng)加載到進(jìn)程的虛擬空間中，成為調(diào)用進(jìn)程的一部分，進(jìn)程中所有線(xiàn)程都可以調(diào)用其中的函數(shù)。如果與其它DLL之間沒(méi)有沖突，該文件通常映射到進(jìn)程虛擬空間的同一地址上。DLL模塊中包含各種導(dǎo)出函數(shù)，用于向外界提供服務(wù)。Windows在加載DLL模塊時(shí)將進(jìn)程函數(shù)調(diào)用與DLL文件的導(dǎo)出函數(shù)相匹配。

在Win32環(huán)境中，每個(gè)進(jìn)程都復(fù)制了自己的讀/寫(xiě)全局變量。如果想要與其它進(jìn)程共享內(nèi)存，必須使用內(nèi)存映射文件或者聲明一個(gè)共享數(shù)據(jù)段。DLL模塊需要的堆棧內(nèi)存都是從運(yùn)行進(jìn)程的堆棧中分配出來(lái)的。

DLL文件中包含一個(gè)導(dǎo)出函數(shù)表（存在于PE的.edata節(jié)中）。這些導(dǎo)出函數(shù)由它們的符號(hào)名和稱(chēng)為標(biāo)識(shí)號(hào)的整數(shù)與外界聯(lián)系起來(lái)。函數(shù)表中還包含了DLL中函數(shù)的地址。當(dāng)應(yīng)用程序加載DLL模塊時(shí)時(shí)，它并不知道調(diào)用函數(shù)的實(shí)際地址，但它知道函數(shù)的符號(hào)名和標(biāo)識(shí)號(hào)。動(dòng)態(tài)鏈接過(guò)程在加載的DLL模塊時(shí)動(dòng)態(tài)建立一個(gè)函數(shù)調(diào)用與函數(shù)地址的對(duì)應(yīng)表。如果重新編譯和重建DLL文件，并不需要修改應(yīng)用程序，除非你改變了導(dǎo)出函數(shù)的符號(hào)名和參數(shù)序列。

簡(jiǎn)單的DLL文件只為應(yīng)用程序提供導(dǎo)出函數(shù)，比較復(fù)雜的DLL文件除了提供導(dǎo)出函數(shù)以外，還調(diào)用其它DLL文件中的函數(shù)。

每個(gè)DLL都有一個(gè)入口函數(shù)（DLLMain），系統(tǒng)在特定環(huán)境下會(huì)調(diào)用DLLMain。在下面的事件發(fā)生時(shí)會(huì)調(diào)用dll入口函數(shù)：1.進(jìn)程裝載DLL。2.進(jìn)程卸載DLL。3.DLL在被裝載之后創(chuàng)建了新線(xiàn)程。4. DLL在被裝載之后一個(gè)線(xiàn)程被終止了。

應(yīng)用程序?qū)牒瘮?shù)與DLL文件中的導(dǎo)出函數(shù)進(jìn)行鏈接有兩種方式：隱式鏈接和顯式鏈接。

隱式鏈接（load-time dynamic linking）是指在應(yīng)用程序中不需指明DLL文件的實(shí)際存儲(chǔ)路徑，程序員不需關(guān)心DLL文件的實(shí)際裝載（由編譯器自動(dòng)完成地址分配）。采用隱式鏈接方式，程序員在建立一個(gè)DLL文件時(shí)，鏈接程序會(huì)自動(dòng)生成一個(gè)與之對(duì)應(yīng)的LIB導(dǎo)入文件。該文件包含了每一個(gè)DLL導(dǎo)出函數(shù)的符號(hào)名和可選的標(biāo)識(shí)號(hào)，但是并不含有實(shí)際的代碼。LIB文件作為DLL的替代文件被編譯到應(yīng)用程序項(xiàng)目中。當(dāng)程序員通過(guò)靜態(tài)鏈接方式編譯生成應(yīng)用程序時(shí)，應(yīng)用程序中的調(diào)用函數(shù)與LIB文件中導(dǎo)出符號(hào)相匹配，這些符號(hào)或標(biāo)識(shí)號(hào)進(jìn)入到生成的EXE文件中。LIB文件中也包含了對(duì)應(yīng)的DLL文件名（但不是完全的路徑名），鏈接程序?qū)⑵浯鎯?chǔ)在EXE文件內(nèi)部。當(dāng)應(yīng)用程序運(yùn)行過(guò)程中需要加載DLL文件時(shí)，Windows根據(jù)這些信息發(fā)現(xiàn)并加載DLL，然后通過(guò)符號(hào)名或標(biāo)識(shí)號(hào)實(shí)現(xiàn)對(duì)DLL函數(shù)的動(dòng)態(tài)鏈接。我們使用的大部分系統(tǒng)Dll就是通過(guò)這樣的方式鏈接的。若找不到需要的Dll則會(huì)給出一個(gè)Dll缺少的錯(cuò)誤消息。

顯式鏈接（run-time dynamic linking）與此相反。用戶(hù)程序在編譯的時(shí)候并沒(méi)有指明需要哪些Dll，而是在運(yùn)行起來(lái)之后調(diào)用Win32 的LoadLibary()函數(shù)，去裝載Dll。若沒(méi)有找到Dll則這個(gè)函數(shù)就會(huì)返回一個(gè)錯(cuò)誤。在用LoadLibary()函數(shù)裝載Dll之后，應(yīng)用程序還需要用GetProcAdress()函數(shù)去獲得Dll輸出函數(shù)的地址。顯式鏈接方式對(duì)于集成化的開(kāi)發(fā)語(yǔ)言比較適合。有了顯式鏈接，程序員就不必再使用導(dǎo)入文件，而是直接調(diào)用Win32 的LoadLibary()函數(shù)，并指定DLL的路徑作為參數(shù)。還要說(shuō)明一點(diǎn)的就是Known Dlls就是保證在通過(guò)LoadLibary()去裝載系統(tǒng)Dll的時(shí)候，只從特定的系統(tǒng)目錄去裝載，防止裝載錯(cuò)。裝載的時(shí)候會(huì)去看注冊(cè)表下是否有一樣的注冊(cè)表鍵名。如果是裝載windowssystem32目錄下的對(duì)應(yīng)的Dll。

Dll的搜索順序，在Windows上有個(gè)注冊(cè)表鍵值決定了Dll的搜索順序：HKLMSystemCurrentControlSetSessionManagerSafeDllSearchMode。在vista,server2003,xp sp2中這個(gè)值為1，在xp,2000 sp4中為0。1值時(shí)的搜素順序?yàn)椋?.可執(zhí)行文件所在目錄，2.系統(tǒng)目錄windowssystem32，3. 16位系統(tǒng)目錄，4.windows目錄，5.當(dāng)前進(jìn)程目錄。6.環(huán)境變量PATH中的目錄。0值時(shí)的搜素順序?yàn)椋?.可執(zhí)行文件所在目錄，2. 當(dāng)前進(jìn)程目錄。3.系統(tǒng)目錄windowssystem32，4. 16位系統(tǒng)目錄，5.windows目錄，6.環(huán)境變量PATH中的目錄。

DLL的加載與連接

Windows DLL裝入(除ntdll.dll外)和連接是通過(guò)ntdll.dll中一個(gè)函數(shù)LdrInitializeThunk實(shí)現(xiàn)的。先對(duì)LdrInitializeThunk()這個(gè)函數(shù)名作些解釋“Ldr顯然是“Loader”的縮寫(xiě)。而“Thunk”意為“翻譯”、“轉(zhuǎn)換”、或者某種起著“橋梁”作用的東西。這個(gè)詞在一般的字典中是查不到的，但卻是個(gè)常見(jiàn)于微軟的資料、文檔中術(shù)語(yǔ)。這個(gè)術(shù)語(yǔ)起源于編譯技術(shù)，表示一小片旨在獲取某個(gè)地址的代碼，最初用于函數(shù)調(diào)用時(shí)“形參”和“實(shí)參”結(jié)合。后來(lái)這個(gè)術(shù)語(yǔ)有了不少新的特殊含義和使用，但是DLL的動(dòng)態(tài)連接與函數(shù)調(diào)用時(shí)“形實(shí)結(jié)合”確實(shí)有著本質(zhì)的相似。

由于Windows沒(méi)有公開(kāi)這個(gè)函數(shù)的代碼，所以學(xué)習(xí)起來(lái)比較困難，只能通過(guò)查閱一些資料來(lái)大概猜測(cè)這個(gè)函數(shù)的實(shí)現(xiàn)。這個(gè)過(guò)程中也參看了很多ReactOS（ReactOS是一個(gè)免費(fèi)而且完全兼容 Microsoft Windows XP 的操作系統(tǒng)。ReactOS 旨在通過(guò)使用類(lèi)似構(gòu)架和提供完整公共接口實(shí)現(xiàn)與 NT 操作系統(tǒng)二進(jìn)制下的應(yīng)用程序和驅(qū)動(dòng)設(shè)備的完全兼容。）的LdrInitializeThunk()函數(shù)實(shí)現(xiàn)源代碼。

在進(jìn)入這個(gè)函數(shù)之前，目標(biāo) EXE映像已經(jīng)被映射到當(dāng)前進(jìn)程的用戶(hù)空間，系統(tǒng)DLL ntdll.dll的映像也已經(jīng)被映射，但是并沒(méi)有在EXE映像與ntdll.dll映像之間建立連接 (實(shí)際上 EXE映像未必就直接調(diào)用ntdll.dll中的函數(shù))。LdrInitializeThunk()是ntdll.dll中不經(jīng)連接就可進(jìn)入的函數(shù)，實(shí)質(zhì)上就是ntdll.dll的入口。除ntdll.dll以外，別的 DLL都還沒(méi)有被裝入(映射)。此外，當(dāng)前進(jìn)程(除內(nèi)核中的“進(jìn)程控制塊”EPROCESS等數(shù)據(jù)結(jié)構(gòu)外)在用戶(hù)空間已經(jīng)有了一個(gè)“進(jìn)程環(huán)境塊”P(pán)EB，以及該進(jìn)程的第一個(gè)“線(xiàn)程環(huán)境塊”TEB。這就是進(jìn)入 LdrInitializeThunk()前的“當(dāng)前形勢(shì)”。

PEB中有一個(gè)字段Ldr是個(gè)PEB_LDR_DATA結(jié)構(gòu)指針，所指向的數(shù)據(jù)結(jié)構(gòu)用來(lái)為本進(jìn)程維持三個(gè)“模塊”隊(duì)列、即InLoadOrderModuleList、InMemoryOrderModuleList、和InInitializationOrderModuleList。這里所謂“模塊”就是PE格式的可執(zhí)行映像，包括EXE映像和DLL映像。前兩個(gè)隊(duì)列都是模塊隊(duì)列，第三個(gè)是初始化隊(duì)列。兩個(gè)模塊隊(duì)列的不同之處在于排列的次序，一個(gè)是按裝入的先后，一個(gè)是按裝入的位置。每當(dāng)為本進(jìn)程裝入一個(gè)模塊、即.exe映像或DLL映像時(shí)，就要為其分配，創(chuàng)建一個(gè)LDR_DATA_TABLE_ENTRY數(shù)據(jù)結(jié)構(gòu)，并將其掛入InLoadOrderModuleList。然后，完成對(duì)這個(gè)模塊的動(dòng)態(tài)連接以后，就把它掛入InInitializationOrderModuleList隊(duì)列，以便依次調(diào)用它們的初始化函數(shù)。相應(yīng)地，LDR_DATA_TABLE_ENTRY數(shù)據(jù)結(jié)構(gòu)中有三個(gè)隊(duì)列頭，因而可以同時(shí)掛在三個(gè)隊(duì)列中。在我做的小實(shí)驗(yàn)當(dāng)中就是通過(guò)查找這三個(gè)隊(duì)列，來(lái)將當(dāng)前進(jìn)程的Dll加載信息顯示出來(lái)的。具體的實(shí)例請(qǐng)見(jiàn)我的實(shí)驗(yàn)說(shuō)明文檔。

在LdrInitializeThunk()中，最開(kāi)始為做的事情就是將加載的模塊信息存放在PEB中的ldr字段，如上面一段文字中所述。之后，LdrInitializeThunk()函數(shù)又調(diào)用了一個(gè)叫LdrPEStartup()的函數(shù)。LdrPEStartup()函數(shù)首先判斷了“期望地址”是否可用，PE映像的NtHeader(peb中有個(gè)ImageBaseAddress的地址，代表exe映像在用戶(hù)空間的位置，在這個(gè)地址指向的數(shù)據(jù)結(jié)構(gòu)中就有NtHeader的結(jié)構(gòu))中有個(gè)指針，指向一個(gè)OptionalHeader。在OptionalHeader中有個(gè)字段ImageBase，是具體映像建議、或者說(shuō)希望被裝入的地址，我們稱(chēng)之為“愿望地址”。在裝入一個(gè)映像時(shí)，只要相應(yīng)的區(qū)間(取決于它的期望地址和大小)空閑，就總正常裝入。但是如果與已經(jīng)被占用的區(qū)間相沖突，就只好利用LdrPerformRelocations()換個(gè)地方。

那么映像的愿望地址有著什么物理的或者邏輯的意義呢？我們知道，軟件在編譯以后有個(gè)連接的過(guò)程，即為函數(shù)的調(diào)用者落實(shí)被調(diào)用函數(shù)的入口地址、為全局變量(按絕對(duì)地址)的使用者落實(shí)變量地址的過(guò)程。連接有靜態(tài)和動(dòng)態(tài)兩種，靜態(tài)連接是在“制造”軟件時(shí)進(jìn)行的，而動(dòng)態(tài)連接則是在使用軟件時(shí)進(jìn)行的。盡管EXE模塊和DLL模塊之間的連接是動(dòng)態(tài)連接，但是EXE或DLL模塊內(nèi)部的連接卻是靜態(tài)連接。既是靜態(tài)連接，就必須為模塊的映像提供一個(gè)假定的起點(diǎn)地址。如果以此假定地址為基礎(chǔ)進(jìn)行連接以后就不可變更，使用時(shí)必須裝入到這個(gè)地址上，那么這個(gè)地址就是固定的“指定地址”了。早期的靜態(tài)連接往往都是使用指定地址的。但是，如果允許按假定地址連接的映像在實(shí)際使用時(shí)進(jìn)行“重定位”，那么這假定地址就是可浮動(dòng)的“愿望地址”了。可“重定位”的靜態(tài)連接當(dāng)然比固定的靜態(tài)連接靈活。事實(shí)上，要是沒(méi)有可“重定位”的靜態(tài)連接技術(shù)，DLL的使用就無(wú)法實(shí)現(xiàn)，因?yàn)楦揪筒豢赡苁孪葹樗锌赡艿腄LL劃定它們的裝入位置和大小。至于可“重定位”靜態(tài)連接的實(shí)現(xiàn)，則一般都是采用間接尋址，通過(guò)指針來(lái)實(shí)現(xiàn)。

所謂重定位，就是計(jì)算出實(shí)際裝入地址與建議裝入地址間的位移a，然后調(diào)整每個(gè)重定位塊中的每一個(gè)重定位項(xiàng)、即指針，具體就是在指針上加a。而映像中使用的所有絕對(duì)地址(包括函數(shù)入口、全局量數(shù)據(jù)的位置)實(shí)際上用的都是間接尋址，每個(gè)這樣的地址都有個(gè)指針存在于某個(gè)重定位塊中。

完成了可能需要的EXE映像重定位以后，下一個(gè)主要的操作就是LdrFixupImports()了。實(shí)際上這才是關(guān)鍵所在，它所處理的就是當(dāng)前模塊所需DLL模塊的裝入和連接。各DLL的程序入口記錄在它們的LDR_DATA_TABLE_ENTRY數(shù)據(jù)結(jié)構(gòu)中借助InInitializationOrderModuleList隊(duì)列就可依次調(diào)用所有DLL的初始化函數(shù)。

NtHeader的OptionalHeader中有個(gè)數(shù)組DataDirectory[]，其中之一是重定位目錄。除此之外，數(shù)組中還有“(普通)引入(import)”、“綁定引入(bound import)”以及其它多種目錄，但是我們?cè)谶@里只關(guān)心“引入”和“綁定引入”。這兩個(gè)目錄都是用于庫(kù)函數(shù)的引入，但是作用不同，目錄項(xiàng)的數(shù)據(jù)結(jié)構(gòu)也不同。每個(gè)引入目錄項(xiàng)都代表著一個(gè)被引入模塊，其模塊名、即文件名在dwRVAModuleName（ReactOS中的名字，下同）所指的地方。需要從同一個(gè)被引入模塊引入的函數(shù)通常有很多個(gè)，dwRVAFunctionNameList指向一個(gè)字符串?dāng)?shù)組，數(shù)組中的每一個(gè)字符串都是一個(gè)函數(shù)名；與此相對(duì)應(yīng)，dwRVAFunctionAddressList則指向一個(gè)指針數(shù)組。這兩個(gè)數(shù)組是平行的，同一個(gè)函數(shù)在兩個(gè)數(shù)組中具有相同的下標(biāo)。從一個(gè)被引入模塊中引入一個(gè)函數(shù)的過(guò)程大體上就是：根據(jù)函數(shù)名在被引入模塊的引出目錄中搜索，找到目標(biāo)函數(shù)以后就把它實(shí)際裝入后的入口地址填寫(xiě)到指針數(shù)組中的相應(yīng)位置上。但是，這個(gè)過(guò)程可能是個(gè)開(kāi)銷(xiāo)相當(dāng)大、速度比較慢的過(guò)程。為此，又發(fā)展起一種稱(chēng)為“綁定”的優(yōu)化。

所謂綁定，就是在軟件的編譯，連接過(guò)程中先對(duì)使用時(shí)的動(dòng)態(tài)連接來(lái)一次預(yù)演，預(yù)演時(shí)假定所有的DLL都被裝入到它們的愿望地址上，然后把預(yù)演中得到的被引入函數(shù)的地址直接記錄在引入者模塊中相應(yīng)引入目錄下的指針數(shù)組中。這樣，使用軟件時(shí)的動(dòng)態(tài)連接就變得很簡(jiǎn)單快捷，因?yàn)閷?shí)際上已經(jīng)事先連接好了。其實(shí)“綁定引入”和靜態(tài)連接并無(wú)實(shí)質(zhì)的不同。但是，各模塊的版本配套就成為一個(gè)問(wèn)題，因?yàn)槿f(wàn)一使用的某個(gè)DLL不是當(dāng)初綁定時(shí)的版本，而且其引出目錄又發(fā)生了變化，就有可能引起混亂。為此，PE格式增加了一種“綁定引入”目錄，相關(guān)的機(jī)制會(huì)進(jìn)行判斷。但是，“綁定引入”畢竟不是很可靠的，萬(wàn)一發(fā)現(xiàn)版本不符就不能使用原先的綁定了。所以“綁定引入”不能單獨(dú)存在，而必須有普通引入作為后備。如果不符就不能按“綁定引入”目錄處理引入，而只好退而求其次，改成按普通“引入”目錄處理引入。另一方面，所謂“綁定”是指當(dāng)被引入模塊裝入在預(yù)定位置上時(shí)的地址綁定，如果被引入模塊的裝入位置變了，就得對(duì)原先所綁定的地址作相應(yīng)的調(diào)整、即“重定位”。

LdrFixupImports()函數(shù)首先從映像頭部獲取指向“引入”目錄和“綁定引入”目錄的指針。若存在“綁定引入”目錄，則先通過(guò)LdrpGetOrLoadModule()找到或裝入(映射)被引入模塊的映像。首先當(dāng)然是在模塊隊(duì)列中尋找，找不到就從被引入模塊的磁盤(pán)文件裝入。之后檢查綁定版本是否一致，如果不一致就退而求其次，通過(guò)LdrpProcessImportDirectory()處理引入。當(dāng)然，那樣一來(lái)效率就要降低了。如果一致，則返回（因?yàn)樵凇邦A(yù)演”中已經(jīng)連接好，效率當(dāng)然高了）。而LdrpProcessImportDirectory()才是真正意義上的動(dòng)態(tài)連接?。。ㄕf(shuō)了這么多原來(lái)才開(kāi)始……）。

LdrpProcessImportDirectory()首先根據(jù)目錄項(xiàng)中的兩個(gè)位移量取得分別指向函數(shù)名字符串?dāng)?shù)組和函數(shù)指針數(shù)組的指針。這兩個(gè)數(shù)組是平行的（前面有介紹），然后對(duì)字符串?dāng)?shù)組中的元素計(jì)數(shù)，得到該數(shù)組的大小IATSize。顯然，函數(shù)指針數(shù)組的大小也是IATSize。這里IAT是“引入地址表(Imported Address Table)”的縮寫(xiě)，其實(shí)就是函數(shù)指針數(shù)組。這個(gè)數(shù)組在映像內(nèi)部，其所在的頁(yè)面在裝入映像時(shí)已被加上寫(xiě)保護(hù)，而下面要做的事正是要改變這些指針的值，所以先要通過(guò)NtProtectVirtualMemory()把這些頁(yè)面的訪(fǎng)問(wèn)模式改成可讀可寫(xiě)。做完這些準(zhǔn)備之后，下面就是連接的過(guò)程了，那就是根據(jù)需要把被引入模塊所引出的函數(shù)入口(地址)填寫(xiě)到引入者模塊的IAT中。與當(dāng)前模塊中的兩個(gè)數(shù)組相對(duì)應(yīng)，在被引入模塊的“引出”目錄中也有兩個(gè)數(shù)組，說(shuō)明本模塊引出函數(shù)的名稱(chēng)和入口地址(在映像中的位移)。當(dāng)然，這兩個(gè)數(shù)組也是平行的。要獲取被引入模塊中的函數(shù)入口有兩種方法，即按序號(hào)(Ordinal)引入和按函數(shù)名引入。從而分別調(diào)用LdrGetExportByOrdinal()和LdrGetExportByName()。這兩個(gè)函數(shù)都返回目標(biāo)函數(shù)在本進(jìn)程用戶(hù)空間中的入口地址，把它填寫(xiě)入當(dāng)前模塊引入目錄函數(shù)指針數(shù)組中的相應(yīng)元素，就完成了一個(gè)函數(shù)的連接。當(dāng)然，同樣的操作要循環(huán)實(shí)施于當(dāng)前模塊需要從給定模塊引入的所有函數(shù)，并且(在上一層)循環(huán)實(shí)施于所有的被引入模塊。完成了對(duì)一個(gè)被引入模塊的連接之后，又調(diào)用NtProtectVirtualMemory()恢復(fù)當(dāng)前模塊中給定目錄項(xiàng)內(nèi)函數(shù)指針數(shù)組所在頁(yè)面的保護(hù)。

到此，我們大概的清楚Windows Dll的加載與連接過(guò)程。

一，首先編寫(xiě)DLL (建win32空DLL工程）

頭文件.h

?

extern "C" _declspec(dllexport) int Max(int a, int b);???????? //extern "C"解決函數(shù)名由于不同編譯器造成的名字匹配問(wèn)題，通常c++編譯器編譯時(shí)會(huì)對(duì)函數(shù)進(jìn)行改名，而c編譯器不會(huì)
extern "C" _declspec(dllexport) int Min(int a, int b);???????? //_declspec(dllexport)說(shuō)明該函數(shù)為導(dǎo)出函數(shù)

?

實(shí)現(xiàn)文件.cpp

#include"TestDLL.h"
int Max(int a, int b)
{
?return (a > b?a:b);
}
int Min(int a, int b)
{
?return (a > b?b:a);
}

?

二，編程測(cè)試DLL的工程（建win32 空工程）

1，靜態(tài)加載dll

a。將dll工程下的dll和lib文件拷到測(cè)試工程下

b。同時(shí)編寫(xiě)頭文件.h

extern "C" _declspec(dllimport) int Max(int a, int b);?????????? //_declspec(dllimport)說(shuō)明函數(shù)為導(dǎo)入函數(shù)
extern "C" _declspec(dllimport) int Min(int a, int b);

c。編寫(xiě)實(shí)現(xiàn)文件.cpp

#include "test.h"
#include

?

2.動(dòng)態(tài)加載dll（僅用包含dll文件，同時(shí)不需要.h文件和lib文件）

a。將dll工程下的dll文件拷貝到測(cè)試工程下

b。編寫(xiě)實(shí)現(xiàn)文件.cpp

#include

int main()
{
?HINSTANCE his =?LoadLibraryA("TestDLL001.dll");??????????????????? //用于加載dll
?typedef int(*pmin)(int a, int b);??????????
?pmin mmi=(pmin)GetProcAddress(his, "Min");????????????????? //GetProcAddress()用于獲得函數(shù)地址
?int aa=mmi(3,4);
?cout<<aa<<endl;
?FreeLibrary(his);?????????????????????????????????????????????????? //釋放dll
?system("pause");
?return 0;
}