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 。
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文件，源代碼如下：
/* 文件名：lib.h */
#ifndef LIB_H
#define LIB_H
extern "C" int __declspec(dllexport)add(int x, int y);
#endif
/* 文件名：lib.cpp */
#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。
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);
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調用約定在輸出函數名前面加下劃線，後面加“@”符號和參數的字節數，形如_functionname@number；而__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中變量的例子（單擊此處下載本工程附件）。
/* 文件名：lib.h */
#ifndef LIB_H
#define LIB_H
extern int dllGlobalVar;
#endif
/* 文件名：lib.cpp */
#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
作者：宋寶華 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 /*=NULL*/)
: 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
作者：宋寶華 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@@UAE@XZ)
LoadExtDllDlg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall CExtDialog::CExtDialog(class CWnd *)" (__imp_??0CExtDialog@@QAE@PAVCWnd@@@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典型實例
作者：宋寶華 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中。
隨後，這位讀者提供了這樣的一個函數：
/* 函數名稱：FFT()
* 參數:
* complex<double> * TD - 指向時域數組的指針
* complex<double> * FD - 指向頻域數組的指針
* r －2的冪數，即迭代次數
* 返回值: 無。
* 說明:該函數用來實現快速傅立葉變換
*/
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的源代碼爲：
/* 文件名：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木馬
作者：宋寶華 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)編程（七）
――讀者反饋與答覆
作者：宋寶華 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
{
/* 創建socket */
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的影子！又一個“萬變不離其宗”！