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方法之前应考虑下一些问题，如应用程序是在网络环境下还是在单机环境下工作等。

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

1. 需要给代码的用户一份Apache Licence
2. 如果你修改了代码，需要再被修改的文件中说明。
3. 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4. 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

• 连接池
• 引用记数
• 多线程
• 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 中的函数速度很快，但是要记住函数的使用序号，否则会发生错误。