Win32应用程序中进程间通信方法分析与比较

1 进程与进程通信

　　进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(如文件、管道等)组成。多进程/多线程是Windows操作系统的一个基本特征。Microsoft Win32应用编程接口(Application Programming Interface, API)提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcess Communication, IPC)，进程通信就是指不同进程间进行数据共享和数据交换。
　　正因为使用Win32 API进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32中进程通信的几种方法加以分析和比较。

2 进程通信方法

2.1 文件映射
　　文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O操作，只需简单的指针操作就可读取和修改文件的内容。
　　Win32 API允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。
　　应用程序有三种方法来使多个进程共享一个文件映射对象。
　　(1)继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。
　　(2)命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(可与文件名不同)。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC机制(有名管道、邮件槽等)把名字传给第二个进程。
　　(3)句柄复制：第一个进程建立文件映射对象，然后通过其它IPC机制(有名管道、邮件槽等)把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。
　　文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。
2.2 共享内存
　　Win32 API中共享内存(Shared Memory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF来代替文件句柄(HANDLE)，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。
2.3 匿名管道
　　管道(Pipe)是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。
　　匿名管道(Anonymous Pipe)是在父进程和子进程之间，或同一父进程的两个子进程之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。
　　匿名管道是单机上实现子进程标准I/O重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。
2.4 命名管道
　　命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。
　　命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。
2.5 邮件槽
　　邮件槽(Mailslots)提供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户，因此可建立多个邮件槽实现进程间的双向通信。
　　通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。
　　邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(如TCP/IP协议中的UDP包)完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。
2.6 剪贴板
　　剪贴板(Clipped Board)实质是Win32 API中一组用来传输数据的函数和消息，为Windows应用程序之间进行数据共享提供了一个中介，Windows已建立的剪切(复制)－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。
　　剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(预定义)剪贴板格式，该值是Win32 API定义的常量；对非标准格式可以使用Register Clipboard Format函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows的程序中使用，不能在网络上使用。
2.7 动态数据交换
　　动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。
　　DDE和剪贴板一样既支持标准数据格式(如文本、位图等)，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste命令。尽管DDE也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE有三种数据交换方式：
　　(1) 冷链：数据交换是一次性数据传输，与剪贴板相同。
　　(2) 温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。
　　(3) 热链：当数据交换时服务器自动给客户发送数据。
　　DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC，它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。
2.8 对象连接与嵌入
　　应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档)，OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE，用户要显式地启动电子表格编辑器。
　　同DDE技术相同，大多数基于Windows的应用程序都支持OLE技术。
2.9 动态连接库
　　Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。
　　虽然可以通过DLL进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存的方法更好一些。
2.10 远程过程调用
　　Win32 API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数，这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。
　　由于Win32 API提供的RPC服从OSF-DCE(Open Software Foundation Distributed Computing Environment)标准。所以通过Win32 API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。
2.11 NetBios函数
　　Win32 API提供NetBios函数用于处理低级网络控制，这主要是为IBM NetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序，其它应用程序最好不要使用NetBios函数来进行进程间通信。
2.12 Sockets
　　Windows Sockets规范是以U.C.Berkeley大学BSD UNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口。除了Berkeley Socket原有的库函数以外，还扩展了一组针对Windows的函数，使程序员可以充分利用Windows的消息机制进行编程。
　　现在通过Sockets实现进程通信的网络应用越来越多，这主要的原因是Sockets的跨平台性要比其它IPC机制好得多，另外WinSock 2.0不仅支持TCP/IP协议，而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA消息将更合适些。
2.13 WM_COPYDATA消息
　　WM_COPYDATA是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPY DATA消息，这样收发双方就实现了数据共享。
　　WM_COPYDATA是一种非常简单的方法，它在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高，并且它只能用于Windows平台的单机环境下。

3 结束语

　　Win32 API为应用程序实现进程间通信提供了如此多种选择方案，那么开发者如何进行选择呢？通常在决定使用哪种IPC方法之前应考虑下一些问题，如应用程序是在网络环境下还是在单机环境下工作等。

• 连接池
• 引用记数
• 多线程
• Timer类运行基理
• C#.Net  

适宜人群

• 数据库应用程序程序员
• 系统分析员
• 模块设计师
• 有一定功底的程序员

目录

• 引言
  1. 数据库连接池（Connection Pool）的工作原理
• 连接池关键问题分析
  1. 并发问题
  2. 事务处理
  3. 连接池的分配与释放
  4. 连接池的配置与维护
• 关键议题
  1. 引用记数
  2. 如何实现事务处理
  3.  管理连接池
• 结合代码说明
  1. 构造方法
  2. 启动服务StartService
  3. 停止服务StopService
  4. 申请 GetConnectionFormPool
  5. 释放DisposeConnection
  6. 如何更新属性
  7. 如何确定连接是否失效
  8. 使用线程管理连接池
     1. threadCreate
     2. threadCheck

  9.  其他

引言

一般的数据库应用程序大致都遵循下面的步骤:

1. 初始化程序
2. 用户在UI上输入操作
3. 由用户操作产生数据库操作
4. 将数据库操作递交到数据库服务器
5. .... (重复2~4)
6. 关闭应用程序

