【windows核心编程】DLL相关（3）

DLL重定向

因为DLL的搜索路径有先后次序，假设有这样的场景：
App1.exe使用MyDll1.0.dll， App2.exe使用MyDll2.0.dll， MyDll1.0 和 MyDll2.0是同一个DLL的两个版本，1.0为旧版本，2.0为新版本。

而如果MyDll2.0.dll的存放路径的优先次序比较靠前时，那么App1.exe就会去加载MyDll2.0.dll，这就可能引发

DLL地狱问题，因此DLL重定向可解决这个问题。

加载程序总是先检查应用程序目录，我们所要做的就是如下：

①在应用程序目录下，新建AppName.local的文件，文件内容无所谓，比如App1.exe，对应文件名为App1.exe.local。

②在应用程序目录下，新建AppName.local的目录，把用到的DLL都放在这个目录下，比如App1.exe，对应目录为App1.exe.local。

注意：Windows中这项特性默认是关闭的，需要在

HKML\Software\Microsoft\WindowsNT\CurrentVersionImag\Image File Execution Options注册表中建一个新项，DWORD  DevOverrideEnable，值为1.

模块的基地址重定位

每个exe和DLL都有一个【首选基地址】，当系统为exe创建进程地址空间的时候，将exe加载进进程地址空间的该地址，默认为0x004000000；

当加载器将DLL加载进进程地址空间的时候，见DLL加载到其首选及地址，DLL默认为0x10000000。

也可以在VS的项目属性中设置模块的【基地址】：项目属性--配置属性--链接器--高级--基地址；  基地址必须是分配粒度的整数倍。

可以用VS的命令dumpbin来查看，也可以用depend是来查看。

e.g.

dumpbin  /headers  ADll.dll

 编译器和连接器在生成代码的时候会将【全局变量】和【静态变量】的地址硬编码，比如有如代码

//全局变量
int g_num = ;

void CUseADll2Dlg::OnBnClickedButton4()
{
    g_num = 0x04030201;

    //局部变量
    int num = ;
    num = 0x01020304;

    //静态局部变量
    int static s_num = ;
    s_num = 0x02030401;
}

其对应的反汇编代码如下：

可以看到【全局变量】和【静态变量】的地址采用的是硬编码，而局部变量则不是。

DLL的导出段中有符号(变量、函数)的RVA(相对虚拟地址)，当DLL被加载到进程地址空间的时候，

符号的在进程地址空间中的地址 = DLL基地址 + RVA;

A.DLL 和 B.DLL的首选基地址都为0x10000000，那么当A.DLL被加载到进程地址空间的此地址的时候，B.DLL就不能被加载到此地址，此时，B.DLL就需要被重定位，那么DLL中的全局变量和静态变量的的地址就需要使用新的基地址重新计算。

假设B.DLL被加载到0x20000000，那么DLL中的全局变量和静态变量的地址就需要重新计算，此时需要有下面的动作：

①加载程序必须遍历重定位段并修改模块中大量的代码，这个过程会带来性能上的损失

②当加载程序写入模块的代码页面中时，系统的【写时复制】(copy-on-wirte)机制就会强制这些页面以系统的【页交换文件】作为后备存储器，这会导致内存页面的换入换出，这对性能是个损失。

创建一个不包含【重定位段】的exe或DLL

在vs的连接器选项中执行【/FIXED】选项，这个开关可以让模块大小变小，但是如果不能被加载到其首选基地址，那么就会载入失败。

对于一个【资源DLL】，不包含任何代码，合理的做法是：使用/FIXED开关， 并在文件头中嵌入一些信息（书上也没说到底是是什么信息，怎么嵌入？）来表示不包含重定位段是合理的。

创建一个不包含任何重定位信息的映像

①/SUBSYSTEM:WINDOWS 或  /SUBSYSTEM:CONSOLE

②不指定/FIXED开关

③在文件头中关闭【IMAGE_FILE_RELOCS_STRIPPED】标志

 VS提供了一个工具来某个模块用到的DLL进行静态重定位，Rebase.exe

通过调用ImageHlp API提供的ReBaseImage函数也可以实现重定位工具。

e.g.

在UseDll3程序中用到了两个DLL， ADll.dll 和  BDll.dll

//UseDll3项目的stdafx.h

#pragma comment(lib, "ADll.lib")
#pragma comment(lib, "BDll.lib") 

extern "C" __declspec(dllimport)  int __stdcall Add(int a, int b);  

extern "C" __declspec(dllimport)  int __stdcall Multi(int a, int b);

在depends中看到的DLL依赖

两者的首选基地址

现在使用rebase工具来UseDll3模块进行重定位

//略，how to use  rebase order ??  未完待续

rebase所做的操作

①模拟创建一个进程地址空间

②打开应该被载入的的所有模块，得到每个模块的【大小】和【首选基地址】

③在模拟的地址空间中对模块重定位过程进程模拟，使个模块没有交叠

④对每个重定位过的模块，解析其【重定位段】，并修改模块在磁盘文件中的代码

⑤更改每个重定位过的模块的文件头，更新其【首选基地址】

模块的绑定

VS提供了bind.exe这一工具来进行绑定，也可以使用BindMageEx()函数来实现。

对模块重定位后，仅仅是修改了其【首选基地址】，加载器还需要在运行时将【导入符号】的虚拟地址写入exe模块的【导入段】中，这也会造成这些页面以【页交换文件】作为后备存储器，也会带来内存换页的性能损失。

而模块的绑定，就是将每个DLL的【导出段】的符号的 【基地址+RVA】，写入exe模块的【导入段】，并且更新DLL的文件头信息，告诉系统这个模块已经被绑定过了， 当为exe创建进程地址空间时，就不需要再动态的获取符号的虚拟地址写入exe导入段， 而是直接从exe的【导入段】中读取即可。

NOTE:

bind.exe是基于两个假设的：

①DLL是被加载到他们的【首选基地址】的，可通过rebase来保证

②绑定完成后，DLL【导出段】中所引用的符号位置没发生变化。加载程序会通过检查每个DLL的时间戳来验证。

当加载程序检测到任意假设不成立的时候， 这时加载器就必须按照以前的样子来手的修正exe的【导入段】，如果加载器检测到两个假设都成立，那么就不再重新定位，也不再查看导入函数的虚拟地址。