2024年1月14日发(作者：)
vc的dll基本用法2==
MICROSOFT基础类库：CaptureEncode项目概述
===
应用程序向导已为您创建了这个CaptureEncode应用程序。此应用程序不仅演示Microsoft基础类的基本使用方法，还可作为您编写应用程序的起点。
本文件概要介绍组成CaptureEncode应用程序的每个文件的内容。
这是使用应用程序向导生成的VC++项目的主项目文件。
它包含生成该文件的Visual C++的版本信息，以及有关使用应用程序向导选择的平台、配置和项目功能的信息。
CaptureEncode.h
这是应用程序的主要头文件。它包括其他项目特定的头文件(包括Resource.h)，并声明CCaptureEncodeApp应用程序类。
这是包含应用程序类CCaptureEncodeApp的主要应用程序源文件。
这是程序使用的所有Microsoft Windows资源的列表。它包括RES子目录中存储的图标、位图和光标。此文件可以直接在Microsoft Visual C++中进行编辑。项目资源位于2052中。
这是用作应用程序图标的图标文件。此图标包括在主要资源文件中。
2
此文件包含不在Microsoft Visual C++中进行编辑的资源。您应该将不可由资源编辑器编辑的所有资源放在此文件中。
/////////////////////////////////////////////////////////////////////////////
应用程序向导创建一个对话框类：
CaptureEncodeDlg.h，-对话框
这些文件包含CCaptureEncodeDlg类。该类定义应用程序主对话框的行为。该对话框的模板位于中，该文件可以在Microsoft Visual
C++中进行编辑。
/////////////////////////////////////////////////////////////////////////////
帮助支持：
此文件是帮助项目文件。它包含将帮助文件编译为.chm文件所需的数据。
此文件列出帮助项目的内容。
此文件包含帮助主题的索引。
此文件包含标准MFC命令和屏幕对象的标准帮助主题。将您自己的帮助主题添加到此文件中。
此文件由生成系统用来编译帮助文件。
hlpImages*.gif
这些是Microsoft基础类库标准命令的标准帮助文件主题所需的位图文件。
/////////////////////////////////////////////////////////////////////////////
其他功能：
ActiveX控件
应用程序包括对使用ActiveX控件的支持。
Windows Sockets
应用程序支持通过TCP/IP网络建立通信。
/////////////////////////////////////////////////////////////////////////////
其他标准文件：
StdAfx.h，
这些文件用于生成名为的预编译头(PCH)文件和名为的预编译类型文件。
Resource.h
这是标准头文件，它定义新的资源ID。
Microsoft Visual C++读取并更新此文件。
st
应用程序清单文件供Windows XP用来描述应用程序
对特定版本并行程序集的依赖性。加载程序使用此
信息从程序集缓存加载适当的程序集或
从应用程序加载私有信息。应用程序清单可能为了重新分发而作为
与应用程序可执行文件安装在相同文件夹中的外部.manifest文件包括，
也可能以资源的形式包括在该可执行文件中。
/////////////////////////////////////////////////////////////////////////////
其他注释：
应用程序向导使用"TODO："指示应添加或自定义的源代码部分。
如果应用程序在共享的DLL中使用MFC，则需要重新发布这些MFC DLL；如果应用程序所用的语言与操作系统的当前区域设置不同，则还需要重新发布对应的本地化资源。有关这两个主题的更多信息，请参见MSDN文档中有关Redistributing Visual C++applications(重新发布Visual C++应用程序)的章节。
/////////////////////////////////////////////////////////////////////////////
vc的dll基本用法
因为要用vc的dll，所以今天做了一些试验，还是有几点记录一下：
一.设置：
1.预处理设置：
如果有如下错误
unexpected end of file while looking for divcompiled header
directive
可以禁止预处理，在project=Settings=C/C++=Category(Precompiled
Headers)=Not using divcompiled headers。
2.预处理宏定义：
若有如下错误
definition of dllimport function not allowed
或者警告
inconsistent dll ort assumed.
可以增加一个预处理宏定义，在project=settings=c/c++=Preprocessor
definitions
添加宏定义：
,_AFXEXT
二.def文件
必须要def文件，如果没有，建一个后内容如下：
LIBRARY DESCRIPTION winlin,chess control EXPORTS
就可以了，
def文件用来生成lib文件的。
我采用的方式是：.dll+.lib+.h
也就是导入.h和lib，以及dll。
三.导出函数：
新建vc的dll工程control，做好上述的第一和第二步后，进入第三步。
新建一个function.h头文件，内容如下：
//function.h
//dll打印信息
extern"C"
void AFX_EXT_API dllPrint()；
然后，建立它的实现文件，内容如下：
#include afx.h
#include iostream using namespace std；
#include windows.h
//dll打印信息
extern"C"
void AFX_EXT_API dllPrint()
{
cout"dll has been loaded."endl；
}
编译项目，生成和
四.使用dll中的导出函数
新建控制台工程test，先复制function.h和到test目录，
然后添加到工程连接选项：project=settings=link=object/library modules添加
写main函数如下：
#include afx.h
#include"function.h"
void main()
{
：dllPrint()；
}
编译，执行即可。
注：function.h可以只拷贝到test工程目录下，不一定要添加到test项目中去。
结果如下：
dll has been loaded.
Press any key to continue
五.导出类
新建vcdll工程control，做好第一步和第二步。
新建human.h类的头文件，内容如下：
#ifndef CN_WINLIN_CONTROL_HUMAN
#define CN_WINLIN_CONTROL_HUMAN
//人类
class AFX_EXT_CLASS Human
{
public：
void Display()；
}；
#endif
然后建立它的实现文件，内容如下：
#include afx.h
#include iostream using namespace std；
#include windows.h
#include"human.h"
void Human：Display()
{
cout"dll class Human display."endl；
}
编译，生成和文件。
六.使用dll中的导出类
新建控制台工程test，先复制human.h和到test目录，
然后添加到工程连接选项：project=settings=link=object/library modules添加
写main函数如下：
#include afx.h
#include"human.h"
void main()
{
Human hm；
y()；
}
编译，执行即可。
注：human.h可以只拷贝到test工程目录下，不一定要添加到test项目中去。
结果如下：
dll class Human display.
Press any key to continue
--
：首页文档中心一般文档DLL
[原创文档本文适合初级读者已阅读52144次]
DLL(Dynamic Link Libraries)专题
作者：姜山
原文出处：目录
*引言
*调用方式
*MFC中的DLL
*DLL入口函数
*关于调用约定
*关于DLL的函数
*模块定义文件(.DEF)
*DLL程序和调用其输出函数的程序的关系
引言
比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。
可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。在构造软件系统时，如果将所有模块的源代
码都静态编译到整个应用程序EXE文件中，会产生一些问题：一个缺点是增加了应用程序的大小，它会占用更多的
磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的EXE程序时，
在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。
Windows系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的DLL
(Dynamic Linkable Library)文件，并可对它们单独编译和测试。在运行时，只有当EXE程序确实要调用这些
DLL模块的情况下，系统才会将它们装载到内存空间中。这种方式不仅减少了EXE文件的大小和对内存空间的需求
，而且使这些DLL模块可以同时被多个应用程序使用。Windows自己就将一些主要的系统功能以DLL模块的形式
实现。
一般来说，DLL是一种磁盘文件，以.dll、.DRV、.FON、.SYS和许多以.EXE为扩展名的系统文件都可以是DLL。
它由全局数据、服务函数和资源组成，在运行时被系统加载到调用进程的虚拟空间中，成为调用进程的一部分。
如果与其它DLL之间没有冲突，该文件通常映射到进程虚拟空间的同一地址上。DLL模块中包含各种导出函数，用
于向外界提供服务。DLL可以有自己的数据段，但没有自己的堆栈，使用与调用它的应用程序相同的堆栈模式；
一个DLL在内存中只有一个实例；DLL实现了代码封装性；DLL的编制与具体的编程语言及编译器无关。
在Win32环境中，每个进程都复制了自己的读/写全局变量。如果想要与其它进程共享内存，必须使用内存映射文件
或者声明一个共享数据段。DLL模块需要的堆栈内存都是从运行进程的堆栈中分配出来的。Windows在加载DLL模块
时将进程函数调用与DLL文件的导出函数相匹配。Windows操作系统对DLL的操作仅仅是把DLL映射到需要它的进
程的虚拟地址空间里去。DLL函数中的代码所创建的任何对象(包括变量)都归调用它的线程或进程所有。
调用方式
1、静态调用方式：由编译系统完成对DLL的加载和应用程序结束时DLL卸载的编码(如还有其它程序使用该DLL，
则Windows对DLL的应用记录减1，直到所有相关程序都结束对该DLL的使用时才释放它，简单实用，但不够灵活，
只能满足一般要求。
隐式的调用：需要把产生动态连接库时产生的.LIB文件加入到应用程序的工程中，想使用DLL中的函数时，只须说明
一下。隐式调用不需要调用LoadLibrary()和FreeLibrary()。程序员在建立一个DLL文件时，链接程序会自动生成一
个与之对应的LIB导入文件。该文件包含了每一个DLL导出函数的符号名和可选的标识号，但是并不含有实际的代码。
LIB文件作为DLL的替代文件被编译到应用程序项目中。当程序员通过静态链接方式编译生成应用程序时，应用程序
中的调用函数与LIB文件中导出符号相匹配，这些符号或标识号进入到生成的EXE文件中。LIB文件中也包含了对应的
DLL文件名(但不是完全的路径名)，链接程序将其存储在EXE文件内部。当应用程序运行过程中需要加载DLL文件时
，Windows根据这些信息发现并加载DLL，然后通过符号名或标识号实现对DLL函数的动态链接。所有被应用程序调用
的DLL文件都会在应用程序EXE文件加载时被加载在到内存中。可执行程序链接到一个包含DLL输出函数信息的输入
库文件(.LIB文件)。操作系统在加载使用可执行程序时加载DLL。可执行程序直接通过函数名调用DLL的输出函数，
调用方法和程序内部其它的函数是一样的。
2、动态调用方式：是由编程者用API函数加载和卸载DLL来达到调用DLL的目的，使用上较复杂，但能更加有效地
使用内存，是编制大型应用程序时的重要方式。
显式的调用：是指在应用程序中用LoadLibrary或MFC提供的AfxLoadLibrary显式的将自己所做的动态连接
库调进来，动态连接库的文件名即是上面两个函数的参数，再用GetProcAddress()获取想要引入的函数。
自此，你就可以象使用如同本应用程序自定义的函数一样来调用此引入函数了。在应用程序退出之前，应该用
FreeLibrary或MFC提供的AfxFreeLibrary释放动态连接库。直接调用Win32的LoadLibary函数，
并指定DLL的路径作为参数。LoadLibary返回HINSTANCE参数，应用程序在调用GetProcAddress函数时使用这
一参数。GetProcAddress函数将符号名或标识号转换为DLL内部的地址。程序员可以决定DLL文件何时加载
或不加载，显式链接在运行时决定加载哪个DLL文件。使用DLL的程序在使用之前必须加载(LoadLibrary)
加载DLL从而得到一个DLL模块的句柄，然后调用GetProcAddress函数得到输出函数的指针，在退出之前必须卸
载DLL(FreeLibrary)。
Windows将遵循下面的搜索顺序来定位DLL：
1.包含EXE文件的目录
2.进程的当前工作目录
s系统目录
s目录
5.列在Path环境变量中的一系列目录
MFC中的DLL
*Non-MFC DLL：指的是不用MFC的类库结构，直接用C语言写的DLL，其输出的函数一般用的是标准C接口，
并能被非MFC或MFC编写的应用程序所调用。
*Regular DLL：和下述的Extension DLLs一样，是用MFC类库编写的。明显的特点是在源文件里有一个继承
CWinApp的类。其又可细分成静态连接到MFC和动态连接到MFC上的。
静态连接到MFC的动态连接库只被VC的专业版和企业版所支持。该类DLL应用程序里头的输出函数可
以被任意Win32程序使用，包括使用MFC的应用程序。输入函数有如下形式：
extern"C"EXPORT YourExportedFunction()；
如果没有extern"C"修饰，输出函数仅仅能从C++代码中调用。
DLL应用程序从CWinApp派生，但没有消息循环。
动态链接到MFC的规则DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应
用程序。但是，所有从DLL输出的函数应该以如下语句开始：
AFX_MANAGE_STATE(AfxGetStaticModuleState())
此语句用来正确地切换MFC模块状态。
Regular DLL能够被所有支持DLL技术的语言所编写的应用程序所调用。在这种动态连接库中，它必须有一个
从CWinApp继承下来的类，DLLMain函数被MFC所提供，不用自己显式的写出来。
*
Extension DLL：用来实现从MFC所继承下来的类的重新利用，也就是说，用这种类型的动态连接库，可以用来
输出一个从MFC所继承下来的类。它输出的函数仅可以被使用MFC且动态链接到MFC的应用程序使用。
可以从MFC继承你所想要的、更适于你自己用的类，并把它提供给你的应用程序。你也可随意的给你的应用程
序提供MFC或MFC继承类的对象指针。Extension DLL使用MFC的动态连接版本所创建的，并且它只被用MFC
类库所编写的应用程序所调用。Extension DLLs和Regular DLLs不一样，它没有从CWinApp继承而来的类的
对象，所以，你必须为自己DLLMain函数添加初始化代码和结束代码。
和规则DLL相比，有以下不同：
1、它没有从CWinApp派生的对象；
2、它必须有一个DLLMain函数；
3、DLLMain调用AfxInitExtensionModule函数，必须检查该函数的返回值，如果返回0，DLLMmain也返回0；
4、如果它希望输出CRuntimeClass类型的对象或者资源，则需要提供一个初始化函数来创建一个
CDynLinkLibrary对象。并且，有必要把初始化函数输出；
5、使用扩展DLL的MFC应用程序必须有一个从CWinApp派生的类，而且，一般在InitInstance里调用扩展
DLL的初始化函数。
DLL入口函数
1、每一个DLL必须有一个入口点，DLLMain是一个缺省的入口函数。DLLMain负责初始化和结束工作，每当一个新
的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调
用DLLMain。但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DLLMain。
DLLMain的函数原型：
BOOL APIENTRY DLLMain(HANDLE hModule,DWORD
ul_reason_for_call,LPVOID lpReserved)
{
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH：
.
case DLL_THREAD_ATTACH：
.
case DLL_THREAD_DETACH：
.
case DLL_PROCESS_DETACH：
.
return TRUE；
}
}
参数：
hMoudle：是动态库被调用时所传递来的一个指向自己的句柄(实际上，它是指向_DGROUP段的一个选择符)；
ul_reason_for_call：是一个说明动态库被调原因的标志。当进程或线程装入或卸载动态连接库的时候，操作系统调用入口函数，并说明动态连接库被调用的原因。它所有的可能值为：
DLL_PROCESS_ATTACH：进程被调用；
DLL_THREAD_ATTACH：线程被调用；
DLL_PROCESS_DETACH：进程被停止；
DLL_THREAD_DETACH：线程被停止；
lpReserved：是一个被系统所保留的参数；
2、_DLLMainCRTStartup
为了使用"C"运行库(CRT，C Run time Library)的DLL版本(多线程)，一个DLL应用程序必须指定
_DLLMainCRTStartup为入口函数，DLL的初始化函数必须是DLLMain。
_DLLMainCRTStartup完成以下任务：当进程或线程捆绑(Attach)到DLL时为"C"运行时的数据
(C Runtime Data)分配空间和初始化并且构造全局"C++"对象，当进程或者线程终止使用DLL(Detach)时，
清理C Runtime Data并且销毁全局"C++"对象。它还调用DLLMain和RawDLLMain函数。
RawDLLMain在DLL应用程序动态链接到MFC DLL时被需要，但它是静态链接到DLL应用程序的。在讲
述状态管理时解释其原因。
关于调用约定
动态库输出函数的约定有两种：调用约定和名字修饰约定。
1)调用约定(Calling convention)：决定函数参数传送时入栈和出栈的顺序，由调用者还是被调用者把参数弹出栈，以
及编译器用来识别函数名字的修饰约定。
函数调用约定有多种，这里简单说一下：
1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不
再被支持(实际上它已被定义为__stdcall。除了__pascal外，__fortran和__syscall也不被支持)，取而代之
的是__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理
传送参数的内存栈，但不同的是函数名的修饰部分(关于函数名的修饰部分在后面将详细说明)。
_stdcall是Pascal程序的缺省调用方式，通常用于Win32 API中，函数采用从右到左的压栈方式，
自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和
参数的字节数。
2、C调用约定(即用__cdecl关键字说明)按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参
数的内存栈是由调用者来维护的(正因为如此，实现可变参数的函数只能使用该调用约定)。另外，在函数名修饰
约定方面也有所不同。
_cdecl是C和C++程序缺省的调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文
件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下
划线前缀。它是MFC缺省调用约定。
3、__fastcall调用约定是"人"如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的(实际上，它
用ECX和EDX传送前两个双字(DWORD)或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前
清理传送参数的内存栈)，在函数名修饰约定方面，它和前两者均不同。
_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和
参数的字节数。
4、thiscall仅仅应用于"C++"成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，
因此不能被程序员指定。
5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存
器，退出函数时则产生代码恢复这些寄存器的内容。
naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。
关键字__stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的
Setting.C/C++Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在
输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即__cdecl。
要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模
仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32
中，它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。
2)名字修饰约定
1、修饰名(Decoration name)
"C"或者"C++"函数在内部(编译和链接)通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字
符串。有些情况下使用函数的修饰名是必要的，如在模块定义文件里头指定输出"C++"重载函数、构造函数、析构函数
，又如在汇编代码里调用"C""或"C++"函数等。
修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。
2、名字修饰约定随调用约定和编译种类(C或C++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同，
下面分别说明。
a、C编译时函数名修饰约定规则：
__stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个"@"符号和其参数的字节数，格式为
_functionname@number。
__cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。
__fastcall调用约定在输出函数名前加上一个"@"符号，后面也是一个"@"符号和其参数的字节数，格式
为@functionname@number。
它们均不改变输出函数名中的字符大小写，这和PASCAL调用约定不同，PASCAL约定输出的函数名无任何修饰
且全部大写。
b、C++编译时函数名修饰约定规则：
__stdcall调用约定：
1、以"?"标识函数名的开始，后跟函数名；
2、函数名后面以"@YG"标识参数表的开始，后跟参数表；
3、参数表以代号表示：
X--void，
D--char，
E--unsigned char，
F--short，
H--int，
I--unsigned int，
J--long，
K--unsigned long，
M--float，
N--double，
_N--bool，
.
PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以"0"代替，一个"0"代表一次重复；
4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；
5、参数表后以"@Z"标识整个名字的结束，如果该函数无参数，则以"Z"标识结束。
其格式为"?functionname@YG*@Z"或"?functionname@YG*XZ"，
例如
int Test1(char*var1,unsigned long)---"?Test1@YGHPADK@Z"
void Test2()---"?Test2@YGXXZ"
__cdecl调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@YG"变为"@YA"。
__fastcall调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@YG"变为"@YI"。
VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用。
关于DLL的函数
动态链接库中定义有两种函数：导出函数(export function)和内部函数(internal function)。导出函数可以被其它
模块调用，内部函数在定义它们的DLL程序内部使用。
输出函数的方法有以下几种：
1、传统的方法
在模块定义文件的EXPORT部分指定要输入的函数或者变量。语法格式如下：
entryname[=internalname][@ordinal[NONAME]][DATA][PRIVATE]
其中：
entryname是输出的函数或者数据被引用的名称；
internalname同entryname；
@ordinal表示在输出表中的顺序号(index)；
NONAME仅仅在按顺序号输出时被使用(不使用entryname)；
DATA表示输出的是数据项，使用DLL输出数据的程序必须声明该数据项为_declspec(DLLimport)。
上述各项中，只有entryname项是必须的，其他可以省略。
对于"C"函数来说，entryname可以等同于函数名；但是对"C++"函数(成员函数、非成员函数)来说，
entryname是修饰名。可以从.map映像文件中得到要输出函数的修饰名，或者使用DUMPBIN/SYMBOLS得到，
然后把它们写在.def文件的输出模块。DUMPBIN是VC提供的一个工具。
如果要输出一个"C++"类，则把要输出的数据和成员的修饰名都写入.def模块定义文件。
2、在命令行输出
对链接程序LINK指定/EXPORT命令行参数，输出有关函数。
3、使用MFC提供的修饰符号_declspec(DLLexport)
在要输出的函数、类、数据的声明前加上_declspec(DLLexport)修饰符表示输出。__declspec(DLLexport)
在C调用约定、C编译情况下可以去掉输出函数名的下划线前缀。extern"C"使得在C++中使用C编译方式
成为可能。在"C++"下定义"C"函数需要加extern"C"关键词。用extern"C"来指明该函数使用C编译方式。
输出的"C"函数可以从"C"代码里调用。
例如，在一个C++文件中，有如下函数：
extern"C"{void __declspec(DLLexport)__cdecl Test(int var)；}
其输出函数名为：Test MFC提供了一些宏，就有这样的作用。
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
像AFX_EXT_CLASS这样的宏，如果用于DLL应用程序的实现中，则表示输出(因为_AFX_EXT被定义，通常是在
编译器的标识参数中指定该选项/D_AFX_EXT)；如果用于使用DLL的应用程序中，则表示输入(_AFX_EXT没有定义
)。
要输出整个的类，对类使用_declspec(_DLLexpot)；要输出类的成员函数，则对该函数使用_declspec(_DLLexp ort)。如：
class AFX_EXT_CLASS CTextDoc：public CDocument
{
…
}
extern"C"AFX_EXT_API void WINAPI InitMYDLL()；
这几种方法中，最好采用第三种，方便好用；其次是第一种，如果按顺序号输出，调用效率会高些；最次是
第二种。
模块定义文件(.DEF)
模块定义文件(.DEF)是一个或多个用于描述DLL属性的模块语句组成的文本文件，每个DEF文件至少必须包含以
下模块定义语句：
#第一个语句必须是LIBRARY语句，指出DLL的名字；
#EXPORTS语句列出被导出函数的名字；将要输出的函数修饰名罗列在EXPORTS之下，这个名字必须与定义函数的名
字完全一致，如此就得到一个没有任何修饰的函数名了。
#可以使用DESCRIPTION语句描述DLL的用途(此句可选)；
#"；"对一行进行注释(可选)。
DLL程序和调用其输出函数的程序的关系
1、DLL与进程、线程之间的关系
#DLL模块被映射到调用它的进程的虚拟地址空间。
#DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
#DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
#DLL使用调用进程的栈。
2、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自
己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每
个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread
Local Strorage)。
在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的.必须给这些变量赋初值
,否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。
最新评论[发表评论][文章投稿]查看所有评论推荐给好友打印
DLL_PROCESS_ATTACH：进程被调用；
DLL_THREAD_ATTACH：线程被调用；
DLL_PROCESS_DETACH：进程被停止；
DLL_THREAD_DETACH：线程被停止；
什么东西啊?(cwhwin发表于2007-6-9 12：08：00)
我是一个初学者，非常感谢作者的这篇文章，最主要的是作者的示例，既有文字图象说明，又有源程序参照，我照着
一步一步的做，总算明白了dll的编写过程，真的非常感谢！衷心地支持作者，希望写更多类似的文章，对于我们初
学者可以说是非常宝贵的！(zdrqq发表于2005-9-6 17：11：00)
版权所有1999-2010 VC知识库
MSN空间完美搬家到新浪博客！
特别声明：
1：资料来源于互联网，版权归属原作者
2：资料内容属于网络意见，与本账号立场无关
3：如有侵权，请告知，立即删除。
发布评论