　　而本文则着重讲解上面第4步骤.在着一步骤中我们经常是,打开数据库连接操作数据库,最后关闭数据库.
　　在服务器端程序设计上与数据库的操作显得十分重要,因为你要处理的数据操作十分巨大.如果频繁创建数据库连接频繁关闭数据库连接则会引起效率低下甚至引发程序崩溃.
　　也许我们可以有另一种操作数据库的形式,我们可以在程序运行时打开一个数据库连接,让这个连接永久存在直到程序'死亡',那么这样做也有不安全隐患,我们知道一个对象存在时间越长或被使用次数越多则它表现的越不稳定,着不稳定因素是由于对象内部可能存在的潜在设计问题产生,对于数据库连接对象道理也一样.我们不能保证一个Connection对象里面能一点问题不存在.所以我们也不敢长时间将它长时间占用内存.
　　既然有这么多的问题由此我们需要一个能帮我们维护数据库连接的东西-它就是连接池,网上有很多的连接池例子,但是多数都是简单的例子,或者介绍比较复杂的连接池原理,没有一个比较完整介绍和实现连接池的例子.这里就介绍你如何自己制作一个连接池.
　　对于共享资源，有一个很著名的设计模式：资源池（Resource Pool）。该模式正是为了解决资源的频繁分配﹑释放所造成的问题。为解决我们的问题，可以采用数据库连接池技术。数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”。预先在缓冲池中放入一定数量的连接，当需要建立数据库连接时，只需从“缓冲池”中取出一个，使用完毕之后再放回去。我们可以通过设定连接池最大连接数来防止系统无尽的与数据库连接。更为重要的是我们可以通过连接池的管理机制监视数据库的连接的数量﹑使用情况，为系统开发﹑测试及性能调整提供依据。连接池的基本工作原理见下图。

数据库连接池（Connection Pool）的工作原理

 连接池关键问题分析

　　1、并发问题

　　为了使连接管理服务具有最大的通用性，必须考虑多线程环境，即并发问题。这个问题相对比较好解决，因为各个语言自身提供了对并发管理的支持像java,c#等等，使用synchronized(java)lock(C#)关键字即可确保线程是同步的。使用方法可以参考，相关文献。

　　２、事务处理

　　我们知道，事务具有原子性，此时要求对数据库的操作符合“ALL-ALL-NOTHING”原则,即对于一组SQL语句要么全做，要么全不做。
　　我们知道当２个线程公用一个连接Connection对象，而且各自都有自己的事务要处理时候，对于连接池是一个很头疼的问题，因为即使Connection类提供了相应的事务支持，可是我们仍然不能确定那个数据库操作是对应那个事务的，这是由于我们有２个线程都在进行事务操作而引起的。为此我们可以使用每一个事务独占一个连接来实现，虽然这种方法有点浪费连接池资源但是可以大大降低事务管理的复杂性。

　　３、连接池的分配与释放

　　连接池的分配与释放，对系统的性能有很大的影响。合理的分配与释放，可以提高连接的复用度，从而降低建立新连接的开销，同时还可以加快用户的访问速度。
　　对于连接的管理可使用一个List。即把已经创建的连接都放入List中去统一管理。每当用户请求一个连接时，系统检查这个List中有没有可以分配的连接。如果有就把那个最合适的连接分配给他（如何能找到最合适的连接文章将在关键议题中指出）；如果没有就抛出一个异常给用户，List中连接是否可以被分配由一个线程来专门管理捎后我会介绍这个线程的具体实现。

 　　４、连接池的配置与维护

　　连接池中到底应该放置多少连接，才能使系统的性能最佳？系统可采取设置最小连接数（minConnection）和最大连接数（maxConnection）等参数来控制连接池中的连接。比方说，最小连接数是系统启动时连接池所创建的连接数。如果创建过多，则系统启动就慢，但创建后系统的响应速度会很快；如果创建过少，则系统启动的很快，响应起来却慢。这样，可以在开发时，设置较小的最小连接数，开发起来会快，而在系统实际使用时设置较大的，因为这样对访问客户来说速度会快些。最大连接数是连接池中允许连接的最大数目，具体设置多少，要看系统的访问量，可通过软件需求上得到。
　　如何确保连接池中的最小连接数呢？有动态和静态两种策略。动态即每隔一定时间就对连接池进行检测，如果发现连接数量小于最小连接数，则补充相应数量的新连接,以保证连接池的正常运转。静态是发现空闲连接不够时再去检查。

       DWORD dwStart = GetTickCount();
DWORD dwEnd   = dwStart;
do
{
dwEnd = GetTickCount()-dwStart;
}while(dwEnd <50);

       DWORD dwStart = GetTickCount();
DWORD dwEnd   = dwStart;
do
{
MSG   msg;
GetMessage(&msg,NULL,0,0);
TranslateMessage(&msg);
DispatchMessage(&msg);
dwEnd = GetTickCount()-dwStart;
}while(dwEnd <50);

       MMRESULT timeSetEvent（ UINT uDelay,
UINT uResolution,
LPTIMECALLBACK lpTimeProc,
WORD dwUser,
UINT fuEvent ）

       uDelay：以毫秒指定事件的周期。
