[注意：本译文的所有大小标题序号都是译者添加，以方便大家阅读。圆圈内的数字是注释的编号，其中注释②译自微软的《PECOFF规范》，其它译自网络。----译者]
一、前言（Preface）------------------
PE（“portableexecutable”，可移植的可执行文件）文件格式，是微软WindwosNT,Windows95和Win32子集①中的可执行的二进制文件的格式；在WindowsNT中，驱动程序也是这种格式。它还能被应用于各种目标文件②和库文件中。
这种文件格式是由微软设计的，并于1993年被TIS（toolinterfacestandard,工具接口标准）委员会（由Microsoft,Intel,Borland,Watcom,IBM,等等组成）所批准，它明显的基于COFF文件格式的许多知识。COFF（“commonobjectfilefromat”,通用目标文件格式）是应用于好几种UNIX系统③和VMS④系统中的目标文件和可执行文件的格式。
Win32SDK⑤中包含一个名叫
你也可能发现DLL文件“imagehelp.dll”很有用途，它是WindowNT的一部分，但其书面文件却很缺乏。它的一些功用在“DeveloperNetwork”（开发者网络）中有所描述。
二、总览（GeneralLayout）-------------------------
在一个PE文件的开始处，我们会看到一个MS-DOS可执行体（英语叫“stub”,意为“根，存根”）；它使任何PE文件都是一个有效的MS-DOS可执行文件。
在DOS-根之后是一个32位的签名以及魔数0x00004550(IMAGE_NT_SIGNATURE)（意为“NT签名”，也就是PE签名；十六进制数45和50分别代表ASCII码字母E和P----译者注）。
那些之后，是可选头（尽管它一直都存在，却仍被称作“可选”----因为COFF文件格式仅为库文件使用一个“可选头”，却不为目标文件使用一个“可选头”，这就是为什么它被称为“可选”的原因）。它会告诉我们该二进制文件怎样被载入的更多信息：开始的地址呀、保留的堆栈数呀、数据段的大小呀、等等。
可选头的一个有趣的部分是尾部的“数据目录”数组；这些目录包含许多指向各“节”数据的指针。例如：如果一个二进制文件拥有一个输出目录，那么你就会在数组成员“IMAGE_DIRECTORY_ENTRY_EXPORT”（输出目录项）中找到一个指向那个目录的指针，而该指针指向文件中的某节。
跟在各种头后面我们就发现各个“节”了，它们都由“节头”引导。本质上讲，各节中的内容才是你执行一个程序真正需要的东西，所有头和目录这些东西只是为了帮助你找到它们。每节都含有和对齐、包含什么样的数据（如“已初始化数据”等等）、是否能共享等有关的一些标记，还有就是数据本身。大多数（并非所有）节都含有一个或多个可通过可选头的“数据目录”数组中的项来参见的目录，如输出函数目录和基址重定位目录等。无目录形式的内容有：例如“可执行代码”或“已初始化数据”等。
+-------------------+|DOS-stub|--DOS-头+-------------------+|file-header|--文件头+-------------------+|optionalheader|--可选头|----------||||datadirectories|--数据目录||+-------------------+|||sectionheaders|--节头||+-------------------+|||section1|--节1||+-------------------+|||section2|--节2||+-------------------+|||...|||+-------------------+|||sectionn|--节n||+-------------------+
三、DOS-根和签名（DOS-stubandSignature）-----------------------------------------
DOS-根的概念很早从16位windows的可执行文件（当时是“NE”格式⑥）时就广为人知了。根原来是用于OS/2⑦系统的可执行文件的，也用于自解压档案文件和其它的应用程序。对于PE文件来说，它是一个总是由大约100个字节所组成的和MS-DOS2.0兼容的可执行体，用来输出象“thisprogramneedswindowsNT”之类的错误信息。
你可以通过确认DOS-头部分是否为一个IMAGE_DOS_HEADER（DOS头）结构来认出DOS-根，它的前两个字节必须为连续的两个字母“MZ”（有一个#defineIMAGE_DOS_SIGNATURE的定义是针对这个WORD单元的）。
你可以通过跟在后面的签名来将一个PE二进制文件和其它含有根的二进制文件区分开来，跟在后面的签名可由头成员'e_lfanew'（它是从字节偏移地址60处开始的，有32字节长）所设定的偏移地址找到。对于OS/2系统和Windows系统的二进制文件来说，签名是一个16位的word单元；对于PE文件来说，它是一个按照8位字节边界对齐的32位的longword单元，并且IMAGE_NT_SIGNATURE（NT签名）的值已由#defined定义为0x00004550（即字母“PE/0/0”----译者）。
四、文件头（FileHeader）-------------------------
要到达IMAGE_FILE_HEADER（文件头）结构，请先确认DOS-头“MZ”（起始的2个字节），然后找出DOS-根的头部的成员“e_lfanew”，并从文件开始处跳过那么多的字节。在核实你在那里找到的签名后，IMAGE_FILE_HEADER（文件头）结构的文件头就紧跟其后开始了，下面我们将从头至尾的介绍其成员。
1）第一个成员是“Machine（机器）”，一个16位的值，用来指出该二进制文件预定运行于什么样的系统。已知的合法的值有：
IMAGE_FILE_MACHINE_I386(0x14c)Intel80386处理器或更高
0x014dIntel80386处理器或更高
0x014eIntel80386处理器或更高
0x0160R3000(MIPS⑧)处理器，大尾⑨
IMAGE_FILE_MACHINE_R3000(0x162)R3000(MIPS)处理器，小尾
IMAGE_FILE_MACHINE_R4000(0x166)R4000(MIPS)处理器，小尾
IMAGE_FILE_MACHINE_R10000(0x168)R10000(MIPS)处理器，小尾
IMAGE_FILE_MACHINE_ALPHA(0x184)DECAlphaAXP⑩处理器
IMAGE_FILE_MACHINE_POWERPC(0x1F0)IBMPowerPC,小尾
2）然后是“NumberOfSections（节数）”成员，16位的值。它是紧跟在头后面的节的数目。我们以后将讨论节的问题。
4-5）成员“PointerToSymbolTable（符号表指针）”和成员“NumberOfSymbols（符号数）”（都是32位）都用于调试信息的。我不知道该怎样去解读它，并且我发现该指针的值总为0。
6）成员“SizeOfOptionalHeader（可选头大小）”（16位）只是“IMAGE_OPTIONAL_HEADER（可选头）”项的大小，你能用它去验证PE文件结构的正确性。
7）成员“Characteristics（特性）”是一个16位的，由许多标志位形成的集合组成，但大多数标志位只对目标文件和库文件有效。具体如下：位0IMAGE_FILE_RELOCS_STRIPPED（重定位被剥离文件）表示如果文件中没有重定位信息，该位置1，这就表明各节的重定位信息都在它们各自的节中；可执行文件不使用该位，它们的重定位信息放在下面将要描述的“baserelocation”（基址重定位）目录中。
位1IMAGE_FILE_EXECUTABLE_IMAGE（可执行映象文件）表示如果文件是一个可执行文件，也即不是目标文件或者库文件时，置1。如果链接器尝试创建一个可执行文件，却因为一些原因失败了，并保存映像以便下次例如增量链接时使用，此时此标志位也可能置1。
位2IMAGE_FILE_LINE_NUMS_STRIPPED（行数被剥离文件）表示如果行数信息被剥除，此位置1；此位也不用于可执行文件。
位3IMAGE_FILE_LOCAL_SYMS_STRIPPED（本地符号被剥离文件）表示如果文件中没有关于本地符号的信息时，此位置1（此位也不用于可执行文件）。
位8IMAGE_FILE_32BIT_MACHINE（32位机器文件）表示如果使用的机器被期望为32位的机器时，此位置1。现在的应用程序总将此位置1；NT5系统可能工作不同。
位9IMAGE_FILE_DEBUG_STRIPPED（调试信息被剥离文件)表示如果文件中没有调试信息，此位置1。此位可执行文件不用。按照其它信息([6])（这里指的是参考书目中的第[6]种----译者注），此位被称作“恒定”，并且当一个映象文件只有在被装入优先的装入地址才能运行（亦即：此文件不可重定位）时，此位置1。位10IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP（移动介质文件从交换文件运行)表示如果一个应用程序不可以从可移动的介质，如软盘或CD-ROM上运行时，此位置1。在这种情况下，建议操作系统将文件复制到交换文件并从那里执行。
位11IMAGE_FILE_NET_RUN_FROM_SWAP（网络文件从交换文件运行)表示如果一个应用程序不可以从网络上运行时，此位置1。在这种情况下，建议操作系统将文件复制到交换文件并从那里执行。
位12IMAGE_FILE_SYSTEM（系统文件)表示如果文件是一个象驱动程序那样的系统文件，此位置1。此位可执行文件不用；我所见过的所有NT系统的驱动程序也不用。
位13IMAGE_FILE_DLL（DLL文件)表示如果文件是一个DLL文件时，此位置1。
位14IMAGE_FILE_UP_SYSTEM_ONLY（仅但处理器系统的文件)表示如果文件不设计运行在多处理器系统上（也就是说，因为此文件严格地依赖单一处理器的一些方式工作，所以它会发生冲突）时，此位置1。
五、相对虚拟地址（RelativeVirtualAddresses）---------------------------------------------
PE格式大量地使用所谓的RVA（相对虚拟地址）。一个RVA，亦即一个“RelativeVirtualAddresses（相对虚拟地址）”，是在你不知道基地址时，被用来描述一个内存地址的。它是需要加上基地址才能获得线性地址的数值。基地址就是PE映象文件被装入内存的地址，并且可能会随着一次又一次的调用而变化。
例如：假若一个可执行文件被装入的地址是0x400000，并且从RVA0x1560处开始执行，那么有效的执行开始处将位于0x401560地址处。假若它被装入的地址为0x100000，那么执行开始处就位于0x101560地址处。
因为PE-文件中的各部分（各节）不需要像已载入的映象文件那样对齐，事情变得复杂起来。例如，文件中的各节常按照512（十六进制的0x200----译者注）字节边界对齐，而已载入的映象文件则可能按照4096（十六进制的0x1000----译者注）字节边界对齐。参见下面的“SectionAlignment（节对齐）”和“FileAlignment（文件对齐）”。
因此，为了在PE文件中找到一个特定RVA地址的信息，你得按照文件已被载入时的那样来计算偏移量，但要按照文件的偏移量来跳过。
试举一例，假若你已知道执行开始处位于RVA0x1560地址处，并且想从那里开始的代码处反汇编。为了从文件中找到这个地址，你得先查明在RAM（内存）中各节是按照4096字节对齐的，并且“.code”节是从RVA0x1000地址处开始，有16384字节长；然后你才知道RVA0x1560地址位于此节的偏移量0x560处。你还要查明在文件中那节是按512字节边界对齐，且“.code”节在文件中从偏移量0x800处开始，然后你就知道在文件中代码的执行开始处就在0x800+0x560=0xd60字节处。
然后你反汇编它并发现访问一个变量的线性地址位于0x1051d0处。二进制文件的线性地址在装入时将被重定位，并常被假定使用的是优先载入地址。因为你已查明优先载入地址为0x100000，因此我们可开始处理RVA0x51d0了。因数据节开始于RVA0x5000处,且有2048字节长，所以它处于数据节中。又因数据节在文件中开始于偏移量0x4800处，所以该变量就可以在文件中的0x4800+0x51d0-0x5000=0x49d0处找到。
六、可选头（OptionalHeader）----------------------------
紧跟在文件头后面的就是IMAGE_OPTIONAL_HEADER（尽管它名叫“可选头”，它却一直都在那里）。它包含有怎样去准确处理PE文件的信息。我们也将从头至尾的介绍其成员。
1）第一个16位的word单元叫“Magic（魔数）”，就我目前所观察过的PE文件而言，它的值总是0x010b。
2-3）下面2个字节是创建此文件的链接器的版本（‘MajorLinkerVersion’，“链接器主版本号”和‘MinorLinkerVersion’，“链接器小版本号”）。这两个值又是不可靠的，并不能总是正确地反映链接器的版本号。（有好几个链接器根本就不设置这个值。）况且，你可想象一下，你连使用的是“什么”链接器都不知道，知道它的版本号又有什么作用呢？
4-6）下面3个longword（每个32位）分别用来设定可执行代码的大小（“SizeOfCode”）、已初始化数据的大小（“SizeOfInitializedData”，所谓的“数据段”）、以及未初始化数据的大小（“SizeOfUninitializedData”，所谓的“bss段”）。这些值也是不可靠的（例如：数据段实际上可能会被编译器或者链接器分成好几段），并且你可以通过查看可选头后面的各个“节”来获得更准确的大小。
7）下一个32位值是RVA。这个RVA是代码入口点的偏移量（‘AddressOfEntryPoint’，“入口点地址”）。执行将从这里开始，它可以是：例如DLL文件的LibMain()的地址，或者一个程序的开始代码（这里相应的叫main()）的地址，或者驱动程序的DriverEntry()的地址。如果你敢于“手工”装载映象文件，那么在你完成所有的修正和重定位后，你可以从这个地址开始执行你的进程。
8-9）下两个32位值分别是可执行代码的偏移值（‘BaseOfCode’，“代码基址”）和已初始化数据的偏移值（‘BaseOfData’，“数据基址”），两个都是RVA，并且两个对我们来说都没有多少意义，因为你可以通过查看可选头后面的各个“节”来获得更可靠的信息。未初始化的数据没有偏移量，正因为它没有初始化，所以在映象文件中提供这些数据是没有用处的。
11-12）下两个32位值分别是RAM中的“SectionAlignment”（当映象文件已被载入后，意为“节对齐”）和文件中的“FileAlignment”（文件对齐），它们都是PE文件的各节的对齐值。这两个值通常都是32，或者是：FileAlignment为512，SectionAlignment为4096。节会在以后讨论。
13-14）下2个16位word单元都是预期的操作系统版本信息（MajorOperatingSystemVersion,“操作系统主版本号”）和（MinorOperatingSystemVersion，“操作系统小版本号”）[它们都使用微软自己书面确定的名字]。这个版本信息应该为操作系统的版本号（如NT或Win95），而不是子系统的版本信息（如Win32）。版本信息常常被不提供或者错误提供。很明显的，加载器并不使用它们。
15-16）下2个16位word单元都是本二进制文件的版本信息('MajorImageVersion'“映象文件主版本号”和'MinorImageVersion'“映象文件小版本号”)。很多链接器不正确地设定这个信息，许多程序员也懒得提供这些，因此即便存在这样的信息，你最好也不要信赖它。
17-18）下2个16位word单元都是预期的子系统版本信息('MajorSubsystemVersion'“子系统主版本号”和'MinorSubsystemVersion'“子系统小版本号”)。此信息应该为Win32或POSIX的版本信息，因为很明显的，16位程序或OS/2程序都不是PE格式的。子系统版本应该被正确的提供，因为它“会”被检验和使用：如果一个应用程序是一个Win32-GUI应用程序并运行于NT4系统之上，而且子系统版本“不是”4.0的话，那么对话框就不会是以3D形式显示，并且一些其它的特征也只会按“老式”的方式工作，因为此应用程序预期是在NT3.51系统上运行的，而NT3.51系统上只有程序管理器而没有浏览器、等等，于是NT4.0系统就尽可能地仿照那个系统的行为来运行程序。
19）然后，我们便碰到32位的“Win32VersionValue”（Win32版本值）。我不清楚它有什么作用。在我所观察过的PE文件中，它全部都为0。
20）下一个是32位值，给出映象文件将要使用的内存数量，单位为字节（‘SizeOfImage’，“映象文件大小”）。如果是按照“SectionAlignment”对齐的，它就是所有头和节的长度的总和。它提示加载器，为了载入映象文件需要多少页。
21）下一个是32位值，给出所有头的总长度，包括数据目录和节头（‘SizeOfHeaders’，“头的大小”）。同时，它也是从文件的开头到第一节的原始数据的偏移量。
22）然后，我们发现一个32位的校验和（“CheckSum”）。这个校验和，对于当前的NT版本，只在映象文件是NT驱动程序时才校验（如果校验和不正确，驱动就将装载失败）。对于其他的二进制文件形式，校验和不需提供并且可能为0。计算校验和的算法是微软的私产，他们不会告诉你的。但是，Win32SDK的好几个工具都会计算和/或补正一个有效的校验和，而且imagehelp.dll中的CheckSumMappedFile()函数也会做同样的工作。使用校验和的目的是为了防止载入无论如何都会冲突的、已损坏的二进制文件----况且一个冲突的驱动程序会导致一个BSOD错误，因此最好根本就不载入这样的坏文件。
23）然后，就到了一个16位的word单元“Subsystem”（子系统），用来说明映象文件应运行于什么样的NT子系统之上：IMAGE_SUBSYSTEM_NATIVE(1)二进制文件不需要子系统。用于驱动程序。IMAGE_SUBSYSTEM_WINDOWS_GUI(2)映象文件是一个Win32二进制图象文件。（它还是能用AllocConsole()打开一个控制台界面，但在开始时却不能自动地打开。）IMAGE_SUBSYSTEM_WINDOWS_CUI(3)二进制文件是一个Win32控制台界面二进制文件。（它将在开始时按照缺省值打开一个控制台，或者继承其父程序的控制台。）
IMAGE_SUBSYSTEM_OS2_CUI(5)二进制文件是一个OS/2控制台界面二进制文件。（OS/2控制台界面二进制文件是OS/2格式，因此此值在PE文件中很少使用。）
IMAGE_SUBSYSTEM_POSIX_CUI(7)二进制文件使用POSIX控制台子系统。
Windows95的二进制文件总是使用Win32子系统，因此它的二进制文件的合法值只有2和3；我不知道windows95的“原”二进制文件是否可能（会有其它值----译者添加，仅供参考）。
24）下一个是16位的值，指明，如果是DLL文件，何时调用DLL文件的入口点（‘DllCharacteristics’，“DLL特性”）。此值似乎不用；很明显地，DLL文件总是被通报所有的情况。如果位0被置1，DLL文件被通知进程附加（亦即DLL载入）。如果位1被置1，DLL文件被通知线程附加（亦即线程终止）。如果位2被置1，DLL文件被通知线程附加（亦即线程创建）。如果位3被置1，DLL文件被通知进程附加（亦即DLL卸载）。
25-28）下4个32位值分别是：保留栈的大小（SizeOfStackReserve）、初始时指定栈大小（SizeOfStackCommit）、保留堆的大小（SizeOfHeapReserve）和指定堆大小（SizeOfHeapCommit）。“保留的”数量是保留给特定目的的地址空间（不是真正的RAM）；在程序开始时，“指定的”数量是指在RAM中实际分配的大小。如果需要的话，“指定的”值也是指定的堆或栈用来增加的数量。（有资料说，不管“SizeOfStackCommit”的值是多少，栈都是按页增加的。我没有验证过。）因此，举例来说，如一个程序的保留堆有1MB，指定堆为64KB,那么启动时堆的大小为64KB,并且保证可以扩大到1MB。堆将按64KB一块来增加。“堆”在本文中是指主要（缺省）堆。如果它愿意的话，一个进程可创建很多堆。栈是指第一个线程的栈（启动main()的那个）。进程可以创建很多线程，每个线程都有自己的栈。DLL文件没有自己的堆或栈，所以它们的映象文件忽略这些值。我不知道驱动程序是否有它们自己的堆或栈，但我认为它们没有。
29）堆和栈的这些描述之后，我们就发现一个32位的“LoaderFlags（加载器标志）”，我没有找到它的任何有用的描述。我只发现一篇时新的关于设置此标志位的短文，说设置此标志位会在映象文件载入后自动地调用一个断点或者调试器；可似乎不正确。
30）接着我们会发现32位的“NumberOfRvaAndSizes（Rva数和大小）”，它是紧随其后的目录的有效项的数目。我已发现此值不可靠；你也许希望用常量IMAGE_NUMBEROF_DIRECTORY_ENTRIES（映象文件目录项数目）来代替它，或者用它们中的较小者。
NumberOfRvaAndSizes之后是一个IMAGE_NUMBEROF_DIRECTORY_ENTRIES(16)（映象文件目录项数目）个IMAGE_DATA_DIRECTORY（映象文件数据目录）数组。这些目录中的每一个目录都描述了一个特定的、位于目录项后面的某一节中的信息的位置（32位的RVA，叫“VirtualAddress（虚拟地址）”）和大小（也是32位，叫“Size（大小）”）。例如，安全目录能在索引4中给定的RVA处发现并具有索引4中给定的大小。稍后我将讨论我知道其结构的目录。已定义的目录及索引有:
七、节目录（Sectiondirectories）---------------------------------
节由两个主要部分组成：首先，是一个节描述(IMAGE_SECTION_HEADER[意为“节头”]类型的)，然后是原始的节数据。因此，我们会在数据目录后发现一“NumberOfSections”个节头组成的数组，它们按照各节的RVA排序。
2）IMAGE_SECTION_HEADER（“节头”）的下一个成员是一个32位的、“PhysicalAddress（物理地址）”和“VirtualSize（虚拟大小）”组成的共用体。在目标文件中，它是内容重定位到的地址；在可执行文件中，它是内容的大小。事实上，此域似乎没被使用；因为有的链接器输入大小，有的链接器输入地址，我还发现有一个链接器输入0，而所有的可执行文件都运行如风。
3）下一个成员是“VirtualAddress（虚拟地址）”，是一个32位的值，用来保存载入RAM（内存）后，节中数据的RVA。
4）然后，我们到了32位的“SizeOfRawData”（意味“原始数据大小”），它表示节中数据被大约到下一个“FileAlignment”的整数倍时节的大小。
5）下一个是“PointerToRawData”（意味“原始数据指针”，32位），它特别有用，因为它是从文件的开头到节中数据的偏移量。如果它为0，那么节的数据就不包含在文件中，并且要在载入时才定。
6-9）然后，我们得到“PointerToRelocations”（意味“重定位指针”，32位）和“PointerToLinenumbers”（意味“行数指针”，也是32位），以及“NumberOfRelocations”（意味“重定位数”，16位）和“NumberOfLinenumbers”（意味“行数数”，也是16位）。所以这些都是只用于目标文件的信息。可执行文件拥有一个特殊的基址重定位目录，并且行数信息（如果真的存在的话）通常包含在有一个特殊目的的调试段中或者别的什么地方。
10）节头的最后一个成员是32位的“Characteristics”（意味“特性”），它是一串描述节的内存如何被处理的标志：
如果位5IMAGE_SCN_CNT_CODE（含有代码的节)被置1，表示节中包含可执行代码。如果位6IMAGE_SCN_CNT_INITIALIZED_DATA（含有初始化数据的节)被置1，表示节中包含执行开始前即取得已定义值的数据。换言之：文件中节的数据就是有意义的。如果位7IMAGE_SCN_CNT_UNINITIALIZED_DATA（含有未初始化数据的节)被置1，表示节中包含未初始化数据，并需于执行开始前被初始化为全0。这通常是BSS节。
如果位9IMAGE_SCN_LNK_INFO（链接器信息节)被置1，表示节中不包含映象数据，只有一些注释、描述或者其他的文档。这些信息是目标文件的一部分，并有可能是提供给链接器的信息，比如需要哪些库文件。
如果位11IMAGE_SCN_LNK_REMOVE（链接可删除节)被置1，表示数据是目标文件的、被预定于可执行文件被链接后丢弃掉的节的一部分。常和位9连用。
如果位12IMAGE_SCN_LNK_COMDAT（链接通用块节)被置1，表示节中包含“commonblockdata”（通用块数据），也即某种形式的打包函数。
如果位15IMAGE_SCN_MEM_FARDATA（内存远程数据节)被置1，表示我们拥有远程数据----意味着什么。此位的含义不明。
如果位17IMAGE_SCN_MEM_PURGEABLE（内存可清除节)被置1，表示节中的数据可清除----但我认为它和“可丢弃”不是一回事，可丢弃拥有自己的标志位，参见后面。同样，它也明显的不是用来指示16位信息的，因为它也有一个IMAGE_SCN_MEM_16BIT定义。此位的含义不明。
如果位18IMAGE_SCN_MEM_LOCKED（内存被锁节)被置1，表示节不应该被从内存中移除？抑或表明没有重定位信息？此位的含义不明。
如果位19IMAGE_SCN_MEM_PRELOAD（内存预载入节)被置1，表示节在执行开始前应该被页载入？此位的含义不明。
位20至23指定我没有找到信息的对齐。诸如#definesIMAGE_SCN_ALIGN_16BYTES之类。我曾经见过的唯一值为0，是16位的缺省对齐。我怀疑它们是库之类文件的目标对齐。
如果位24IMAGE_SCN_LNK_NRELOC_OVFL（链接扩展重定位节)被置1，表示节中包含一些我不知道的扩展重定位。
如果位25IMAGE_SCN_MEM_DISCARDABLE（内存可丢弃节)被置1，表示节中的数据在进程启动后就不需要了。它是，举例来说，含有重定位信息的情况。我曾经见过它也用于只执行一次的驱动和服务程序的启动例程，还用于输入目录。
如果位26IMAGE_SCN_MEM_NOT_CACHED（内存不缓存节)被置1，表示节中的数据不应该被缓存。不要问我为什么不。这是不是意味着关掉2级缓存？
如果位27IMAGE_SCN_MEM_NOT_PAGED（内存不可页换出节)被置1，表示节中的数据不应该页换出。它对驱动程序有意义。
如果位28IMAGE_SCN_MEM_SHARED（内存共享节)被置1，表示节中的数据在映象文件的所有正在运行的实例中共享。如果它是，例如DLL文件的未初始化数据，那么DLL的所有正在运行的实例程序在任何时候都将拥有相同的变量内容。注意：只有第一个实例的节被初始化。含有代码的节总是被共享写时拷贝（copy-on-write）（亦即：如果重定位必不可少，那么共享就不工作）。（译注：“写时拷贝”的译法也许根本就是错误的，但我一时找不到更准确的翻译，也不清楚其具体含义，只能以此充数了。希望知情着指点。）
如果位29IMAGE_SCN_MEM_EXECUTE（内存可执行节)被置1，表示进程对节的内存有“执行”的存取权限。如果位30IMAGE_SCN_MEM_READ（内存可读节)被置1，表示进程对节的内存有“读”的存取权限。如果位31IMAGE_SCN_MEM_WRITE（内存可写节)被置1，表示进程对节的内存有“写”的存取权限。
在节头之后，我们就会发现节本身。在文件中，它们按照“FileAlignment”（文件对齐）的字节数对齐（也就是说，在可选头之后和每个节的数据之后将要填充一些字节）并按照它们的RVA排序。在载入后（内存中），它们按照“SectionAlignment”（节对齐）的字节数对齐。
试举一例，如果可选头在文件的偏移量981处结束，“FileAlignment”（文件对齐）的值为512，那么第一个节将于1024字节处开始。注意：你可通过“PointerToRawData”（原始数据指针）或者“VirtualAddress”（虚拟地址）的值来找到各节，因此实际上根本没必要在对齐上小题大做。
试画映象文件的全图如下：
+-------------------+|DOS-根|+-------------------+|文件头|+-------------------+|可选头||----------|||----------------+|数据目录||||||(指向节中|-------------+||目录的RVA)|||||---------+|||||||+-------------------+|||||-----+||||节头||||||(指向节|--+|||||边界的RVA)||||||+-------------------+<-+|||||||<-+|||节数据1|||||||<-----+|+-------------------+<----+|||||节数据2||||<--------------++-------------------+
每个节都有一个节头，并且每个数据目录都会指向其中的一个节（几个数据目录有可能指向同一个节，而且也可能有的节没有数据目录指向它们）。
八、节的原始数据（Sections'rawdata）--------------------------------------
根据节中包含的内容，可分为好几种节。大多数（并非所有）情况下，节中至少由一个数据目录，并在可选头的数据目录数组中有一个指针指向它。
2.代码节（codesection）------------------------首先，我将提到代码节。此节，至少，要将“IMAGE_SCN_CNT_CODE”（含有代码节）、“IMAGE_SCN_MEM_EXECUTE”（内存可执行节）和“IMAGE_SCN_MEM_READ”（内存可读节）等标志位设为1，并且“AddressOfEntryPoint”（入口点地址）将指向节中的某个地方，指向开发者希望首先执行的那个函数的开始处。“BaseOfCode”（代码基址）通常指向这一节的开始处，但是，如果一些非代码字节被放在代码之前的话，它也可能指向节中靠后的某个地方。通常，除了可执行代码外，本节没有别的东东，并且通常只有一个代码节，但是不要太迷信这一点。典型的节名有“.text”、“.code”、“AUTO”之类。
3.数据节（datasection）------------------------我们要讨论的下一件事情就是已初始化变量；本节包含的是已初始化的静态变量（象“staticinti=5;”）。它将，至少，使“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）、“IMAGE_SCN_MEM_READ”（内存可读节）和“IMAGE_SCN_MEM_WRITE”（内存可写节）等标志位被置为1。一些链接器可能会将常量放在没有可写标志位的它们自己的节中。如果有一部分数据可共享，或者有其它的特定情况，那么可能会有更多的节，且它们的合适的标志位会被设置。不管是一节，还是多节，它们都将处于从“BaseOfData”（数据基址）到“BaseOfData”+“SizeOfInitializedData”（数据基址+已初始化数据的大小）的范围之内。典型的名称有“.data”、“.idata”、“DATA”、等等。
4.BSS节（bsssection）----------------------其后就是未初始化的数据（一些象“staticintk;”之类的静态变量）；本节十分象已初始化的数据，但它的“PointerToRawData”（文件偏移量）却为0，表明它的内容不存储在文件中；并且“IMAGE_SCN_CNT_UNINITIALIZED_DATA”（含有未初始化数据节）而不是“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）标志位被置为1，表明在载入时它的内容应该被置为0。这就意味着，在文件中只有节头，没有节身；节身将由加载器创建，并全部为0字节。它的长度由“SizeOfUninitializedData”（未初始化数据大小）确定。典型的名称有“.bss”、“BSS”之类。
有些节数据“没有”被数据目录指向。它们的内容和结构是由编译器而不是链接器提供。（栈段和堆段不是二进制文件中的节，它们是由加载器根据可选头中的栈大小和堆大小项来创建的。）
6.输出符号（exportedsymbols）------------------------------（注意：本文的1993年03月12日之前的各个版本中，输出目录的描述有误。文中没有描述中转、只以序数输出、或者使用好几个名称输出等内容。）
下一件最简单的事情是输出目录，是由“IMAGE_DIRECTORY_ENTRY_EXPORT”（输出目录项）指向的。它是一个典型的在DLL中常见到的目录；包含一些输出函数的入口点（以及输出对象等的地址）。当然可执行文件也可能拥有输出符号但一般没有。包含它们的节应该有“已初始化数据的”和“可读的”特性。这样的节应该是不可丢弃的，因为在运行时，进程有可能调用“GetProcAddress()”来寻找一个函数的入口点。如果单独成节的话，本节通常被称作“.edata”；更常见的是，它被并入象“已初始化数据”之类的节中。
输出表（“IMAGE_EXPORT_DIRECTORY”）的结构由一个头和输出数据，也就是：符号名称、它们的序号和它们的入口点偏移量等构成。
1）首先，我们有一个没被使用并通常为0的、32位的“Characteristics”（特性）。
3-4）往后我们看到2个16位的、有关版本信息的word单元（“MajorVersion”和“MinorVersion”，含义分别为‘主版本号’和‘小版本号’），同样，它们很多地被设为0。
5）下一个东东是32位的“Name”（名称）；它是一个指向以0结尾的ASCII字符串为DLL名称的RVA。（为防DLL被改名时的错误，名称是必须的----参见输入目录中的“绑定”部分。）
6）然后是32位的“Base”（基址）。稍后我们再讨论。
8）下一个32位值“AddressOfFunctions”（函数地址）是指向输出条目列表的RVA。它指向一个32位值的“NumberOfFunctions”（函数数）数组，数组的每一项都是一个指向输出函数或变量的RVA。
关于此列表有两个怪事：第一，这样一个输出的RVA竟可能会为0，在此情况下，此值没被使用。第二，如果一RVA指向含有输出目录的节，那么它就是一个中转输出。一个中转输出就是指指向另一个二进制文件中的输出项的指针；如果使用了它，就可用另一个二进制文件中的被指向的输出项来代替使用。此时的RVA指向，正如已提到的，输出目录的节中，指向一个以以零结尾的字符串组成的、被指向的DLL的名称和一个用点分开的输出项的名称，象“otherdll.exportname”这样，或者是DLL的名称和输出序数，象“otherdll.#19”这样。
现在到了解释输出序数的时候了。一个输出项的序数就是函数地址数组中的索引值加上上面提到的“Base”（基址）的值的和。在大多数情况下，“Base”（基址）的值为1，这就意味着第一个输出项的序数为1，第二个输出项的序数为2，以此类推。
9-10）“AddressOfFunctions”（函数地址）RVA之后，我们发现二个RVA，一个指向符号名称的32位RVA的数组“AddressOfNames”（名字的地址），另一个指向16位序数“AddressOfNameOrdinals”（名字序数的地址）的数组。两个数组都有“NumberOfNames”（名字数）个元素。符号名称可能会全部丢失，此时“AddressOfNames”（名字的地址）为0；否则，被指向的数组并行运行，这意味着它们的每个索引中的元素共同拥有。“AddressOfNames”（名字的地址）数组由以0结尾的输出名称的RVA组成；这些名称以一个分类的列表排列（即：数组的第一个成员是按照字母顺序排列的最小的名称的RVA；这使当按名称查找一个输出符号时，搜索的效率更高。）根据PE规范，“AddressOfNameOrdinals”（名字序数的地址）数组每个名称拥有一个相应的序数，然而，我发现这个数组却将实际的索引包含到“AddressOfFunctions”（函数地址）数组中去。
我将画一个有关这三个表的图：
函数地址|||v带序数‘基址’的输出RVA带序数‘基址+1’的输出RVA...带序数‘基址+函数数-1’的输出RVA
名字地址名字序数地址||||||vv第一个名字的RVA<->第一个名字的输出索引第二个名字的RVA<->第二个名字的输出索引......第‘名字数’个名字的RVA<->第‘名字数’个名字的输出索引
举一些例子是适宜的。
为按序数找到一个输出符号，先减去“Base”（基址）值以得到索引值，再根据“AddressOfFunctions”（函数地址）的RVA得到输出项数组，并用索引值去找到数组中的输出RVA。如果结果没有指向输出节中，你就完了。否则，它就指向那里的一个描述输出DLL和（输出项）名称或序数的字符串，之后你就得在那里查找中转输出。
为按名称找到一个输出符号，先跟随“AddressOfNames”（名字的地址）的RVA（如果是0就没有名称）找到输出名称的RVA数组。在列表中搜寻你要找的名称。用该名称在“AddressOfNameOrdinals”（名字序数的地址）数组中的索引，得到和找到的名称相应的16位数字。根据PE规范，这是一个序数，你需先减去“Base”（基址）值以得到输出索引值；但依据我的经验，这就是输出索引值，你不需要再减了。使用输出索引值，你就能在“AddressOfFunctions”（函数地址）数组中找到输出RVA了，要么是输出RVA本身，要么是一个描述中转输出的字符串的RVA。
7.输入符号（importedsymbols）------------------------------
当编译器发现一个对别的可执行文件（大多数是DLL文件）中的函数调用时，在最简单化的情况下，它会对此情况一无所知，只是简单地输出一个对那个符号的正常调用指令。链接器不得不修正那个符号的地址，就象它为任何其它的外部符号所做的那样。链接器使用一个输入库来查找从哪个DLL文件输入了哪个符号，并为所有的输入符号都建立存根，每个存根包含一个跳转指令；存根就是实际的调用目标。这些跳转指令实际上将跳往从所谓的输入地址表中提取的一个地址。在更复杂的应用程序（使用“__declspec(dllimport)”时）中，编译器会知道函数是输入的，并直接输出一个位于输入地址表中的地址的调用，绕过跳转。
不管怎样，DLL文件中的函数地址总是必要的，并将于应用程序载入时，由加载器从输出DLL文件的输出目录中提供。加载器知道哪个库中的哪些符号需要被查找以及哪些地址需要通过搜索输入目录来修正。
我最好给你一个例子。有或无__declspec(dllimport)的调用如下所示：
源文件：intsymbol(char*);__declspec(dllimport)intsymbol2(char*);voidfoo(void){inti=symbol("bar");intj=symbol2("baz");}
汇编：...call_symbol;没有declspec(dllimport)的...call[__imp__symbol2];含有declspec(dllimport)的...
在第一种（没有__declspec(dllimport)）情况下，编译器不知道“_symbol”位于一个DLL文件中，因此链接器必须要提供“_symbol”函数。因为此函数不存在，它就为输入符号提供一个存根函数，即一个间接跳转。所有输入存根的集合被称为“转移区”（有时也叫做“跳板”，因为你跳到那里的目的是为了跳到别的地方）。
典型地，此转移区位于代码节中（它不是输入目录的一部分）。每一个函数存根都是一个跳往DLL文件中的实际函数的跳转。转移区的形式象这样：
_symbol:jmp[__imp__symbol]_other_symbol:jmp[__imp__other__symbol]...
这意味着：如果你不指定“__declspec(dllimport)”来使用输入符号，那么链接器将会为它们产生一个由间接跳转所组成的转移区。如果你真指定了“__declspec(dllimport)”，那么编译器就会自己做间接（跳转），转移区也就不需要了。（这也意味着：如果你输入的是变量或其它东西，你就必须指定“__declspec(dllimport)”，因为一个具有jmp指令的存根只合适于函数。）
不管怎样，符号“x”的地址都被存在“__imp_x”的存储单元。所有这样的存储单元一起形成所谓的“输入地址表”，此表是由被用到的各DLL文件中的输入库提供给链接器的。输入地址表就是由下面这种形式的一组地址组成的：
__imp__symbol:0xdeadbeef__imp__symbol2:0x40100__imp__symbol3:0x300100...
这个输入地址表是输入目录的一部分，并且被IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录指针所指向（尽管有些链接器不设置此目录项，程序也能运行；很明显地，这是因为加载器不使用IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录也能解决输入问题）。这些地址并不被链接器所知；链接器只插入一些伪地址（函数名称的RVA；参见后面的更多信息），这些伪地址会在载入时被加载器用输出DLL文件中的输出目录来修正。输入地址表，以及它是怎样被加载器找到的，将会在本章的后面被详细讲述。
这就是程序的代码如何使用输入函数的；现在我们再来看看输入目录是如何建立以便加载器使用的。
输入目录应该存在于是“已初始化数据”并且“可读”的节中。输入目录是一个多IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的数组，每个被使用的DLL文件都有一个。（它们的）列表由一个全部用0填充的IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）结构作为结束。一个IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）是一个拥有下列成员的结构体：
OriginalFirstThunk（原始第一个换长）（汉译的说明见注释）它是一个RVA（32位），指向一个以0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组永不改变。
ForwarderChain（中转链）它是输入函数列表中第一个中转的、32位的索引。中转也是高级的东东。对初学者先将所有位设为-1。Name（名称）它是一个DLL文件的名称（0结尾的ASCII码字符串）的、32位的RVA。FirstThunk（第一换长）它也是一个RVA（32位），指向一个0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组是输入地址表的一部分，并且可以改变。
没有必要失望，我将再画一图。这里是IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的关键内容：
原始第一个换长第一个换长||||||VV
0-->函数1<--01-->函数2<--12-->函数3<--23-->foo<--34-->mumpitz<--45-->knuff<--56-->00<--6/*最后的RVA是0!*/
图当中的名字就是尚未讨论的IMAGE_IMPORT_BY_NAME（输入名字）。每一个都是一个16位的数字（一个提示）跟着一些数量未定的字节，它们都是以0结尾的、输入符号的ASCII码名字。提示就是指向输出DLL文件名字表的索引（参见上面的输出目录）。那个索引中的名字将被一一尝试，如果没有相符的，再使用二进制搜索来寻找名字。（有些链接器不愿意查找正确的提示，总是只简单的将其指定为1，或者其它的随意数字。这并无大害，只是使解决名字的第一次尝试总是失败，并迫使每个名字都使用二进制搜索来进行。）
总结一下：如果你想从“knurr”DLL中查找输入函数“foo”的信息，第一步你先找到数据目录中的IMAGE_DIRECTORY_ENTRY_IMPORT（输入目录项）项，得到一个RVA，再在原始节数据中找到那个地址，现在你就得到一个IMAGE_IMPORT_DESCRIPTOR（输入描述结构）数组了。通过查看根据它们的“名称”被指向的字符串，得到和“knurr”DLL有关的这个数组的成员（即一个输入描述结构）。在你找到正确的IMAGE_IMPORT_DESCRIPTOR（输入描述结构）后，顺着它的“OriginalFirstThunk”（原始第一个换长）得到被指向的IMAGE_THUNK_DATA（换长数据）数组；再通过查询RVA找到“foo”函数。
现在输入已经被用正确的线性地址修正，如下所示：
0-->函数10-->输出函数11-->函数21-->输出函数22-->函数32-->输出函数33-->foo3-->输出函数foo4-->mumpitz4-->输出函数mumpitz5-->knuff5-->输出函数knuff6-->00<--6
这是简单情况下的基本结构。现在我们将要学习输入目录中的需细讲的东西。
第一，当数组中IMAGE_THUNK_DATA元（换长数据）素的IMAGE_ORDINAL_FLAG（序数标志）位（也是：MSB，参见注释）被置1时，表示列表中没有符号的名字信息，符号只以序数输入。你可通过查看IMAGE_THUNK_DATA（换长数据）中的低地址word来得到序数。通过序数输入是不鼓励的，通过名字输入会更安全，因为如果输出DLL文件不是预期的版本时输出序数可能会改变。
第二，有所谓的“绑定输入”。
请思考一下加载器的工作：当它想执行的一个二进制文件需要一个DLL中的函数时，加载器会载入该DLL，找到它的输出目录，查找函数的RVA并计算函数的入口点。然后用这样找到的地址修正“FirstThunk”（第一个换长）列表。假设程序员很聪明，给DLL文件提供的唯一优先载入地址不会发生冲突，那么我们就能认为函数的入口点将总是相同的。它们在链接时能被算出并被补进“FirstThunk”（第一个换长）列表中，这就是“绑定输入”所发生的一切。（“绑定”工具就是干这个的，它是Win32SDK的一部分。）
当然，你得慎重：用户的DLL可能是不同的版本，或者DLL必须重定位，这些都会使先前修正的“FirstThunk”（第一个换长）列表不再有效；此时，加载器仍能查寻“OriginalFirstThunk”（原始第一个换长）列表，找出输入符号并重新补正“FirstThunk”（第一个换长）列表。加载器知道这是必须的，当：1）输出DLL文件的版本不符，或2）输出DLL文件需要重定位时。
这一点可通过“ForwarderChain”（中转链）来做到。它是一个指向换长列表中的索引值；被索引位置的输入就是一个中转输出，并且此位置的“FirstThunk”（第一个换长）列表中的内容就是“下一个”中转输入的索引值，以此类推，直到索引值为-1，就表明已没有其他的中转了。如果根本就没有中转，那么“ForwarderChain”（中转链）的值本身就为-1。
这就是所谓的“老式”绑定。
至此，我们应该总结一下我们目前已掌握的情况:-)
还有一件我到现在都没有提及的事情：明显地有些链接器在构建输入目录时会产生bug（我就发现一个还在被一个BorlandC链接器使用的bug）。这些链接器把IMAGE_IMPORT_DESCRIPTOR（输入描述结构）中的“OriginalFirstThunk”（原始第一个换长）设为0，并只建立“FirstThunk”（第一个换长）。很明显的，这样的输入目录不能被绑定（否则重修输入的必须信息就会丢失----你根本找不到函数名字）。在这种情况下，你得根据“FirstThunk”（第一个换长）数组来取得输入符号名字，你将永远得不到预先补正的入口地址。我已发现一个TIS文件(参考书目[6])，讲述一个在某种程度上和此bug兼容的输入目录，因此那个文件可能就是该bug的起源。
跟在“IMAGE_BOUND_FORWARDER_REF（绑定中转参考）”后的是下一个“IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构）”，以此类推；列表最终以一个全部为0位的IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构）结束。
我对由此（描述）造成的不便表示歉意，但这就是它看起来的样子:-）
8.资源（resources）-------------------资源，比如对话框、菜单、图标等等，都存储在IMAGE_DIRECTORY_ENTRY_RESOURCE（“资源目录项”）指向的数据目录中。它们处于一个至少“IMAGE_SCN_CNT_INITIALIZED_DATA（已初始化数据内容节）”和“IMAGE_SCN_MEM_READ（内存可读节）”标志位都被置为1的节中。
资源的基础是“资源目录”（IMAGE_RESOURCE_DIRECTORY）；它包含好几个“资源目录项”（IMAGE_RESOURCE_DIRECTORY_ENTRY），其中的每一项反过来又可能指向一个“资源目录”。按照这种方式，你就得到一个以“资源目录项”为树叶的“资源目录”树；它们的树叶指向实际的资源数据。
在实际使用中，情况会稍微简单些。一般你不会遇到不可能理清的特别复杂的树的。通常，它的层次结构是这样的：一个目录作为根。它指向很多目录，每种资源类型都有一个。这些目录又指向子目录，每个子目录都有一个名字或者ID号并指向这个资源所提供的各种语言的目录；每种语言你都能找到一个资源项，资源项最终指向（具体的）数据。（注意：多语言资源不能在Win95上运行。即使程序有好几种语言，Win95也总是使用相同的资源----我没有查出是哪一种，但我猜测肯定是它最先碰到的那种。多语言资源在NT系统上可以运行。）
没有指针的树大致象这样：
(根)|+----------------+------------------+|||菜单对话框图标|||+-----+-----++-+----++-+----+----+|||||||"main""popup"0x10"maindlg"0x1000x1100x120|||||||+---+-+||||||||defaultenglishdefaultdef.def.def.germanenglish
紧随此结构后的是“已命名项目数”+“ID项目数”两结构体，它们都是“资源目录项”格式，都以名字开头。它们可能指向下一个“资源目录”或者指向实际的资源数据。
一个“资源目录项”由下面组成：32位单元提供你它所描述的资源的ID或者是目录；32位的到数据的偏移量或者是到下一个子目录的偏移量。
ID的含义取决于树中的层次；ID可能是一个数字（如果最高位为0）也可能是一个名字（如果最高位为1）。如果是一个名字，它的低31位就是从资源节原始数据的开始到这个名字（名字有16位长并由unicode的宽字符而不是0结尾符作为结束）的偏移量。
如果你位于根目录之中，且如果ID是一个数字的话，那么它指的就是下面的一种资源类型：1:光标2:位图3:图标4:菜单5:对话框6:字串表7:字体目录8:字体9:快捷键10:未格式化资源数据11:信息表12:组光标14:组图标16:版本信息任何其它数字都是用户自定义的。任何有类型名的资源类型也是用户自定义的。
要确定资源目录的下一层是不是另一个目录，你可查看它的偏移量的最高位。如果它是1，剩下的31位就是从资源节原始数据的开始到下一层目录的偏移量，还是按“资源目录”后接“资源目录项”的格式。如果高位为0，它就是从资源节原始数据的开始到资源的原始数据描述，即一个资源数据项的偏移量。资源的原始数据描述包含32位的“OffsetToData”（到数据的偏移量）（指的是到原始数据的偏移量，从资源节原始数据的开头算起），32位的数据的“Size”（大小），32位的“CodePage”（代码页）和一个未使用的32位单元。（不鼓励使用代码页，你应该使用“语言”的特性来支持多地域。）
原始数据格式依赖于资源类型；详细的介绍可在微软的SDK文档中找到。注意：除了用户自定义资源，资源中的任何字符串总是按UNICODE格式，明显的，用户自定义的资源按的是开发者选定的格式。
9.重定位（relocations）-----------------------我将要描述的最后一个数据目录是基址重定位目录。它是由可选头数据目录中的IMAGE_DIRECTORY_ENTRY_BASERELOC（基址重定位目录项）项来指向的。典型的，它包含在自己的节中，名字象“.reloc”这样，并且IMAGE_SCN_CNT_INITIALIZED_DATA（已初始化数据内容节）、IMAGE_SCN_MEM_DISCARDABLE（内存可丢弃节）和IMAGE_SCN_MEM_READ（内存可读节）等标志位被置1。
如果映象文件不能被加载到可选头中提到的优先载入地址“ImageBase”（映象基址）时，重定位数据对加载器来说就是必须的。此时，链接器所提供的固定地址就不再有效，并且加载器将不得不对静态变量、字符串文字等使用的绝对地址进行修正。
所谓重定位目录就是一些连续的块，每一块都包含4K映象文件的重定位信息。块由一个“IMAGE_BASE_RELOCATION（基址重定位）”结构体开始，这个结构体包含一个32位的“VirtualAddress（虚拟地址）”项和一个32位的“SizeOfBlock（块大小）”项。跟在它们后面的就是块的实际重定位数据，每一条都是16位的。“VirtualAddress（虚拟地址）”就是重定位所在块需要应用的基本的RVA；“SizeOfBlock（块大小）”就是整个块的字节大小；跟在后面的重定位的数目是：('SizeOfBlock'-sizeof(IMAGE_BASE_RELOCATION))/2个。当你碰到一个“VirtualAddress（虚拟地址）”值为0的“IMAGE_BASE_RELOCATION（基址重定位）”结构体时，重定位信息就结束了。
每一个16位的重定位信息由低12位的重定位位置和高4位的重定位类型组成。要得到重定位的RVA，你需要用这个12位的位置加上“IMAGE_BASE_RELOCATION（基址重定位）”中的“VirtualAddress（虚拟地址）”。类型是下面之一：
IMAGE_REL_BASED_ABSOLUTE(0)这种不需操作；用于将块按32位边界对齐。位置应该为0。IMAGE_REL_BASED_HIGH(1)重定位的高16位必须被用于被偏移量所指向的那个16位的WORD单元，此WORD是一个32位的DWORD的高位WORD。IMAGE_REL_BASED_LOW(2)重定位的低16位必须被用于被偏移量所指向的那个16位的WORD单元，此WORD是一个32位的DWORD的低位WORD。IMAGE_REL_BASED_HIGHLOW(3)重定位的全部32位必须应用于上面所说的全部32位。这种（和不需操作的第“0”种）是我在二进制文件种实际发现的仅有的重定位类型。IMAGE_REL_BASED_HIGHADJ(4)这是一种复杂的。请自己参阅（参考文献[6]），并努力弄懂它的意思：“高调整。这种修正要求一个全32位值。高16位定位于偏移量处，低16位定位在下一个数组元素（此数组元素包括在大小的域中）的偏移量处。它们两个需要被连成一个有符号的变量。加上32位的增量。然后加上0x8000并将有符号变量的高16位存储在偏移量处的16位域中。”IMAGE_REL_BASED_MIPS_JMPADDR(5)不清楚IMAGE_REL_BASED_SECTION(6)不清楚IMAGE_REL_BASED_REL32(7)不清楚
举一个例子，如果你发现重定位信息是0x00004000(32位,开始的RVA)0x00000010(32位,块的大小)0x3012(16位的重定位数据)0x3080(16位的重定位数据)0x30f6(16位的重定位数据)0x0000(16位的重定位数据)0x00000000(下一块的RVA)0xff341234你知道第一块描述的重定位开始于RVA0x4000处，有16字节长。因为头用掉了8字节，并且一个重定位要用2字节，所以块中计有(16-8)/2=4个重定位。第一个重定位被应用于0x4012处的DWORD，第二个于0x4080处的DWORD，第三个于0x40f6处的DWORD。最后一个不需操作。下一块的RVA是0，列表结束。
好，你怎么处理一个重定位呢？你能知道映象文件“被”重定位到可选头“ImageBase（映象基址）”的优先载入地址；你也能知道你真正载入的地址。如果它们相同，你什么也不用做。如果它们不同，你需计算出实际基址-优先基址的差并加上重定位位置的值（有符号，可能为负值），此值你可通过上面讲述的方法找到。
九、致谢（Acknowledgments）---------------------------感谢DavidBinette的调试和校读。（剩下的错误全部都是我的。）也感谢wotsit.org网站让我将此文放到他们的网站上。
十二、版本（Versions）----------------------你可在文件的顶部找到当前的版本号。
1998-04-06第一次公开发表
1998-07-29将映象文件版本和子系统版本中错误的“byte”改为“word”更正“栈只限于1MB”的错误（实际上没有上限）更正一些输入错误
1999-03-15更正输出目录的描述，原来非常不全调整输入目录的描述，原来讲的不清更正输入错误并为其它节改了一些词句
十三、参考文献（Literature）----------------------------[1]"PeeringInsidethePE:ATouroftheWin32PortableExecutableFileFormat"(M.Pietrek),in:MicrosoftSystemsJournal3/1994
[2]"WhytoUse_declspec(dllimport)&_declspec(dllexport)InCode",MSKnowledgeBaseQ132044
[3]《Windows问与答》"WindowsQ&A"(M.Pietrek),in:MicrosoftSystemsJournal8/1995
[4]《编写多语言资源》"WritingMultiple-LanguageResources",MSKnowledgeBaseQ89866
[5]"ThePortableExecutableFileFormatfromToptoBottom"(RandyKath),in:MicrosoftDeveloperNetwork
[6]《Windows下TIS格式规范1.0版》ToolInterfaceStandard(TIS)FormatsSpecificationforWindowsVersion1.0(IntelOrderNumber241597,IntelCorporation1993)
附录（Appendix:helloworld）：-------------------------------在这个附录中我将给大家展示一下怎样手工建立一个程序。因为我不会DECAlpha的，本例将使用Intel汇编语言。
本程序相当于
#include
首先，我使用Win32函数来翻译它以取代C运行时库：
#defineSTD_OUTPUT_HANDLE-11UL#definehello"hello,world\n"
__declspec(dllimport)unsignedlong__stdcallGetStdHandle(unsignedlonghdl);
__declspec(dllimport)unsignedlong__stdcallWriteConsoleA(unsignedlonghConsoleOutput,constvoid*buffer,unsignedlongchrs,unsignedlong*written,unsignedlongunused);
staticunsignedlongwritten;
voidstartup(void){WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE),hello,sizeof(hello)-1,&written,0);return;}
现在我将笨拙的将它汇编出来：startup:;WriteConsole()的参数,反向的6A00push0x0000000068pushoffset_written6A0Dpush0x0000000d68pushoffsethello;GetStdHandle()的参数6AF5push0xfffffff52EFF15calldwordptrcs:__imp__GetStdHandle@4;结果是WriteConsole()的参数50pusheax2EFF15calldwordptrcs:__imp__WriteConsoleA@20C3ret
hello:68656C6C6F2C20776F726C640A"hello,world\n"_written:00000000
以上就是编译的部分。任何人都能做到这点。从现在起让我们扮演起链接器的角色，这会非常有趣:-)
我需要先找出函数WriteConsoleA()和GetStdHandle()。碰巧它们都在“kernel32.dll”中。（这是“输入库”部分。）
现在我开始做可执行文件。问号代表待定的值；它们将在以后被修正。
首先是DOS-根，开始于0x0，有0x40字节长：00|4d5a000000000000000000000000000010|0000000000000000000000000000000020|0000000000000000000000000000000030|00000000000000000000000040000000正如你所见到的，这不是真正的MS-DOS程序。它只是一个开始部分有“MZ”签名的头和紧跟在头后面的e_lfanew指针，没有任何代码。这是因为它并非打算运行于MS-DOS之上；它之所以在这里只是因为规范的需要。
然后是PE签名，开始于0x40，有0x4字节长：50450000
现在到了文件头，开始于0x44，有0x14字节长：Machine4c01;i386NumberOfSections0200;代码段和数据段TimeDateStamp00000000;谁管它？PointerToSymbolTable00000000;未用NumberOfSymbols00000000;未用SizeOfOptionalHeadere000;常量Characteristics0201;32位机器上的可执行文件
接着是可选头，开始于0x58，有0x60字节长：Magic0b01;常量MajorLinkerVersion00;我是0.0版:-)MinorLinkerVersion00;SizeOfCode20000000;32字节代码SizeOfInitializedData;待找出SizeOfUninitializedData00000000;我们没有BSS节AddressOfEntryPoint;待定BaseOfCode;待定BaseOfData;待定ImageBase00001000;1MB,随意选SectionAlignment20000000;32字节对齐FileAlignment20000000;32字节对齐MajorOperatingSystemVersion0400;NT4.0MinorOperatingSystemVersion0000;MajorImageVersion0000;0.0版MinorImageVersion0000;MajorSubsystemVersion0400;Win324.0MinorSubsystemVersion0000;Win32VersionValue00000000;未使用SizeOfImage;待定SizeOfHeaders;待定CheckSum00000000;非驱动不用Subsystem0300;Win32控制台DllCharacteristics0000;未用(不是一个DLL)SizeOfStackReserve00001000;1MB栈SizeOfStackCommit00100000;开始时4KBSizeOfHeapReserve00001000;1MB堆SizeOfHeapCommit00100000;开始时4KBLoaderFlags00000000;未知NumberOfRvaAndSizes10000000;常量
正如你所见，我计划只用2个节，一个用于代码，一个用于所有剩余的东西（数据、常量和输入目录等）。没有重定位和象资源之类其它东西。我也不用BSS节并将变量“written”放入已初始化数据。文件和RAM中的节对齐都是一样的（32字节）；这将有助于使任务简单，否则我就得来回地计算RVA很多次。
现在我们设置数据目录，开始于0xb8字节，有0x80字节长:地址大小0000000000000000;IMAGE_DIRECTORY_ENTRY_EXPORT(0);IMAGE_DIRECTORY_ENTRY_IMPORT(1)0000000000000000;IMAGE_DIRECTORY_ENTRY_RESOURCE(2)0000000000000000;IMAGE_DIRECTORY_ENTRY_EXCEPTION(3)0000000000000000;IMAGE_DIRECTORY_ENTRY_SECURITY(4)0000000000000000;IMAGE_DIRECTORY_ENTRY_BASERELOC(5)0000000000000000;IMAGE_DIRECTORY_ENTRY_DEBUG(6)0000000000000000;IMAGE_DIRECTORY_ENTRY_COPYRIGHT(7)0000000000000000;IMAGE_DIRECTORY_ENTRY_GLOBALPTR(8)0000000000000000;IMAGE_DIRECTORY_ENTRY_TLS(9)0000000000000000;IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG(10)0000000000000000;IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(11)0000000000000000;IMAGE_DIRECTORY_ENTRY_IAT(12)0000000000000000;130000000000000000;140000000000000000;15仅使用输入目录。
下一个使节头。首先我们做代码节的，代码节将包含前面所编的汇编语句。它有32字节长，所以代码节也就是这么长。节头从0x138处开始，有0x28字节长：
Name2e636f6465000000;".code"的ASCII码值VirtualSize00000000;未用VirtualAddress;待定SizeOfRawData20000000;代码的大小PointerToRawData;待定PointerToRelocations00000000;未用PointerToLinenumbers00000000;未用NumberOfRelocations0000;未用NumberOfLinenumbers0000;未用Characteristics20000060;代码节，可执行，可读
第二节将包含数据。节头开始于0x160处，有0x28字节长：
Name2e64617461000000;".data"的ASCII码值VirtualSize00000000;未用VirtualAddress;待定SizeOfRawData;待定PointerToRawData;待定PointerToRelocations00000000;未用PointerToLinenumbers00000000;未用NumberOfRelocations0000;未用NumberOfLinenumbers0000;未用Characteristics400000c0;已初始化的，可读，可写
下一个字节位于0x188处，但节需要按32字节（的倍数）对齐（因为我是这样选择的），所以我们需要添一些（0）字节直到0x1a0处：
000000000000;填充的000000000000000000000000000000000000
现在第一节，就是上面所汇编的代码节，“到”了。它开始于0x1a0处，有0x20字节长：6A00;push0x0000000068;pushoffset_written6A0D;push0x0000000d68;pushoffsethello_string6AF5;push0xfffffff52EFF15;calldwordptrcs:__imp__GetStdHandle@450;pusheax2EFF15;calldwordptrcs:__imp__WriteConsoleA@20C3;ret
因为这一节的长度（刚好32字节），在下一节（数据节）前我们不需要填充任何字节。下一节到了，从0x1c0处开始：
68656C6C6F2C20776F726C640A;"hello,world\n"的ASCII码值000000;填充几个0以和_written对齐00000000;_written
现在剩下的只有输入目录了。本文件将从"kernel32.dll"库中输入2个函数，输入目录将从本节的变量后面立即开始。首先我们先将上面的数据按32字节对齐：
000000000000000000000000;填充的
在0x1e0处开始输入描述（IMAGE_IMPORT_DESCRIPTOR）:OriginalFirstThunk;待定TimeDateStamp00000000;未绑定ForwarderChainffffffff;无中转Name;待定FirstThunk;待定
我们需要用一个0字节项来结束输入目录（我们现在位于0x1f4):OriginalFirstThunk00000000;结束符号TimeDateStamp00000000;ForwarderChain00000000;Name00000000;FirstThunk00000000;
现在只剩下DLL名字，还有2个换长，以及换长数据和函数名字了。但现在我们真的很快就要完成了。
DLL名字，以0结尾，开始于0x208处:6b65726e656c33322e646c6c00;"kernel32.dll"的ASCII码值000000;填充到32位边界
原始第一个换长，开始于0x218处:AddressOfData;"WriteConsoleA"函数名的RVAAddressOfData;"GetStdHandle"函数名的RVA00000000;结束符号
现在剩下的只有输入名字（IMAGE_IMPORT_BY_NAME）形式的两个函数名了。我们现处于0x230字节。0100;序数，不需要正确5772697465436f6e736f6c654100;"WriteConsoleA"的ASCII码值0200;序数，不需要正确47657453746448616e646c6500;"GetStdHandle"的ASCII码值
Ok,这就全部结束了。下一个字节，我们并不真正需要，是0x24f。我们必须将节填充到0x260处:00000000000000000000000000000000;填充的00
------------
我们已经完成了。因为我们已经知道了所有的字节偏移量，我们可以应用我们的修正到所有原先被用“？？”符号标为“未知”的地址和大小了。我将不强迫你一步一步地去读它（很好懂的），只直接给出结果来：
DOS-头,开始于0x0:00|4d5a000000000000000000000000000010|0000000000000000000000000000000020|0000000000000000000000000000000030|00000000000000000000000040000000
签名,开始于0x40:50450000
文件头,开始于0x44:Machine4c01;i386NumberOfSections0200;代码和数据TimeDateStamp00000000;谁管它PointerToSymbolTable00000000;未用NumberOfSymbols00000000;未用SizeOfOptionalHeadere000;常量Characteristics0201;可执行于32位机器上
数据目录，开始于0xb8:地址大小0000000000000000;IMAGE_DIRECTORY_ENTRY_EXPORT(0)e00100006f000000;IMAGE_DIRECTORY_ENTRY_IMPORT(1)0000000000000000;IMAGE_DIRECTORY_ENTRY_RESOURCE(2)0000000000000000;IMAGE_DIRECTORY_ENTRY_EXCEPTION(3)0000000000000000;IMAGE_DIRECTORY_ENTRY_SECURITY(4)0000000000000000;IMAGE_DIRECTORY_ENTRY_BASERELOC(5)0000000000000000;IMAGE_DIRECTORY_ENTRY_DEBUG(6)0000000000000000;IMAGE_DIRECTORY_ENTRY_COPYRIGHT(7)0000000000000000;IMAGE_DIRECTORY_ENTRY_GLOBALPTR(8)0000000000000000;IMAGE_DIRECTORY_ENTRY_TLS(9)0000000000000000;IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG(10)0000000000000000;IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(11)0000000000000000;IMAGE_DIRECTORY_ENTRY_IAT(12)0000000000000000;130000000000000000;140000000000000000;15
节头(代码节),开始于0x138:Name2e636f6465000000;".code"VirtualSize00000000;未用VirtualAddressa0010000;代码节的RVASizeOfRawData20000000;代码的大小PointerToRawDataa0010000;代码节的文件偏移量PointerToRelocations00000000;未用PointerToLinenumbers00000000;未用NumberOfRelocations0000;未用NumberOfLinenumbers0000;未用Characteristics20000060;代码节，可执行，可读
节头(数据节),开始于0x160:Name2e64617461000000;".data"VirtualSize00000000;未用VirtualAddressc0010000;数据节的RVASizeOfRawDataa0000000;数据节的大小PointerToRawDatac0010000;数据节的文件偏移量PointerToRelocations00000000;未用PointerToLinenumbers00000000;未用NumberOfRelocations0000;未用NumberOfLinenumbers0000;未用Characteristics400000c0;已初始化，可读，可写
(填充)000000000000;填充的000000000000000000000000000000000000
代码节,开始于0x1a0:6A00;push0x0000000068d0011000;pushoffset_written6A0D;push0x0000000d68c0011000;pushoffsethello_string6AF5;push0xfffffff52EFF1528021000;calldwordptrcs:__imp__GetStdHandle@450;pusheax2EFF1524021000;calldwordptrcs:__imp__WriteConsoleA@20C3;ret
数据节，开始于0x1c0:68656C6C6F2C20776F726C640A;"hello,world\n"000000;填充到和_written对齐00000000;_written填充：000000000000000000000000;填充的
输入描述（IMAGE_IMPORT_DESCRIPTOR），开始于0x1e0:OriginalFirstThunk18020000;原始第一个换长的RVATimeDateStamp00000000;未绑定ForwarderChainffffffff;-1，无中转Name08020000;DLL名字的RVAFirstThunk24020000;第一个换长的RVA结束标志(0x1f4):OriginalFirstThunk00000000;结束标志TimeDateStamp00000000;ForwarderChain00000000;Name00000000;FirstThunk00000000;
DLL名字,开始于0x208:6b65726e656c33322e646c6c00;"kernel32.dll"000000;填充到32位边界
原始第一个换长,开始于0x218:AddressOfData30020000;函数名"WriteConsoleA"的RVAAddressOfData40020000;函数名"GetStdHandle"的RVA00000000;结束标志
第一个换长,开始于0x224:AddressOfData30020000;函数名"WriteConsoleA"的RVAAddressOfData40020000;函数名"GetStdHandle"的RVA00000000;结束标志
输入函数名称（IMAGE_IMPORT_BY_NAME），开始于0x230:0100;序数，不需要正确5772697465436f6e736f6c654100;"WriteConsoleA"的ASCII码值
IMAGE_IMPORT_BY_NAME,开始于0x240:0200;序数，不需要正确47657453746448616e646c6500;"GetStdHandle"的ASCII码值(填充)00000000000000000000000000000000;填充的00第一个未使用字节开始于:0x260
--------------
噢，这个文件能在NT上却不能在windows95上运行。windows95不能运行按32字节节对齐的应用程序，它要求节对齐为4KB；并且很明显的，文件对齐也应为512字节。因此要想在windows95上运行，你得插入很多的0字节（为了对齐）并调整RVA。感谢D.Binette在windows95上的（运行）试验。
--全文结束--
===========================|“PE文件格式”1.9版注释：|===========================①Win32s和Win32Win32s是“WIN32subset”的缩写，它是一个可被加入到Windows3.1和WindowsforWorkgroups系统中以使它们能够运行32位应用程序的软件包。正如它的名字所暗示的那样，Win32s只是Windows95和WindowsNT系统中使用的Win32API的一个子集。Win32s的主要功能就是在32位和16位内存地址间相互转换，也就是一种被称为换长的操作。
Win32是32位Windows（包括WindowsNT,95,98和2000等）操作系统的编程接口(API)。当应用程序是按Win32API编写时，它们就具有16位API(Win16)所不具备的一些高级性能。一个按Win32编写的程序能运行在所有的操作系统之上，除非这个程序要求特定的操作系统特性，而这些特性别的操作系统又没有时。例如，WindowsNT提供的安全特性Windows95/98就没有。一个为NT系统的这些特性编写的程序就不能运行在其它的Windows系统之上。
使用此API的程序能运行在...上Win3295,98,NT,2000,XPWin32s3.1,95,98,NT,2000,XPWin32c95Win163.0,3.1,95,98,NT,2000,XP
②目标文件（Objectfile）和映象文件（Imagefile）目标文件（Objectfile）指的是链接程序（链接器）的输入文件。链接器输出的是映象文件，映象文件反过来又是加载器的输入文件。“objectfile”一词未必含有任何和面向对象的编程有关的联系。
映象文件（Imagefile）指的就是可执行文件：或者是.EXE，或者是.DLL。一个映象文件可被想象为“内存映象”。“映象文件”一词常被用来代替“可执行文件”，因为后者有时被用来专指.EXE文件。
③UNIX是一个很流行的多用户、多任务的操作系统，由贝尔实验室于上世纪70年代早期开发出来的。只有很少的程序员建立的UNIX系统本来是设计给他们这些程序员专用的、小巧的、灵活的系统。UNIX是用高级编程语言，就是C语言，编写的第一批操作系统之一。这就意味着只要电脑上有C语言编译器，UNIX就可以被虚拟地安装到任何电脑上。天生的可移植性加上低廉的价格使得UNIX成为各大学的流行选择。（因为反信用条款禁止贝尔实验室将UNIX作为它的全权产品推向市场，所以UNIX的价格不贵。）贝尔实验室只发布它自己源语言形式的UNIX操作系统，所以任何获得一份拷贝的人都可以按照自己的意愿来修改和定制它。到上世纪70年代末时，有好几十种不同版本的UNIX运行在世界各地。（更多信息请参阅别的资料。）
⑥NeFormat（New-styleEXEFormat的缩写）是一个早期Windows操作系统的可执行文件(.EXE)，包含一个代码和数据的集合或者一个代码、数据和资源的集合。这种可执行文件也包括两个头：一个MS-DOS头和一个Windows头，和一些节。（具体参看其他资料）
MIPS技术公司是美国著名的芯片设计公司，它采用精简指令系统计算结构(RISC)来设计芯片。和英特尔采用的复杂指令系统计算结构(CISC)相比，RISC具有设计更简单、设计周期更短等优点，并可以应用更多先进的技术，开发更快的下一代处理器。MIPS是出现最早的商业RISC架构芯片之一，新的架构集成了所有原来MIPS指令集，并增加了许多更强大的功能。
⑨big-endian、Little-endian和endianBig-endian和Little-endian是用来表述一组有序的字节数存放在计算机内存中时的顺序的术语。Big-endian(即“大端结束”或者“大尾”)是将高位字节（序列中最重要的值）先存放在低地址处的顺序，而Little-endian（即“小端结束”或者“小尾”）是将低位字节（序列中最不重要的值）先存放在低地址处的顺序。举例来说，在使用Big-endian顺序的计算机中，要存储一个十六进制数4F52所需要的字节将会以4F52的形式存储（比如4F存放在内存的1000位置，而52将会被存储在1001位置）。而在使用Little-endian顺序的系统中，存储的形式将会是524F（52在地址1000处，4F在地址1001处）。IBM的370种大型机、大多数基于RISC的计算机以及Motorola的微处理器使用的是Big-endian顺序，TCP/IP协议也是。而Intel的处理器和DEC公司的一些程序则使用的Little-endian方式。“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。我们一般将endian翻译成“字节序”，将bigendian和littleendian称作“大尾”和“小尾”。
⑩AlphaAXP“DECAlpha”,也被称作“AlphaAXP”,是一个原来由美国数据设备公司(DEC)开发和制造的64位RISC微处理器（例如：DECAlphaAXP21064微处理器），他们将它用在自己的工作站和服务器系列上。被设计作为VAX系列计算机的继承者，AlphaAXP不但支持VMS操作系统，同时也支持DigitalUNIX操作系统。后来的一些开放源码操作系统也能运行于Alpha之上，著名的Linux和BSDUNIX操作系统特别支持。微软直到WindowsNT4.0SP6才支持这种处理器，但Windows2000第2版之后就又不支持了。
BSS是“BlockStartedbySymbol”的缩写，意为“以符号开始的块”。BSS是Unix链接器产生的未初始化数据段。其他的段分别是包含程序代码的“text”段和包含已初始化数据的“data”段。BSS段的变量只有名称和大小却没有值。此名后来被许多文件格式使用，包括PE。“以符号开始的块”指的是编译器处理未初始化数据的地方。BSS节不包含任何数据，只是简单的维护开始和结束的地址，以便内存区能在运行时被有效地清零。BSS节在应用程序的二进制映象文件中并不存在，例如：unsignedcharvar;//分配到.bss节的8位未初始化变量unsignedcharvar2=25;//分配到.data节的8位已初始化变量
BSOD（bluescreenofdeath，蓝屏死机）是运行在Windows环境下的计算机上出现的一个错误，甚至包括最早版本的Windows，比如Windows3.0和3.1，在后来的Windows版本比如MicrosoftWindows95,Windows98,WindowsNT,和Windows2000上仍能出现。它被开玩笑地称为蓝屏之死是因为错误发生时，屏幕变成蓝色，电脑总是不能正常运转并需要重新启动。
POSIX是“PortableOperatingSystemInterfaceforUNIX”（UNIX可移植操作系统接口）的首字母缩写，它是定义程序和操作系统之间的接口的一套IEEE和ISO标准。通过将他们的程序设计为符合POSIX标准，开发者就能获得一些让他们的程序可以容易地被移植到其他POSIX兼容的操作系统上的保证，主要包括大多数UNIX操作系统。POSIX标准目前由IEEE下叫做“PortableApplicationsStandardsCommittee”(PASC)（可移植的应用程序标准委员会）维护。