您的位置:首页 > 其它

Learn DLL (One)

2009-10-13 16:03 232 查看
Learn DLL
1.       DLL 声明
通常,在设计DLL时头文件中进行如下声明:
(1)C或C++编程
#ifndef  XXX_LIBAPI
#define XXX_LIBAPI __declspec(dllimport)
#endif
XXX_LIBAPI 函数声明
(2)C/C++混合编程
#ifndef  XXX_LIBAPI
#define XXX_LIBAPI extern “C” __declspec(dllimport)
#endif
XXX_LIBAPI 函数声明
使用extern “C” 的目的是为了防止C++编译器对函数名进行改编,以免C程序调用时无法找到需要的函数。
 
2.       DLL定义
DLL定义文件中通常有如下形式:
(1)C或C++编程
#define XXX_LIBAPI __declspec(dllexport)
#include “xxxxLib.h” //对应该DLL的头文件

函数定义
(2)C/C++混合编程
#define XXX_LIBAPI extern “C” __declspec(dllexport)
#include “xxxxLib.h” //对应该DLL的头文件
       …
      函数定义
上面的#define 和 #include顺序不能颠倒。
 
3.       为不同编译器创建DLL
在前面都是假设使用相同的编译器,这不会出现问题。如果生成的DLL供其它编译器使用,由于不同编译器对函数名字的改编规则不同,而通常情况下Dll在生成时名字就决定了,这会导致链接程序找不到需要的函数。解决此问题有两种办法:
(1)       使用def文件
def文件称为模块定义文件,在该文件中定义EXPORTS 节,在该节下指定DLL中导出函数的名字,这样在省城DLL时就会生成def定义的名字,从而别的编译器生成的程序也可以引用该DLL。
(2)       使用 #pragma
#pragma comment(linker, "/export:FuncName1=FuncName1_Mangle")
FuncName1 通常是函数声明时的名字,FuncName1_Mangle 编译器改编后的名字;使用这种方法可以使这两个名字等价。但是这种方法不易使用,因为你必须了解编译器的名字改编规则,推荐使用第一种方法
4.       DLL的加载
DLL有两种加载方式:隐式加载和显式加载
(1)       隐式加载
隐式加载通常是在程序中使用#include 指令包含DLL相关的头文件,然后引用DLL中导出的对象,比较简单,不多说。
(2)       显式加载
显示加载是在程序运行时动态加载,这是通过以下两个函数之一实现的:
LoadLibrary(PCTSTR pszDLLPathName)
HMODULE LoadLibraryEx(
        PCTSTR pszDLLPathName,
        HANDLE hFile,
        DWORD dwFlags)
其中,pszDLLPathName 是DLL模块的名字;
hFile保留,设置为NULL
dwFlags为0或者以下值的位组合
   DONT_RESOLVE_DLL_REFERENCES
   LOAD_LIBRARY_AS_DATAFILE
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
LOAD_LIBRARY_AS_IMAGE_RESOURCE
LOAD_WITH_ALTERED_SEARCH_PATH
LOAD_IGNORE_CODE_AUTHZ_LEVEL
对于这些标志,其解释如下:
DONT_RESOLVE_DLL_REFERENCES
该标志告诉系统把DLL模块映射到调用进程的地址空间,但不执行DllMain,也不进行其它DLL的加载。
通常情况下,系统会把DLL映射到调用进程的地址空间,然后执行DllMain对DLL模块进行初始化;而且系统还会检查该DLL是否引用了其它DLL,如果有则加载引用的DLL。
因此,使用该标志时程序很有可能会由于使用未初始化的结构而引发异常,所以最好不要使用该标志。
LOAD_LIBRARY_AS_DATAFILE
该标志与DONT_RESOLVE_DLL_REFERENCES类似,它仅把DLL作为数据文件映射到调用进程的地址空间,不作执行代码的准备。
当DLL仅包含资源时,使用该标志;如果程序使用的资源在exe文件中,则必须使用该标志。
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
该标志与LOAD_LIBRARY_AS_DATAFILE相似,区别在于程序使用该模块时不允许其它程序修改模块,提供更高的安全性
LOAD_LIBRARY_AS_IMAGE_RESOURCE
该标志与LOAD_LIBRARY_AS_DATAFILE 相似,区别在于系统在加载该DLL模块时使用相对虚地址(RVA),这些地址可以直接使用而无需根据DLL在内存中的加载地址进行转换,它使得解析DLL的PE节的时候非常方便
LOAD_WITH_ALTERED_SEARCH_PATH
该标志用于改变loadLibraryEx定位DLL时的搜索算法,关于DLL的定位搜索算法在后面说明。
LOAD_IGNORE_CODE_AUTHZ_LEVEL
该标志用于关闭windows的WinSafer校验。
 
5.       DLL模块的定位搜索
一般情况下,DLL模块的定位算法或搜索顺序如下:
(1)可执行文件(调用DLL)所在目录
(2)Windows系统目录;该目录可以通过函数GetSystemDirectory获得
(3)16位系统目录,即windows目录下的system子目录
(4)Windows目录;该目录可以通过函数GetWindowsDirectory获得
(5)进程的当前目录
(6)PATH环境变量中列出的目录
如果在以上目录中未找到需要的DLL文件,则报错。进程的当前目录在Windows目录之后搜索,这是在Win XP SP2之后改变的,是为了安全原因。通常情况下,加载器还会查看DLL模块的imports节,以确定它所引用的DLL并把这些DLL也加载进来。在前面提到动态显式加载DLL时,标志LOAD_WITH_ALTERED_SEARCH_PATH可以改变LoadLibraryEx的搜索顺序,根据传给该函数的pszDLLPathName参数值,它以三种方式搜索:
(1)       pszDLLPathName不包含路径(不包含‘/’)
采用前面所述的标准搜索算法
(2)       pszDLLPathName含有‘/’字符
在这种情况下,先判断是相对路径还是绝对路径,
l  如果是绝对路径或者网络路径,例如C:/Apps/Libraries/MyLibrary.dll 或//server/share/MyLibrary.dll,系统直接加载该DLL,如果找不到,则返回NULL,错误类型为ERROR_MOD_NOT_FOUND
l  如果是相对路径,则首先把该相对路径与以下路径进行连接,然后加载
a.       进程当前目录
b.       windows系统目录
c.       16位系统目录
d.       windows目录
e.       PATH的列表目录
值得注意的是,如果该参数中含有“.”或“..”,它仍然会不作任何修改进行上述连接
(3)       使用了函数SetDllDirectory,此时搜索顺序变为
a.       程序所在目录
b.       SetDllDirectory设置的目录
c.       windows系统目录
d.       16位系统目录
e.       windows目录
f.        PATH的列表目录
使用SetDllDirectory时,参数如果为“”,则不搜索进程当前目录;如果为NULL,恢复标准搜索。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息