Uresolution：以毫秒指定延时的精度，数值越小定时器事件分辨率越高。缺省值为1ms。
LpTimeProc：指向一个回调函数。
DwUser：存放用户提供的回调数据。
FuEvent：指定定时器事件类型：
TIME_ONESHOT：uDelay毫秒后只产生一次事件
TIME_PERIODIC ：每隔uDelay毫秒周期性地产生事件。      

       BOOL  QueryPerformanceFrequency(LARGE_INTEGER ＊lpFrequency);
BOOL  QueryPerformanceCounter(LARGE_INTEGER ＊lpCount);

       typedef union _LARGE_INTEGER
{
struct
{
DWORD LowPart ;// 4字节整型数
LONG  HighPart;// 4字节整型数
};
LONGLONG QuadPart ;// 8字节整型数
}LARGE_INTEGER ;

       LARGE_INTEGER litmp;
LONGLONG QPart1,QPart2;
double dfMinus, dfFreq, dfTim;
QueryPerformanceFrequency(&litmp);
dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
QueryPerformanceCounter(&litmp);
QPart1 = litmp.QuadPart;// 获得初始值
do
{
QueryPerformanceCounter(&litmp);
QPart2 = litmp.QuadPart;//获得中止值
dfMinus = (double)(QPart2-QPart1);
dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒
}while(dfTim<0.001);

       LARGE_INTEGER litmp;
LONGLONG QPart1,QPart2;
double dfMinus, dfFreq, dfTim;
QueryPerformanceFrequency(&litmp);
dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
QueryPerformanceCounter(&litmp);
QPart1 = litmp.QuadPart;// 获得初始值
Sleep(100);
QueryPerformanceCounter(&litmp);
QPart2 = litmp.QuadPart;//获得中止值
dfMinus = (double)(QPart2-QPart1);
dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒     

       LARGE_INTEGER litmp;
LONGLONG QPart1,QPart2;
double dfMinus, dfFreq, dfTim;
QueryPerformanceFrequency(&litmp);
dfFreq = (double)litmp.QuadPart;// 获得计数器的时钟频率
QueryPerformanceCounter(&litmp);
QPart1 = litmp.QuadPart;// 获得初始值
do
{
QueryPerformanceCounter(&litmp);
QPart2 = litmp.QuadPart;//获得中止值
dfMinus = (double)(QPart2-QPart1);
dfTim = dfMinus / dfFreq;// 获得对应的时间值，单位为秒
}while(dfTim<0.000001);

三、动态链接库的创建

　　在 Visual C++6.0 开发环境下，打开 FileNewProject 选项，可以选择 Win32 Dynamic-Link Library 或 MFC AppWizard[dll] 来以不同的方式来创建 Non-MFC Dll 、 Regular Dll 、 Extension Dll 等不同种类的动态链接库。

　　 1 ． Win32 Dynamic-Link Library 方式创建 Non-MFC DLL 动态链接库

　　每一个 DLL 必须有一个入口点，这就象我们用 C 编写的应用程序一样，必须有一个 WINMAIN 函数一样。在 Non-MFC DLL 中 DllMain 是一个缺省的入口函数，你不需要编写自己的 DLL 入口函数，用这个缺省的入口函数就能使动态链接库被调用时得到正确的初始化。如果应用程序的 DLL 需要分配额外的内存或资源时，或者说需要对每个进程或线程初始化和清除操作时，需要在相应的 DLL 工程的 .CPP 文件中对 DllMain() 函数按照下面的格式书写。
　

　　参数中， hMoudle 是动态库被调用时所传递来的一个指向自己的句柄 ( 实际上，它是指向 _DGROUP 段的一个选择符 ) ； ul_reason_for_call 是一个说明动态库被调原因的标志，当进程或线程装入或卸载动态链接库的时候，操作系统调用入口函数，并说明动态链接库被调用的原因，它所有的可能值为： DLL_PROCESS_ATTACH: 进程被调用、 DLL_THREAD_ATTACH: 线程被调用、 DLL_PROCESS_DETACH: 进程被停止、 DLL_THREAD_DETACH: 线程被停止； lpReserved 为保留参数。到此为止， DLL 的入口函数已经写了，剩下部分的实现也不难，你可以在 DLL 工程中加入你所想要输出的函数或变量了。

　　我们已经知道 DLL 是包含若干个函数的库文件，应用程序使用 DLL 中的函数之前，应该先导出这些函数，以便供给应用程序使用。要导出这些函数有两种方法，一是在定义函数时使用导出关键字 _declspec(dllexport) ，另外一种方法是在创建 DLL 文件时使用模块定义文件 .Def 。需要读者注意的是在使用第一种方法的时候，不能使用 DEF 文件。下面通过两个例子来说明如何使用这两种方法创建 DLL 文件。

　　 1 ）使用导出函数关键字 _declspec(dllexport) 创建 MyDll.dll ，该动态链接库中有两个函数，分别用来实现得到两个数的最大和最小数。在 MyDll.h 和 MyDLL.cpp 文件中分别输入如下原代码：
　

