dll(Dynamic Link Library)，动态链接库，它和exe基本上一样，只不过它的pe文件头中的符号表标明该文件是dll而不是exe。
dll文件的后缀名不仅是dll还可以是ocx和cpl。
dll设计的目的不同于共享对象，它关注的是软件工程中的模块化设计思想，想要做到高内聚低耦合，它方便了软件的升级和维护。
exe文件里面也有基地址和RVA(Relative Virtual Address，相对虚拟地址)。
对于dll来说它的基地址有一个默认值，如果这个默认值被其他模块占用了，它就找个别的地方装载。
dll中有些数据是共享的，有些是进程私有的。
按照这个区别划分的话，就可以把数据段分成两种。
不过由于各进程共同访问公共数据段，如果某一进程恶意破坏数据，其他进程也会受到影响，这存在一定的安全隐患。
ELF中的符号默认都是可以导入导出的，所谓导出就是指可以被别的模块调用，导入就不解释了，而DLL中的符号需要指定才能导入导出。
__declspec(dllexport)用来指定导出符号，__declspec(dllimport)用来指定导入符号。
另外，还可以用def文件中的IMPORT和EXPORTS段来声明符号的导入和导出。
如果是C语言的符号规范，你必须在符号的定义之前加上external
“C”。
就是前面提到的def文件了，它的好处有如下几点：
1、能够控制导出符号的符号名。原来__cdecl、__stdcall、__fastcall都是msvc中的函数规范啊。编译器会对源码中的符号进行修饰，经过修饰的符号变得和环境中的符号不兼容，不便于维护和使用，于是采用def文件对导出符号进行重命名。
2、它可以控制一些链接的过程。它还可以控制输出文件名、段的属性、堆栈大小、版本号等。
即，运行时加载。
Windows提供了3个API：
1、LoadLibrary装载一个DLL进进程地址空间。
2、GetProAddress查找某个符号的地址。
3、FreeLibrary用来卸载某个已经加载的模块。
Windows下的PE文件的导出符号全部集中在导出表中，供其他PE文件调用，它提供的是一种符号与地址的映射关系。
导出表是个DataDirectory的结构体数组，名字叫做IMAGE_EXPORT_DIRECTORY，被定义在Winnt.h中。
DataDirectory中最后三项EAT(Export Address Table)、Name
Table、Name
Ordinal Table分别代表导出地址表、符号名表、名字序号对应表。
导出地址表存放的是个符号的相对虚拟地址。
符号名表存放的是导出符号的名字。
名字序号对应表存放的是函数的序号和函数名的对应关系。
函数序号存在的意义在于节省空间和查找方便，坏处是函数变化了序号也要跟着变化。导出函数一定有序号但可以没有函数名。
在创建DLL时会产生一个EXP，EXP中的.edata存放的是导出表。EXP会与其他目标文件一样一起链接生成DLL并且成为导出表。
来自于DLL和其他可执行文件中的符号会存储在导入表中。
导入表是一个IMAGE_EXPORT_DIRECTORY结构体数组。
IMAGE_EXPORT_DIRECTORY中的FirstThunk指向导入地址数组（Import
Address Table，IAT），每个IAT对应一个被导入的符号。
延迟载入：DLL也支持延迟装载，它是通过特殊的桩代码实现的。
PE DLL的代码段并不是地址无关的。
PE采用了重定基地址的方法来解决模块装载时进程空间中地址冲突的问题。
__declspec(dllimport)的作用是使编译器能够区分函数是从外部导入的还是模块内部定义的。
同一个导出函数会产生两个符号的定义，一个指向该函数的桩代码，一个指向该函数在IAT中的位置。
用__declspec(dllimport)来声明导入函数时会在导入函数前面加上__imp__以确保跟库中的函数符号正确链接。
DLL本身的代码段和数据段并不是地址无关的。
一旦DLL的基址被占用，它就必须被重定位，这需要时间开销。
虽然在DLL中采用二分查找法进行符号字符串的比较和查找，但是由于符号众多，因此这也是一项非常耗时的工作。
以上是影响DLL性能的两个问题。
在装载DLL时发生了地址冲突，就必须对每个绝对地址的引用都进行重定位。
重定位的过程很简单就是在原来的地址基础上加上一个偏移量，但是这是对所有需要重定位的绝对地址而言的。
PE文件的重定位信息都放在reloc段中。
一般来讲exe文件是不会发生重定位的，因为它总是被第一个装载。
而DLL则是动态装载所以它的装载地址可能被占用。
DLL文件中代码段的访问比ELF更加快速，是一种空间换时间的优化策略，因为它每个进程都有一个副本。
确切地说它是装载时重定位基址。
DLL的装载和地址顺序是一样的。
DLL的基地址是可以手动指定的，不然老是重定位多麻烦啊，VC提供这种功能。
一个导出的函数符号可以没有函数名，但是绝对不能没有序号。
序号表示导出函数在导出表中的位置。
内部使用的函数一般只有序号没有函数名。
Windows API虽然函数名是不变的，但是序号总是在变化的。
序号可以通过def文件指定。
凡是涉及到PE文件的查找的地方用的都是二分查找法。
由于无论如何导入导出的符号关系都会被重新解析，而且每次解析完毕后它们被装载的内存地址都相同，那么这个解析过程就是浪费。
针对这种浪费采取的优化策略就叫做DLL绑定，具体方法是把这些导入的符号保存在模块的导入表中每次只需查表即可。
INT(Import Name Table)，导入名称表，把符号运行时的目标地址写到INT中。
DLL更新和重定基址可能导致DLL绑定地址失效。
针对DLL更新，Windows会核对装载的DLL与绑定时的DLL版本是否相同，还有该DLL是否发生过重定基址，如果都没有那就直接查表。
DLL绑定过程可以发生在安装的时候，可能改变可执行文件本身从而导致可执行文件的校验和变化。这对于一些经过加密的和数字签名的程序来说可能会有问题。
Linux下的共享库绝大多数都是用C语言写的，这是因为C++编写的库比C语言编写的库要复杂得多，而且由于C++没有二进制级别的规定只有语法级别的，所以也为共享库的更新带来了不便。
C++带来的麻烦主要表现在以下几个方面：
1、内存释放过程复杂，不好把握。因为不同的DLL和EXE使用不同的堆。
2、所谓的更新只不过是简单的覆盖。
3、正是由于旧版DLL被覆盖，如果新版程序运行出错，旧版程序也运行出错，那就悲剧了。
为了解决程序开发中遇到的兼容性问题，微软推出了组件对象模型(COM，Component
Object Model)。
P300列出了几点用C++编写DLL时应该遵循的原则。
早期Windows中的DLL文件使用范围大，更新也频繁，而且还缺乏版本控制机制，所以DLL不兼容的情况在早期Windows下特别严重，史称DLL噩梦。
导致DLL
HELL发生的3个原因见P301中所说明的。
解决DLL
HELL的方法：
1、由于DLL HELL是由DLL引起的，即动态链接引起的，所以最彻底的解决办法是不使用动态链接，而使用静态链接。
2、避免DLL覆盖。这个可以通过Windows的文件保护机制实现。
3、避免DLL冲突。它主要是针对不同应用程序依赖相同DLL的不同版本的问题，解决办法是让每个应用程序。
.NET下的程序集包括两种类型应用程序集和库程序集，前者是指EXE可执行文件，后者是指DLL动态链接库。
由于程序集包括一个或多个文件所需要一个清单来描述，这个清单叫做Manifest文件，它就是描述了程序及的各种属性信息，其本质是一个XML文件。
在Windows
XP以前的版本中Manifest就是个摆设，这以后的Windows版本在执行可执行文件时首先要读取Manifest内容获取所需的DLL文件列表，然后Windows再根据DLL的Manifest文件去掉用DLL。
CRT(C Run-Time Library)：C语言运行库。
