VC++动态链接库(DLL)编程（四）
――MFC扩展 DLL
作者：宋宝华 e-mail:21cnbao@21cn.com
前文我们对非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:21cnbao@21cn.com
动态链接库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:21cnbao@21cn.com
从前文可知，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木马最简单情况的介绍，读者若有兴趣深入研究，可以参考其它资料。
此后将是本系列文章的最后一次连载，即读者来信与反馈。