　　该动态链接库编译成功后，打开 MyDll 工程中的 debug 目录，可以看到 MyDll.dll 、 MyDll.lib 两个文件。 LIB 文件中包含 DLL 文件名和 DLL 文件中的函数名等，该 LIB 文件只是对应该 DLL 文件的 " 映像文件 " ，与 DLL 文件中， LIB 文件的长度要小的多，在进行隐式链接 DLL 时要用到它。读者可能已经注意到在 MyDll.h 中有关键字 "extern C" ，它可以使其他编程语言访问你编写的 DLL 中的函数。

　　 2 ）用 .def 文件创建工程 MyDll

　　为了用 .def 文件创建 DLL ，请先删除上个例子创建的工程中的 MyDll.h 文件，保留 MyDll.cpp 并在该文件头删除 ＃i nclude MyDll.h 语句，同时往该工程中加入一个文本文件，命名为 MyDll.def ，再在该文件中加入如下代码：

LIBRARY MyDll
EXPORTS
Max
Min

　　其中 LIBRARY 语句说明该 def 文件是属于相应 DLL 的， EXPORTS 语句下列出要导出的函数名称。我们可以在 .def 文件中的导出函数后加 @n ，如 Max@1 ， Min@2 ，表示要导出的函数顺序号，在进行显式连时可以用到它。该 DLL 编译成功后，打开工程中的 Debug 目录，同样也会看到 MyDll.dll 和 MyDll.lib 文件。

　　 2 ． MFC AppWizard[dll] 方式生成常规 / 扩展 DLL

　　在 MFC AppWizard[dll] 下生成 DLL 文件又有三种方式，在创建 DLL 是，要根据实际情况选择创建 DLL 的方式。一种是常规 DLL 静态链接到 MFC ，另一种是常规 DLL 动态链接到 MFC 。两者的区别是：前者使用的是 MFC 的静态链接库，生成的 DLL 文件长度大，一般不使用这种方式，后者使用 MFC 的动态链接库，生成的 DLL 文件长度小；动态链接到 MFC 的规则 DLL 所有输出的函数应该以如下语句开始：
　

　　最后一种是 MFC 扩展 DLL ，这种 DLL 特点是用来建立 MFC 的派生类， Dll 只被用 MFC 类库所编写的应用程序所调用。前面我们已经介绍过， Extension DLLs 和 Regular DLLs 不一样，它没有一个从 CWinApp 继承而来的类的对象，编译器默认了一个 DLL 入口函数 DLLMain() 作为对 DLL 的初始化，你可以在此函数中实现初始化 , 代码如下：
　

　　参数 hinstDll 存放 DLL 的句柄，参数 reason 指明调用函数的原因， lpReserved 是一个被系统所保留的参数。对于隐式链接是一个非零值，对于显式链接值是零。

　　在 MFC 下建立 DLL 文件，会自动生成 def 文件框架，其它与建立传统的 Non-MFC DLL 没有什么区别，只要在相应的头文件写入关键字 _declspec(dllexport) 函数类型和函数名等，或在生成的 def 文件中 EXPORTS 下输入函数名就可以了。需要注意的是在向其它开发人员分发 MFC 扩展 DLL 时，不要忘记提供描述 DLL 中类的头文件以及相应的 .LIB 文件和 DLL 本身，此后开发人员就能充分利用你开发的扩展 DLL 了。

　应用程序使用DLL可以采用两种方式：一种是隐式链接，另一种是显式链接。在使用DLL之前首先要知道DLL中函数的结构信息。Visual C++6.0在VCin目录下提供了一个名为Dumpbin.exe的小程序，用它可以查看DLL文件中的函数结构。另外，Windows系统将遵循下面的搜索顺序来定位DLL： 1．包含EXE文件的目录，2．进程的当前工作目录， 3．Windows系统目录， 4．Windows目录，5．列在Path环境变量中的一系列目录。

　　1．隐式链接

　　隐式链接就是在程序开始执行时就将DLL文件加载到应用程序当中。实现隐式链接很容易，只要将导入函数关键字_declspec(dllimport)函数名等写到应用程序相应的头文件中就可以了。下面的例子通过隐式链接调用MyDll.dll库中的Min函数。首先生成一个项目为TestDll，在DllTest.h、DllTest.cpp文件中分别输入如下代码：
　

　　在创建 DllTest.exe 文件之前，要先将 MyDll.dll 和 MyDll.lib 拷贝到当前工程所在的目录下面，也可以拷贝到 windows 的 System 目录下。如果 DLL 使用的是 def 文件，要删除 TestDll.h 文件中关键字 extern "C" 。 TestDll.h 文件中的关键字 Progam commit 是要 Visual C+ 的编译器在 link 时，链接到 MyDll.lib 文件，当然，开发人员也可以不使用 #pragma comment(lib ， "MyDll.lib") 语句，而直接在工程的 Setting->Link 页的 Object/Moduls 栏填入 MyDll.lib 既可。

　　 2 ．显式链接

　　显式链接是应用程序在执行过程中随时可以加载 DLL 文件，也可以随时卸载 DLL 文件，这是隐式链接所无法作到的，所以显式链接具有更好的灵活性，对于解释性语言更为合适。不过实现显式链接要麻烦一些。在应用程序中用 LoadLibrary 或 MFC 提供的 AfxLoadLibrary 显式的将自己所做的动态链接库调进来，动态链接库的文件名即是上述两个函数的参数，此后再用 GetProcAddress() 获取想要引入的函数。自此，你就可以象使用如同在应用程序自定义的函数一样来调用此引入函数了。在应用程序退出之前，应该用 FreeLibrary 或 MFC 提供的 AfxFreeLibrary 释放动态链接库。下面是通过显式链接调用 DLL 中的 Max 函数的例子。
　

