如果在DOS下执行PE格式文件就会执行后面的DOS Stub，显示字符串"This program cannot run in DOS mode"，如果在Window下执行PE格式文件，PE加载器就会根据DOS MZ header中的最后一个域 e_lfnew跳过DOS Stub直接转到PE Header , DOS MZ header 和 DOS Stub的贡献仅此而已。
２. PE Header:
当加载器跳到PE Header后，根据里面的各个域首先检查这是不是有效的PE文件格式，能否在当前的CPU架构下运行，优先加载基址是多少，一共有几个节（section），这是一个EXE文件还是DLL文件等总体信息，有了这些总体信息之后加载器就会跳到下面的Section table。
３．Section table：
有了上面从PE Header获得的总体信息后，加载器并不能准确的加载文件，因为要准确的加载文件，加载器还需要一些关于每一节的更具体的信息，比如：每一节在磁盘文件上的起始位置、大小，应该被加载的线性地址空间的哪一部分，这一节是代码还是数据，读写属性如何等等。所有这些信息都保存在Section table里面，Section table是一个结构数组，数组里面的每一个结构对应PE文件中的一个节。PE加载器就会遍历这个结构数组把PE文件的每一节准确的加载到线性地址空间。(这里还要注意两点：一是PE加载器把PE文件的每一节加载到线性地址空间并不是说把磁盘上的文件调入物理内存；而只是为它分配线性地址空间，分配线性地址空间意味着申请本进程需要的页表，并把相应的信息添入页表中。线性地址空间也可以看作是一种资源，它是通过页表来体现的，当一个页表被添入相应的信息被占用之后那么这个页表对应的那块线性地址空间也就被分配出去了。需要注意的另一点是PE加载器对每一节采用文件映射的方式把相应的磁盘文件映射到内存，而不是把整个PE文件采用文件映射的方法把磁盘文件映射到内存。更具体的解释我会在“Windows 内存管理”中提到。)
４．Sections:
PE文件最后的部分就是各个节了，比如.text , .data , .idata等等，各种节的作用后面会有一个简要介绍。
思考一下：既然加载器不一定把程序加载到PE头中指定的优先加载基址，那么如果在没有加载到PE头中指定的优先加载基址的情况下，指令中的地址是不是都要依次修改呢？首先我们要明确的一点是程序指令中的地址分两大类，其中一类是在编译过程就可以确定的，这类地址采用的是相对虚拟地址（RVA），所以即使程序没有被加载到希望的基址这些地址也无需修改。另一类地址是编译过程和连接过程都无法确定的，比如那些引用外部库的函数地址，因为外部库之后在被加载器加载后里面的函数地址才能确定下来，所以程序中的这类地址要在程序被加载后进行修改。那么编译器和连接器对这类无法确定的地址是如何处理的呢？加载器又是根据什么如何来对它们进行修改的呢？个人感觉PE文件格式学习中这一部分内容有些繁杂，所以希望大家读后面各节的时候最好时常思考一下这两个问题。从下一节开始我们将对PE文件的各个部分作更为详尽的讲解。重点部分会放在对上面两个问题的解决上。
不登高山，怎知天高；不临深溪，焉知地厚！站在坚实的土地上，做着生命中最真实的事情；像一棵挺拔的大树，认可自己的命运并敢于迎接属于这一方天空的风风雨雨。
重庆分公司
重庆分公司
