PE（Portable Execute）文件是Windows下可执行文件的总称，常见的有DLL，EXE，OCX，SYS等，事实上，一个文件是否是PE文件与其扩展名无关，PE文件可以是任何扩展名。那Windows是怎么区分可执行文件和非可执行文件的呢？我们调用LoadLibrary传递了一个文件名，系统是如何判断这个文件是一个合法的动态库呢？这就涉及到PE文件结构了。
PE文件的结构一般来说如下图所示：从起始位置开始依次是DOS头，NT头，节表以及具体的节。
- DOS头是用来兼容MS-DOS操作系统的，目的是当这个文件在MS-DOS上运行时提示一段文字，大部分情况下是：This program cannot be run in DOS mode.还有一个目的，就是指明NT头在文件中的位置。
- NT头包含windows PE文件的主要信息，其中包括一个‘PE’字样的签名，PE文件头（IMAGE_FILE_HEADER）和PE可选头（IMAGE_OPTIONAL_HEADER32），头部的详细结构以及其具体意义在PE文件头文章中详细描述。
- 节表：是PE文件后续节的描述，windows根据节表的描述加载每个节。
- 节：每个节实际上是一个容器，可以包含代码、数据等等，每个节可以有独立的内存权限，比如代码节默认有读/执行权限，节的名字和数量可以自己定义，未必是上图中的三个。
当一个PE文件被加载到内存中以后，我们称之为“映象”（image），一般来说，PE文件在硬盘上和在内存里是不完全一样的，被加载到内存以后其占用的虚拟地址空间要比在硬盘上占用的空间大一些，这是因为各个节在硬盘上是连续的，而在内存中是按页对齐的，所以加载到内存以后节之间会出现一些“空洞”。
因为存在这种对齐，所以在PE结构内部，表示某个位置的地址采用了两种方式，针对在硬盘上存储文件中的地址，称为原始存储地址或物理地址表示距离文件头的偏移；另外一种是针对加载到内存以后映象中的地址，称为相对虚拟地址（RVA），表示相对内存映象头的偏移。
然而CPU的某些指令是需要使用绝对地址的，比如取全局变量的地址，传递函数的地址编译以后的汇编指令中肯定需要用到绝对地址而不是相对映象头的偏移，因此PE文件会建议操作系统将其加载到某个内存地址（这个叫基地址），编译器便根据这个地址求出代码中一些全局变量和函数的地址，并将这些地址用到对应的指令中。例如在IDA里看上去是这个样子：
这种表示方式叫做虚拟地址（VA）。
也许有人要问，既然有VA这么简单的表示方式为什么还要有前面的RVA呢？因为虽然PE文件为自己指定加载的基地址，但是windows有茫茫多的DLL，而且每个软件也有自己的DLL，如果指定的地址已经被别的DLL占了怎么办？如果PE文件无法加载到预期的地址，那么系统会帮他重新选择一个合适的基地址将他加载到此处，这时原有的VA就全部失效了，NT头保存了PE文件加载所需的信息，在不知道PE会加载到哪个基地址之前，VA是无效的，所以在PE文件头中大部分是使用RVA来表示地址的，而在代码中是用VA表示全局变量和函数地址的。那又有人要问了，既然加载基址变了以后VA都失效了，那存在于代码中的那些VA怎么办呢？答案是：重定位。系统有自己的办法修正这些值，到后续重定位表的文章中会详细描述。既然有重定位，为什么NT头不能依靠重定位采用VA表示地址呢（十万个为什么）？因为不是所有的PE都有重定位，早期的EXE就是没有重定位的。
我们都知道PE文件可以导出函数让其他的PE文件使用，也可以从其他PE文件导入函数，这些是如何做到的？PE文件通过导出表指明自己导出那些函数，通过导入表指明需要从哪些模块导入哪些函数。
windows 应用程序与控制台应用程序的区别
从表面上来看：控制台程序运行时是在DOS环境下，或者模拟dos环境运行的程序，运行时一般会启动一个提示符窗口。 而应用程序是Windows环境下的窗口程序。运行时一般会启动一个窗口画面。（例外，病毒木马，就不显示窗口，这决定于是否创建了窗口，或者是否让窗口显示）
但是，实质上，windows应用程序和控制台应用程序的真正区别是，PE文件的结构不同，这点不需要我们去关心，编译器会根据你的选择去构建生成的exe文件的PE结构。
如何告之编译器你的选择？在编译器进行连接的时候，给它一个连接参数：
subsystem:windows或者subsystem:console来告诉它。对于大多数编程工具来说一般在“工程->设置->连接”这个表单里面就可以看到这个参数。
但是通常在我们要创建一个新的工程的时候，编译器会让我们事先选择好是创建windows应用程序还是创建控制台应用程序。这个参数的设置就不用我们操心了。
补充（你可以不看，有点复杂了）：事实上，控制台程序依然还有区别，那就是，16位的可以在DOS操作系统环境中运行的DOS程序（也可以在window运行通常windows会模拟一个dos环境，这时你会程序窗口与平时的提示符窗口明显不一样），和 32位通常只能在windows操作系统中运行的程序。通常32位控制台在DOS下运行，它的PE结构中会给予DOS环境下运行的一个入口点(DOS文件头），这个入口点只有“一行”代码："This program cannot be run in DOS mode" 而在32位系统下，操作系统将将查看PE文件头里面的subsystem字段来获得程序将以什么方式运行（windoes或者console)这个字段里面指示了子系统（CUI对应控制台，GUI对应普通程序，驱动程序等没有子系统）32位的控制台程序当然可以调用PAI函数，而16位的DOS程序则不可以调用API函数。 后台程序一般就是指控制台程序，程序的文件头某个位置指定了该程序是IMAGE_SUBSYSTEM_WINDOWS_GUI还是IMAGE_SUBSYSTEM_WINDOWS_CUI。
再补充关于编译器的一点内容：通常大学里面学习C，c++时，最常用的是VC6.0 TC++3.0 和 TC2.0 VC6.0只能写32位程序。（也就是不能写Dos程序）
而TC++3.0 和 TC2.0这两个编译器是16位的编译器，不能写窗口程序（因为调用不了API（之所以调用不了，固然是编译器的限制，但实质是编译器根本不去使用32位寄存器））
那么，如何才能写一个即可以在DOS运行，又可以在windows下运行的程序(还要带窗口）？那就是要修改exe的PE文件结构，使用人工方法粘贴代码。
某个PE文件，不管是文件文件格式扩展是exe,dll,com,ocx,sys文件中哪一个，最终决定执行该PE文件的子系统的类型（API，GUI如下图所示）
#define IMAGE_SUBSYSTEM_UNKNOWN 0 // Unknown subsystem.
#define IMAGE_SUBSYSTEM_NATIVE 1 // Image doesn't require a subsystem.
#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2 // Image runs in the Windows GUI subsystem.
#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3 // Image runs in the Windows character subsystem.
#define IMAGE_SUBSYSTEM_OS2_CUI 5 // image runs in the OS/2 character subsystem.
#define IMAGE_SUBSYSTEM_POSIX_CUI 7 // image runs in the Posix character subsystem.
#define IMAGE_SUBSYSTEM_NATIVE_WINDOWS 8 // image is a native Win9x driver.
#define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI 9 // Image runs in the Windows CE subsystem.
#define IMAGE_SUBSYSTEM_EFI_APPLICATION 10 //
#define IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER 11 //
#define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12 //
#define IMAGE_SUBSYSTEM_EFI_ROM 13
#define IMAGE_SUBSYSTEM_XBOX 14
#define IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION 16
是由PE文件中的NT头中的可选头IMAGE_OPTIONAL_HEADER32的substem的类型决定的。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