　　在上例中使用类型定义关键字 typedef ，定义指向和 DLL 中相同的函数原型指针，然后通过 LoadLibray() 将 DLL 加载到当前的应用程序中并返回当前 DLL 文件的句柄，然后通过 GetProcAddress() 函数获取导入到应用程序中的函数指针，函数调用完毕后，使用 FreeLibrary() 卸载 DLL 文件。在编译程序之前，首先要将 DLL 文件拷贝到工程所在的目录或 Windows 系统目录下。

　　使用显式链接应用程序编译时不需要使用相应的 Lib 文件。另外，使用 GetProcAddress() 函数时，可以利用 MAKEINTRESOURCE() 函数直接使用 DLL 中函数出现的顺序号，如将 GetProcAddress(hDLL,"Min") 改为 GetProcAddress(hDLL, MAKEINTRESOURCE(2)) （函数 Min() 在 DLL 中的顺序号是 2 ），这样调用 DLL 中的函数速度很快，但是要记住函数的使用序号，否则会发生错误。 

关键词

摘要

正文

首先char* 是指向ANSI字符数组的指针，其中每个字符占据8位（有效数据是除掉最高位的其他7位），这里保持了与传统的C,C++的兼容。

LP的含义是长指针(long pointer)。LPSTR是一个指向以‘\0’结尾的ANSI字符数组的指针，与char*可以互换使用，在win32中较多地使用LPSTR。
而LPCSTR中增加的‘C’的含义是“CONSTANT”（常量），表明这种数据类型的实例不能被使用它的API函数改变，除此之外，它与LPSTR是等同的。
1.LP表示长指针,在win16下有长指针(LP)和短指针(P)的区别,而在win32下是没有区别的,都是32位.所以这里的LP和P是等价的.
2.C表示const
3.T是什么东西呢,我们知道TCHAR在采用Unicode方式编译时是wchar_t,在普通时编译成char.

为了满足程序代码国际化的需要，业界推出了Unicode标准，它提供了一种简单和一致的表达字符串的方法，所有字符中的字节都是16位的值，其数量也可以满足差不多世界上所有书面语言字符的编码需求，开发程序时使用Unicode（类型为wchar_t)是一种被鼓励的做法。

LPWSTR与LPCWSTR由此产生，它们的含义类似于LPSTR与LPCSTR，只是字符数据是16位的wchar_t而不是char。

然后为了实现两种编码的通用，提出了TCHAR的定义：
如果定义_UNICODE，声明如下：
typedef wchar_t TCHAR;
如果没有定义_UNICODE，则声明如下：
typedef char TCHAR;

LPTSTR和LPCTSTR中的含义就是每个字符是这样的TCHAR。

CString类中的字符就是被声明为TCHAR类型的，它提供了一个封装好的类供用户方便地使用。

LPCTSTR:
     #ifdef _UNICODE
        typedef const wchar_t * LPCTSTR;
     #else
        typedef const char * LPCTSTR;
     #endif

将CString转换成char * 时
CString str("aaaaaaa");
strcpy(str.GetBuffer(10),"aa");
str.ReleaseBuffer();
当我们需要字符数组时调用GetBuffer(int n),其中n为我们需要的字符数组的长度.使用完成后一定要马上调用ReleaseBuffer();
还有很重要的一点就是,在能使用const char *的地方,就不要使用char *

2、memcpy：
CString mCS=_T("cxl");
char mch[20];
memcpy(mch,mCS,20);

3、用LPCTSTR强制转换： 尽量不使用
char *ch;
CString str;
ch=(LPSTR)(LPCTSTR)str;

CString str = "good";
char *tmp;
sprintf(tmp,"%s",(LPTSTR)(LPCTSTR)str);

4、
CString Msg;
Msg=Msg+"abc";
LPTSTR lpsz;
lpsz = new TCHAR[Msg.GetLength()+1];
_tcscpy(lpsz, Msg);
char * psz;
strcpy(psz,lpsz);

CString类向const char *转换
char a[100];
CString str("aaaaaa");
strncpy(a,(LPCTSTR)str,sizeof(a));
或者如下:
strncpy(a,str,sizeof(a));
以上两种用法都是正确地. 因为strncpy的第二个参数类型为const char *.所以编译器会自动将CString类转换成const char *.

CString转LPCTSTR (const char *)
CString cStr;
const char *lpctStr=(LPCTSTR)cStr;

LPCTSTR转CString
LPCTSTR lpctStr;
CString cStr=lpctStr;

将char*类型的变量赋给CString型的变量
可以直接赋值，如：
CString myString = "This is a test";
也可以利用构造函数，如：
CString s1("Tom");

将CString类型的变量赋给char []类型(字符串)的变量
1、sprintf()函数
CString str = "good";
char tmp[200] ;
sprintf(tmp, "%s",(LPCSTR)str);  
(LPCSTR)str这种强制转换相当于(LPTSTR)(LPCTSTR)str
CString类的变量需要转换为(char*)的时,使用(LPTSTR)(LPCTSTR)str

然而，LPCTSTR是const char *,也就是说，得到的字符串是不可写的！将其强制转换成LPTSTR去掉const，是极为危险的！
一不留神就会完蛋！要得到char *,应该用GetBuffer()或GetBufferSetLength()，用完后再调用ReleaseBuffer()。

2、strcpy()函数
CString str;
char c[256];
strcpy(c, str);

char mychar[1024];
CString source="Hello";
strcpy((char*)&mychar,(LPCTSTR)source);

关于CString的使用
1、指定 CString 形参
    对于大多数需要字符串参数的函数，最好将函数原型中的形参指定为一个指向字符 (LPCTSTR) 而非 CString 的 const 指针。
当将形参指定为指向字符的 const 指针时，可将指针传递到 TCHAR 数组（如字符串 ["hi there"]）或传递到 CString 对象。
CString 对象将自动转换成 LPCTSTR。任何能够使用 LPCTSTR 的地方也能够使用 CString 对象。

2、如果某个形参将不会被修改，则也将该参数指定为常数字符串引用（即 const CString&）。如果函数要修改该字符串，
则删除 const 修饰符。如果需要默认为空值，则将其初始化为空字符串 [""]，如下所示：
void AddCustomer( const CString& name, const CString& address, const CString& comment = "" );

3、对于大多数函数结果，按值返回 CString 对象即可。

串的基本运算
    对于串的基本运算，很多高级语言均提供了相应的运算符或标准的库函数来实现。
为叙述方便，先定义几个相关的变量：
    char s1[20]="dir/bin/appl",s2[20]="file.asm",s3[30],*p;
    int result;
    下面以C语言中串运算介绍串的基本运算
1、求串长
        int strlen(char *s);         //求串s的长度
    【例】printf("%d",strlen(s1));    //输出s1的串长12

2、串复制
    char *strcpy(char *to,*from)；//将from串复制到to串中，并返回to开始处指针
    【例】strcpy(s3,s1);  //s3="dir/bin/appl",s1串不变

3、联接
    char *strcat(char *to,char *from);//将from串复制到to串的末尾，
                                      //并返回to串开始处的指针
    【例】strcat(s3,"/");    //s3="dir/bin/appl/"
         strcat(s3,s2);     //s3="dir/bin/appl/file.asm"

4、串比较
    int strcmp(char *s1,char *s2);//比较s1和s2的大小，
     //当s1<s2、s1>s2和s1=s2时，分别返回小于0、大于0和等于0的值
    【例】result=strcmp("baker","Baker");    //result>0
            result=strcmp("12","12");       //result=0
            result=strcmp("Joe","joseph")   //result<0

5、字符定位
    char *strchr(char *s,char c);//找c在字符串s中第一次出现的位置，
                                 //若找到，则返回该位置，否则返回NULL
    【例】p=strchr(s2,'.');      //p指向"file"之后的位置
　　　　　if(p) strcpy(p,".cpp");     //s2="file.cpp"

  注意：
    　①上述操作是最基本的，其中后 4个操作还有变种形式：strncpy，strncath和strnchr。
    　②其它的串操作见C的<string.h>。在不同的高级语言中，对串运算的种类及符号都不尽相同
    　③其余的串操作一般可由这些基本操作组合而成

    【例】求子串的操作可如下实现：
    void substr(char *sub,char *s,int pos,int len){
         //s和sub是字符数组，用sub返回串s的第pos个字符起长度为len的子串
         //其中0<=pos<=strlen(s)-1,且数组sub至少可容纳len+1个字符。
        if (pos<0||pos>strlen(s)-1||len<0)
            Error("parameter error!");
        strncpy(sub,&s[pos],len);      //从s[pos]起复制至多len个字符到sub
--- http://www.cppblog.com/colelhx/archive/2007/09/13/32116.html

具体来说，我们将通过IMAGE_IMPORT_DESCRIPTOR数组来访问“.idata”段中引入的DLL的信息，然后通过IMAGE_THUNK_DATA数组来针对一个被引入的DLL访问该DLL中被引入的每个函数的信息，找到我们需要截获的函数的跳转地址，然后改成我们自己的函数的地址……具体的做法在后面的关键代码中会有详细的讲解。
   讲了这么多原理，现在让我们回到“鼠标屏幕取词”的专题上来。除了API函数的截获，要实现“鼠标屏幕取词”，还需要做一些其它的工作，简单的说来，可以把一个完整的取词过程归纳成以下几个步骤：
1． 安装鼠标钩子，通过钩子函数获得鼠标消息。
使用到的API函数：SetWindowsHookEx
2． 得到鼠标的当前位置，向鼠标下的窗口发重画消息，让它调用系统函数重画窗口。
     使用到的API函数：WindowFromPoint，ScreenToClient，InvalidateRect
3． 截获对系统函数的调用，取得参数，也就是我们要取的词。
对于大多数的Windows应用程序来说，如果要取词，我们需要截获的是“Gdi32.dll”中的“TextOutA”函数。
我们先仿照TextOutA函数写一个自己的MyTextOutA函数，如：
BOOL WINAPI MyTextOutA(HDC hdc, int nXStart, int nYStart, LPCSTR lpszString,int cbString)
{
       // 这里进行输出lpszString的处理
           // 然后调用正版的TextOutA函数
}
把这个函数放在安装了钩子的动态连接库中，然后调用我们最后给出的HookImportFunction函数来截获进程
对TextOutA函数的调用，跳转到我们的MyTextOutA函数，完成对输出字符串的捕捉。HookImportFunction的
用法：
 HOOKFUNCDESC hd;
 PROC         pOrigFuns;
 hd.szFunc=TextOutA;
 hd.pProc=(PROC)MyTextOutA;
 HookImportFunction (AfxGetInstanceHandle(),gdi32.dll,&hd,pOrigFuns);
下面给出了HookImportFunction的源代码，相信详尽的注释一定不会让您觉得理解截获到底是怎么实现的
很难，Ok,Let’s Go：

///////////////////////////////////////////// Begin ///////////////////////////////////////////////////////////////
#include <crtdbg.h>

// 这里定义了一个产生指针的宏
#define MakePtr(cast, ptr, AddValue) (cast)((DWORD)(ptr)+(DWORD)(AddValue))

// 定义了HOOKFUNCDESC结构,我们用这个结构作为参数传给HookImportFunction函数
typedef struct tag_HOOKFUNCDESC
{
  LPCSTR szFunc; // The name of the function to hook.
  PROC pProc;    // The procedure to blast in.
} HOOKFUNCDESC , * LPHOOKFUNCDESC;

// 这个函数监测当前系统是否是WindowNT
BOOL IsNT();

// 这个函数得到hModule -- 即我们需要截获的函数所在的DLL模块的引入描述符(import descriptor)
PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hModule, LPCSTR szImportModule);

// 我们的主函数
BOOL HookImportFunction(HMODULE hModule, LPCSTR szImportModule,
                         LPHOOKFUNCDESC paHookFunc, PROC* paOrigFuncs)
{
/////////////////////// 下面的代码检测参数的有效性 ////////////////////////////
 _ASSERT(szImportModule);
 _ASSERT(!IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC)));
#ifdef _DEBUG
 if (paOrigFuncs) _ASSERT(!IsBadWritePtr(paOrigFuncs, sizeof(PROC)));
 _ASSERT(paHookFunc.szFunc);
 _ASSERT(*paHookFunc.szFunc != \0);
        _ASSERT(!IsBadCodePtr(paHookFunc.pProc));
#endif
 if ((szImportModule == NULL) || (IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC))))
 {
  _ASSERT(FALSE);
  SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
  return FALSE;
 }
//////////////////////////////////////////////////////////////////////////////

 // 监测当前模块是否是在2GB虚拟内存空间之上
 // 这部分的地址内存是属于Win32进程共享的
 if (!IsNT() && ((DWORD)hModule >= 0x80000000))
 {
  _ASSERT(FALSE);
  SetLastErrorEx(ERROR_INVALID_HANDLE, SLE_ERROR);
  return FALSE;
 }
     // 清零
 if (paOrigFuncs) memset(paOrigFuncs, NULL, sizeof(PROC));

 // 调用GetNamedImportDescriptor()函数,来得到hModule -- 即我们需要
 // 截获的函数所在的DLL模块的引入描述符(import descriptor)
 PIMAGE_IMPORT_DESCRIPTOR pImportDesc = GetNamedImportDescriptor(hModule, szImportModule);
 if (pImportDesc == NULL)
 return FALSE; // 若为空,则模块未被当前进程所引入

 //  从DLL模块中得到原始的THUNK信息,因为pImportDesc->FirstThunk数组中的原始信息已经
 //  在应用程序引入该DLL时覆盖上了所有的引入信息,所以我们需要通过取得pImportDesc->OriginalFirstThunk
 //  指针来访问引入函数名等信息
 PIMAGE_THUNK_DATA pOrigThunk = MakePtr(PIMAGE_THUNK_DATA, hModule,
                                               pImportDesc->OriginalFirstThunk);

 //  从pImportDesc->FirstThunk得到IMAGE_THUNK_DATA数组的指针,由于这里在DLL被引入时已经填充了
 //  所有的引入信息,所以真正的截获实际上正是在这里进行的
 PIMAGE_THUNK_DATA pRealThunk = MakePtr(PIMAGE_THUNK_DATA, hModule, pImportDesc->FirstThunk);

 //  穷举IMAGE_THUNK_DATA数组,寻找我们需要截获的函数,这是最关键的部分!
 while (pOrigThunk->u1.Function)
 {
  // 只寻找那些按函数名而不是序号引入的函数
  if (IMAGE_ORDINAL_FLAG != (pOrigThunk->u1.Ordinal & IMAGE_ORDINAL_FLAG))
  {
   // 得到引入函数的函数名
   PIMAGE_IMPORT_BY_NAME pByName = MakePtr(PIMAGE_IMPORT_BY_NAME, hModule,
               pOrigThunk->u1.AddressOfData);

   // 如果函数名以NULL开始,跳过,继续下一个函数  
   if (\0 == pByName->Name[0])
    continue;

   // bDoHook用来检查是否截获成功
   BOOL bDoHook = FALSE;

   // 检查是否当前函数是我们需要截获的函数
   if ((paHookFunc.szFunc[0] == pByName->Name[0]) &&
    (strcmpi(paHookFunc.szFunc, (char*)pByName->Name) == 0))
   {
    // 找到了!
    if (paHookFunc.pProc)
    bDoHook = TRUE;
   }
   if (bDoHook)
   {
    // 我们已经找到了所要截获的函数,那么就开始动手吧
    // 首先要做的是改变这一块虚拟内存的内存保护状态,让我们可以自由存取
    MEMORY_BASIC_INFORMATION mbi_thunk;
    VirtualQuery(pRealThunk, &mbi_thunk, sizeof(MEMORY_BASIC_INFORMATION));
    _ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,
                        PAGE_READWRITE, &mbi_thunk.Protect));

    // 保存我们所要截获的函数的正确跳转地址
    if (paOrigFuncs)
      paOrigFuncs = (PROC)pRealThunk->u1.Function;

    // 将IMAGE_THUNK_DATA数组中的函数跳转地址改写为我们自己的函数地址!
    // 以后所有进程对这个系统函数的所有调用都将成为对我们自己编写的函数的调用
    pRealThunk->u1.Function = (PDWORD)paHookFunc.pProc;

    // 操作完毕!将这一块虚拟内存改回原来的保护状态
    DWORD dwOldProtect;
    _ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,
                        mbi_thunk.Protect, &dwOldProtect));
    SetLastError(ERROR_SUCCESS);
    return TRUE;
   }
  }
  // 访问IMAGE_THUNK_DATA数组中的下一个元素
  pOrigThunk++;
  pRealThunk++;
 }
 return TRUE;
}

// GetNamedImportDescriptor函数的实现
PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hModule, LPCSTR szImportModule)
{
 // 检测参数
 _ASSERT(szImportModule);
 _ASSERT(hModule);
 if ((szImportModule == NULL) || (hModule == NULL))
 {
  _ASSERT(FALSE);
  SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
  return NULL;
 }

 // 得到Dos文件头
 PIMAGE_DOS_HEADER pDOSHeader = (PIMAGE_DOS_HEADER) hModule;

 // 检测是否MZ文件头
 if (IsBadReadPtr(pDOSHeader, sizeof(IMAGE_DOS_HEADER)) ||
  (pDOSHeader->e_magic != IMAGE_DOS_SIGNATURE))
 {
  _ASSERT(FALSE);
  SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
  return NULL;
 }

 // 取得PE文件头
 PIMAGE_NT_HEADERS pNTHeader = MakePtr(PIMAGE_NT_HEADERS, pDOSHeader, pDOSHeader->e_lfanew);

 // 检测是否PE映像文件
 if (IsBadReadPtr(pNTHeader, sizeof(IMAGE_NT_HEADERS)) ||
   (pNTHeader->Signature != IMAGE_NT_SIGNATURE))
 {
  _ASSERT(FALSE);
  SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
  return NULL;
 }

 // 检查PE文件的引入段(即 .idata section)
 if (pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress == 0)
  return NULL;

 // 得到引入段(即 .idata section)的指针
 PIMAGE_IMPORT_DESCRIPTOR pImportDesc = MakePtr(PIMAGE_IMPORT_DESCRIPTOR, pDOSHeader,
  pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);

 // 穷举PIMAGE_IMPORT_DESCRIPTOR数组寻找我们需要截获的函数所在的模块
 while (pImportDesc->Name)
 {
  PSTR szCurrMod = MakePtr(PSTR, pDOSHeader, pImportDesc->Name);
  if (stricmp(szCurrMod, szImportModule) == 0)
      break; // 找到!中断循环
  // 下一个元素
  pImportDesc++;
 }

 // 如果没有找到,说明我们寻找的模块没有被当前的进程所引入!
 if (pImportDesc->Name == NULL)
  return NULL;

 // 返回函数所找到的模块描述符(import descriptor)
 return pImportDesc;
}

// IsNT()函数的实现
BOOL IsNT()
{
 OSVERSIONINFO stOSVI;
 memset(&stOSVI, NULL, sizeof(OSVERSIONINFO));
 stOSVI.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
 BOOL bRet = GetVersionEx(&stOSVI);
 _ASSERT(TRUE == bRet);
 if (FALSE == bRet) return FALSE;
 return (VER_PLATFORM_WIN32_NT == stOSVI.dwPlatformId);
}
/////////////////////////////////////////////// End //////////////////////////////////////////////////////////////////////

   不知道在这篇文章问世之前，有多少朋友尝试过去实现“鼠标屏幕取词”这项充满了挑战的技术，也只有尝试过的朋友才能体会到其间的不易，尤其在探索API函数的截获时，手头的几篇资料没有一篇是涉及到关键代码的，重要的地方都是一笔代过，MSDN更是显得苍白而无力，也不知道除了IMAGE_IMPORT_DESCRIPTOR和IMAGE_THUNK_DATA，微软还隐藏了多少秘密，好在硬着头皮还是把它给攻克了，希望这篇文章对大家能有所帮助。