小结

讨论过托管映像文件的结构以及IL编译器生成这些文件的方式，我将小结一下IL编译器创建一个托管PE文件的步骤。PE文件的创建表现为以下4个步骤：

步骤1：初始化

1.       初始化内部缓冲器

2.       在内存创建一个PE文件的空模板，包括MS-DOS头和stub、PE签名、COFF头和PE头。

3.       输入地址表和CLR头被分配在.text区段中。

步骤2：源代码的语法分析

1.       元数据被收集在内部缓冲器中。

2.       方法体（IL代码和托管的异常处理表）被收集在内部缓冲器中。

3.       数据常量被发布到.sdata和.tls区段。

步骤3：图像的生成

1.       为强签名在.text区段中分配空间。

2.       元数据被分析和重新整理。

3.       内部（到模块）的引用在IL代码中被处理。

4.       方法体被发布到.text区段。

5.       TLS目录表被发布到.sdata区段。

6.       调试目录被发布到.text区段。

7.       为元数据在.text区段中分配空间。

8.       为内嵌的托管资源在.text区段中分配空间。

9.       非托管的导出stub被发布到.text区段。

10.   VTFixup标被发布到.text区段。

11.   V-表被发布到. sdata区段。

12.   非托管的导出表被发布到. sdata区段。

13.   元数据中最近的改变——映射字段的RVA被修复。

14.   元数据被发布在.text区段的预分配空间。

15.   托管的资源被发布在.text区段的预分配空间。

16.   运行时的开始stub被发布在.text区段

17.   非托管资源被从.res文件中读取到，并被发布在.rsrc区段

18.   必需的基本重定向被发布在.reloc区段

步骤4：完成

1.       映像文件被写为一个磁盘文件。

2.       强签名过程被应用到文件，通过调用强名称工具的方式。

IL编译器允许你在映像文件的头中显示地设置某个值，依靠源代码指令和编译器命令行选项，正如表4-7所示。在本章所讨论的所有情形中，命令行选项优先于相应的源代码指令。

头	字段	指令	命令行选项
COFF	Machine		/ITANIUM, /X64(default is I386)
PE	Header type		/PE64(default is PE32)
PE	ImageBase	.imagebase <integer value>	/BASE=<integer value>
PE	SizeOfStackReserve	.stackreserve <integer value>	/STACK=<integer value>
PE	FileAlignment	.file alignment <integer value>	/ALIGNMENT=<integer value>
PE	Subsystem	.subsystem <integer value>	/SUBSYSTEM=<integer value>
CLR	Flags	.corflags <integer value>	/FLAGS=<integer value>

Commit翻译——提交？

Preferred——首选的

take precedence of——优先于

make nontrivial use of = 很需要使用

as sush 同样的

重定位区段

映像文件的.reloc区段包括了Fixup表，它为映像文件中的所有修正保存了入口。RVA和.reloc区段的大小都由PE头的Base Relocation表目录定义。Fixup表由很多块修正组成，每一块将这些修正保存为一个4KB的页。这些块都是按4字节排列的。

每一个修正都描述了映像文件中特定地址的位置，以及当加载这个映像文件到内存的时候，OS加载器应该如何修改这个位置上的地址。

每一个修正块开始于两个4字节的无符号整数：这个页的RVA包括了要修正的地址和这个块的大小。这个页的入口的修正包括直接位于它的后面。每个入口都有16位的宽度，包含了重定位的类型所需要的4个最重要的字节。剩下的12位保存了这个页中重定位地址的偏移量。

为了重定位地址，OS的加载器计算出首选的基地址（PE头的ImageBase字段）和实际映像文件被加载的基地址之间的不同（delta）。这个delta接着根据重定位的类型被应用到地址上。一旦映像文件被加载到它首选的位置，就不会应用任何修正。

下面的重定位类型定义于Winnt.h中：

IMAGE_REL_BASED_ABSOLUTE (0)：这个类型在映像文件中没有任何意义，修正在这里被跳过。

IMAGE_REL_BASED_HIGH (1)：这个delta的16高位段被添加到偏移量上的16位字段上。

IMAGE_REL_BASED_LOW (2)：这个delta的16低位段被添加到偏移量上的16位字段上。在这种情形中的16位字段是32位地址被重新部署的半数低位。

IMAGE_REL_BASED_HIGHLOW (3)：这个delta被添加到偏移量上的32位字段上。对这个类型的重定位与IMAGE_REL_BASED_HIGH和IMAGE_REL_BASED_LOW这些重定位的位或运算是相等的，它是32位地址重定位的首选类型。

IMAGE_REL_BASED_HIGHADJ (4)：这个delta的16高位段被添加到偏移量上的16位字段上。这个16位字段在这种情形中是重定位的32位地址的高位部分。这个地址的16低位存储在16位的在这个重定位之后的单词中。这个类型的修正占据了两个槽。

IMAGE_REL_BASED_MIPS_JMPADDR (5)：

IMAGE_REL_BASED_SECTION (6)：保留的。

IMAGE_REL_BASED_REL32 (7)：保留的。

IMAGE_REL_BASED_MIPS_JMPADDR16 (9)：这个修正应用到MIPS的jump方法。

IMAGE_REL_BASED_IA64_IMM64 (9)：与IMAGE_REL_BASED_MIPS_JMPADDR16相同。

IMAGE_REL_BASED_DIR64 (10)：这个delta在偏移量上被添加到64位字段。

IMAGE_REL_BASED_HIGH3ADJ (11)：这个修正添加了这个delta的16高位段到偏移量上的16位字段上。这个16位字段是48高位地址的三分之一。这个地址的32位低位存储在32位两倍于这个单词中，紧跟在这个重定位中。这个类型的一个修正占据了3个槽。

唯一的修正类型是IMAGE_REL_BASED_HIGHLOW，由32位可执行体中的已有的托管编译器发布。在64位可执行体中，则是IMAGE_REL_BASED_DIR64

一个32位的纯净IL的PE文件，在.text区段中只包括一个修正。这样做是为了CLR开始的stub，在一个纯净的IL映像文件中本地代码的唯一片段。这个修正是为了映像文件的IAT，包括了一个唯一的入口：CLR入口点。

一个64位的纯净IL的PE文件，在X64体系中有1个修正，在Itanimu体系中有2个修正（额外的那个修正是为了全局指针）。

Windows XP或者更新的版本，作为一个CLR天生载体的操作系统，既不需要CLR的开始stub，也不需要IAT来调用CLR。因此，如果CLR头的标记指出映像文件只是IL（COMIMAGE_FLAGS_ILONLY），操作系统就会完全地忽略这个.reloc区段。

这种优化对由IL编译器生成的一些映像文件开了一个冷笑话，这将生成纯净的IL映像文件但却需要重定向被执行——如果有任何数据定位于TLS或定义了data on data。当映像文件在Windows XP下被加载时，为了让这些重定位得到执行，IL编译器被迫作弊并设置CLR头的标记就好像映像文件包括内嵌的本地代码（32位目标平台上为COMIMAGE_FLAGS_32BITREQUIRED，没有适用于64位目标平台的值）。

其他平台上并没有这些问题。生成了纯净IL映像文件的编译器（如C#或VB.NET）并没有定义基于TLS的数据或data-on-data。

正如VC++编译器和连接器生成混合代码的映像文件那样，这些映像文件的.reloc区段可以包括任意数量的重定位。但是混合代码的映像文件从来不携带仅有IL的CLR头标记，因此他们的重定位总是被执行。

文本区段

PE文件的文本区段是一个只读区段。在一个托管的PE文件中，它包括了元数据表、导出表、CLR头以及用于CLR的非托管的启动stub。在这个由IL编译器生成的映像文件中，这个区段还包括了托管资源、哈希强签名、调试数据以及非托管的导入型stub。

图4-3总结了由IL编译器生成的.text区段的通用结构。

IL编译器以一个特定的顺序发布数据到.text区段。当PE文件生成器在IL启动期间被初始化的时候，就会在.text区段为输入地址表（只携带一个单独的入口，作为CLR的入口点）和在本章前面章节描述的CLR头分配空间。

当IL编译器解析源代码并在内存中形成元数据和IL结构体的时候，.text区段得到一个临时性的断点；直到解析完成并且IL编译器做好PE文件发布的准备时，才会发布上去。

接下来是IL编译器，如果是这样被安排好的（通过在.assembly指令中指定公钥；参见第6章了解详细内容），为强签名在.text区段分配充分的空间。强签名是一个对主模块使用程序集发布者的私钥进行加密的哈希值。签名本身被发布到随后分配的空间中，作为主模块生成的最后一步。

接下来进行到方法体这一步，包括了方法头、IL代码以及托管异常处理表（参见第10章了解详细内容）。

图4-3 由IL编译器发布的.text区段的结构

在方法体被发布后，而且一旦你定制了包括调试信息的PDB文件的生成，IL编译器就发布调试目录入口以及包括了指向PDB文件路径的CodeReview-style头。

接下来是元数据，在那之后会被完全定义的，就被发布到.text区段，紧跟在后面的是托管资源（如果有的话）。元数据格式会在下一章详细描述，而托管资源将会在本章后面的“资源”章节讨论。

在元数据和托管资源之后，非托管导出stub发布为那些托管的方法——被暴露为非托管的导出。第18章描述了导出托管方法为非托管的客户端。

下一个发布到.text区段的项（如果存在），是本章前面描述的V-表的修正表。

最后一个发布到.text区段的项，是CLR的非托管起始stub，它的RVA被分配到PE头的AddressOfEntryPoint字段。

数据区段

由IL编译器生成的一个映像文件的数据区段（.sdata），是一个可读写的区段。它包括了数据常量、在“V-表”章节中描述的V-表、非托管导出表以及TLS的目录结构。声明为特定于线程的数据位于一个不同的区段，也就是.tls区段。

数据常量

数据常量这个术语，可能有一些误解。数据常量位于一个可读写的区段中，肯定可以被覆写，因此从技术上讲，很难称其为常量。然而这个词语，涉及的是数据的用法而不是数据的本性。数据常量代表了静态字段直接的映射，并通常包括被映射字段初始化了的数据。（第一章描述了字段映射的特性。）

字段映射是一个便捷的方式来初始化任何带有ANSI字符串、blob或结构的静态字段。一个可选择的初始化静态字段的方法——也是一个以CLR形式的更传统的方法——将会通过执行类的构造函数中的代码显示地对其操作，正如第九章讨论的那样。但是这种可选择性更加单调乏味，因此没有人真的去责备编译器借助字段映射来初始化。VC++编译器映射了所有的全局字段，而不管它们是否将会被初始化。

将静态字段映射到数据有其自身的需要注意的。映射到数据区段的字段，换句话说，就如同类型控制和垃圾收集那样，是CLR控制机制难以达到的，换句话说，对于自由访问和修改是广泛开放的。这就引起了加载器阻止特定的字段类型被映射；被映射的字段类型可能不包括指向对象、向量、数组或任何非公有的子结构的引用。如果类的构造函数被用为静态字段初始化，就不会有这样的问题发生。从哲学意义上讲，这是非常自然的：贯穿人类的历史，背离了正统，尽管是临时性的，也总是会带来一些不愉快的并发症。

V-表

纯托管代码模块中的V-表用于将托管方法暴露给非托管代码来调用。V-表是由一些入口条目组成，每个入口条目又是由一个或多个槽位组成。这些入口和V-表的槽都定义在V-表的修正中——在前面“VTableFixedup字段”章节讨论。每个修正详细指明了数量和在每个入口中这些槽的宽度（4或8字节）。每个V-表的槽包含了相应方法的元数据符号，这将在执行期间被方法本身的地址或提供了非托管的方法入口的一个封送了thunk的地址所取代。随着这些修正在运行期间被执行，这个由托管的PE文件组成的V-表必须位于一个可读写的区段中。IL编译器将这个V-表放在了.sdata区段中，不像VTFixup表，后者位于.text区段中。

非托管映像文件的V-表需要完全定义在链接期间，并只需要基本的由OS加载器执行的重定位修正。由于在执行期间没有生成对V-表的改变（正如用托管图像的地址代替方法符号），非托管的映像文件在只读区段中携带着它们的V-表。

非托管导出表

在非托管的映像文件中，这些非托管的导出表占据了一个独立的名为.edata区段。在由IL编译器生成的映像文件中，这些非托管导出表位于.sdata区段中，还附带上它所引用的V-表。

非托管的导出表包括了有关方法的信息——非托管导出文件能够遍历动态链接。非托管的导出表不是一个单独的表，而是一组连续的5个表：Export Directory表，Export Address表，Name Pointer表，Ordinal表和Export Name表。图4-4显示了YDD.DLL模块的导出表之间的联系，它的函数暴露为Yabba，Dabba和Doo。

图4-4 非托管表导出表的结构

非托管的导出信息开始于Export Directory表，它描述了导出信息的剩余部分。这是只有一个元素的表，包括了位置和其他导出表的大小。这个Export Directory表的唯一一行的结构，定义在如下的Winnt.h中：

简而言之，_IMAGE_EXPORT_DIRECTORY字段包括了以下部分：

Characteristics：保留的。这个字段应该被设置为0。

TimeDateStamp：导出数据生成的时间和日期。

MajorVersion：主版本号。这个字段和MinorVersion字段只用于信息；IL编译器并没有设置它们。

MinorVersion：次版本号。

Name：ASCII字符串的RVA，包括了导出模块的名称。

Base：顺序的基数（通常是1）。这是用来导出在映像文件表中的开始顺序的数字。

NumberOfFunctions：Export Address表中的入口数量。

NumberOfNames：Export Name表中的入口数量。

AddressOfFunctions：Export Address表中的RVA。

AddressOfNames：Export Name表中的RVA。

AddressOfNameOrdinals：Name Pointer表中的RVA。

Export Address表包含了被导出为入口点的RVA。一个进入点的导出序号定义为它的在Export Address表中的基于0的索引加上基本序号（IMAGE_EXPORT_DIRECTORY结构的Base字段值）。

在托管的文件中，Export Address表不仅包括了属于导出进入点（方法）自身的RVA，还有非托管导出stub——拥有对这些进入点的方法。（参见本章前面介绍的“文本区段”）。导出stub，按照顺序，包括了对相应的V-表的槽的引用。

在一个Export Address表中的RVA，可以是一个forwarder RVA，识别了一个重导出的进入点——就是说，一个指向这个模块的入口从一个模块导入并导出为其自身。在这种情形中，这个RVA指向了一个包括了导入名称的ASCII字符串。导入名称可能是一个DLL名称和这个导入点（SomeDLL.someFunc）的名称或一个DLL名称和在这个DLL（SomeDLL.#12）中导入入口的序号。

IL编译器并不允许重导出，因此由这个编译器生成的一个映像文件的Export Address表的入口，总是表示了非托管导出stub的RVA。

Export Name表包括了以0结尾的ASCII字符串，表示了由这个模块导出的方法导出名称。严格的讲，Export Name表不仅是一个表，还是一系列以0结尾的字符串。Export Name表中的导出名称按照字母顺序排序，从而使按照名称的二分查找法的入口点变得便利。导出名称可能不同于声明在模块中的方法下的名称。如果一个导出方法是只按照序号导出的，可能根本没有导出名称。在这种情形中，它的序号并不包括在Ordinal表中。IL编译器不允许未命名的导出。

Name Pointer表包括了来自Export Name表的由RVA组成的导出名称。

Ordinal表包括了对Export Address表的2个字节的索引。Name Pointer表和Ordinal表构成了两个类似的数组，并作为一个直接查找表来操作，重新排列了入口以至于它们可以从词法上按名称排序。当一个入口根据名称被识别时，这个二分查找法在Name Pointer表中被引导。如果在Name Pointer表中发现被找到的入口和地址数字N的名称相匹配，这个入口的序号会被从Ordinal表中的元素数字N取出。通过这个序号，这个入口的地址可以从Export Address中重新得到。

第18章检查了非托管的导出信息，以及将托管方法暴露为非托管导出的细节

TLS

ILAsm和VC++允许你定义属于TLS的数据常量并映射静态字段到数据常量上。TLS是一个特殊的存储类，在这里，一个数据对象不仅是一个栈变量仍然还是本地化到每个隔离的线程。从而，每个线程可以为每一个这样的变量维护一个不同的值。

TLS数据在TLS目录中描述，IL编译器将其放置于.sdata区段中。用于32位映像文件的TLS目录结构定义在如下的Winnt.h中：

用于64位映像（IMAGE_TLS_DIRECTORY64）的TLS目录的结构是类似的，除了开头的4个字段是8字节的无符号整数（ULONGLONG）取代了4字节的无符号整数（ULONG）。这个结构的字段如下：

StartAddressOfRawData：TLS数据常量的虚地址（是VA而不是RVA）的开始部分。TLS数据常量加上未初始化的TLS数据一起形成了TLS模板。每当一个线程创建的时候，操作系统就会制作一个对TLS模板的复制，从而提供了每个带有“私有”数据常量和字段映射的线程。

EndAddressOfRawData：TLS数据常量的VA的结束部分。TLS数据的结束部分（如果有的话）以0填充。IL编译器允许未初始化的TLS数据，假定TLS数据常量代表全部的TLS模板，因此不会留下什么被0填充。

AddressOfIndex：4字节TLS索引的VA，位于普通的数据区段。IL编译器将TLS索引放入.sdata区段，直接位于TLS目录结构和回调函数指针数组休止符的后面。

AddressOfCallBacks：TLS回调函数指针的一个以null结尾的数组的VA。这个数组以null结尾，而结果这个字段并不是null值并且如果没有指出回调函数的话，就指向一个全部为0的指针。IL编译器并不支持回调函数，因此TLS回调函数指针的整个数组包括了一个null休止符。这个null休止符在.sdata区段中的TLS目录结构之后。

SizeOfZeroFill：TLS模板的未初始化部分的大小，当TLS模板的一份复制被创建的时候，以0填充。IL编译器将这个字段设置为0。

Characteristics：保留的。这个字段应该被设置为0。

StartAddressOfRawData，EndAddressOfRawData，AddressOfIndex，AddressOfCallBacks字段保存了VA而不是RVA，因此你需要在.reloc区段为它们定义基本的重定位。

RVA和TLS目录结构的大小存储在PE头中的第10个数据目录（TLS）中。TLS数据常量，构成了TLS模板，位于映像文件的.tls区段中。

资源

你能够嵌入两种截然不同的资源到一个PE文件中：非托管的特定于平台的资源和托管的特定于CLR的资源。这两种资源，没有什么共同之处，位于托管映像文件的不同区段，并可以被不同组别的API访问。

非托管的资源

非托管资源位于映像文件的.rsrc区段中。开始部分的RVA和内嵌的非托管资源大小，都表示在PE头的资源数据目录中。

非托管资源是通过类型、名称和语言来索引的，它们是二进制的，以这三个特性以及上面的顺序进行分类。一系列资源目录表如下表示这个索引：每个目录表都紧跟着一个由目录入口组成的数组，它们包括了引用数字的整数（ID）或相应级别的名称（类型、名称和语言的级别）和下一级目录表的地址或数据描述（树的叶子节点）。由于使用了这三个索引特性，任何数据描述都可以通过分析至多三个目录表获取到。

在数据描述获取到之前，它的类型、名称和语言都可以从路径中得到，这个路径由搜索算法遍历以达到数据描述的位置。

.rsrc区段有以下结构：

资源目录表和入口：正如之前所描述的。

资源目录字符串：Unicode（UTF-16）字符串代表了通过目录入口寻址的字符串数据。这些字符串是以2字节排列的。每个字符串都在前面加上2-字节无符号整数以表示这个字符串的长度。

资源数据描述：一组由目录入口记录的地址，包括了这个实际资源数据的大小和位置。

资源数据：处于自然状态的undelimited资源数据，由独立的资源数据组成，其地址和大小定义在数据描述的记录中。

一个资源目录表的结构定义在如下的Winnt.h中：

根据前面关于对非托管资源和资源目录表的构成的讨论，这些字段的角色应该是明显的。一个异常可能是Characteristic字段，这是受保护的并且应该被设置为0。

名称入口，使用字符串来识别类型、名称或语言，直接跟在资源目录表之后。在其之后，存储了ID入口。

资源目录入口（名称入口或ID入口）是一个8位的结构，包括了两个4位无符号整数，在Winnt.h中定义如下：

如果第一个4位的组件的开始位被设置了，入口就是一个名称入口，并且剩下的31位代表了名称字符串的偏移量；否则，这个入口就是一个ID入口，并且它的16个不重要的位保存了ID值。

如果第二个4位的组件的开始位被设置了，那么这个项，它的偏移量由剩下的31位所表示，是资源目录表的下一级别，否则它就是一个资源数据描述。

资源数据描述是一个定义在如下Winnt.h中的16位结构：

OffsetToData和Size字段刻画了资源数据相应的chunk的特征，这些chunk组成了一个独立的资源。OffsetToData被详细指明相对于资源目录的起始位置。CodePage代码页的ID，用于对元数据中的代码点的值进行解码。通常这是Unicode的代码页。最后，不要在这里感到惊讶，Reserved字段是受保护的并且必须被设置为0。

IL编译器创建了.rsrc区段并内嵌了来自相应的.res文件的非托管资源——如果这个文件文件被详细指定在命令行选项。编译器只可以为每个模块内嵌一个非托管的资源文件。

当IL反编译器分析一个托管的PE文件并找到这个.rsrc区段，它从这个这个区段中读取数据和它的结构，并发布包括了在PE文件中所有的非托管资源的.res文件。

托管资源

CLR头的Resource字段包括了RVA和内嵌在PE文件中的托管资源的大小。这并没有对PE头的Resource目录做些什么，但是它详细指定了RVA和非托管的特定于平台的资源的大小。

在由IL编译器创建的PE文件中，非托管资源位于映像文件的.rsrc区段中，反之托管资源位于.text区段中，和元数据、IL代码等等在一起。托管资源连续地存储在.text区段中。元数据携带着ManifestResource的记录，每一个对应着一个托管的资源，包括了托管资源的名称，以及在CLR头的Resource字段中详细指明的RVA的开始部分距离资源开始处的偏移量。在这个偏移量的位置上，一个4位的无符号整数指出了资源的字节长度。紧跟在后面的则是资源本身。

当IL反编译器处理一个托管的映像文件并找到内嵌的托管资源，它将每个资源写到一个独立的文件中，并根据资源的名称来命名。

当IL编译器创建一个PE文件时，它从文件中读取定义在源代码中的所有托管的内嵌的资源，根据资源的名称并将它们写到.text区段中，每一个都以它们特定的长度作为开始。

作为一个练习，我提议你使用IL反编译器打开任何托管的可执行体（比方说，一个简单的示例），并选择View/Headers菜单进入点。你将会看到所有的头和它们的“field”字段。

CLR头

PE头的第15个目录入口包括了RVA和映像文件中的CLR头的大小。这个CLR头，包括了所有特定于CLR的数据入口和其他的信息，应该位于这个映像文件中的一段只读区段。IL编译器将CLR头放在了.text区段。

头的结构

CLR头定义在CorHdr.h中——一个头文件被分配为Microsoft .NET Framework SDK的一部分，如下：

表4-6对这个头的字段提供了进一步的着眼。

表4-6 CLR头的字段

Flags字段

CLR头的Flags字段保存了下列位标志的位或运算：

COMIMAGE_FLAGS_ILONLY (0x00000001)：这个映像文件只包括IL代码，而没有内嵌的本地非托管代码——除开始的stub外（只是简单地执行一个到CLR进入点的跳转）。CLR——意识到操作系统（如Windows XP或更新的操作系统）忽略开始部分的stub并自动调用CLR，到目前为止，所有的实际意图都是为了这个文件可以被认为是纯净的IL。然而，在Windows XP或更新操作系统下运行的时候，设置这个标记会引起特定的问题。如果设置了这个标记，Windows XP或更新操作系统的加载器不仅忽略了开始部分的stub，还忽略了.reloc区段，在这种情形中后者将包括一个对CLR入口点的单一的重定位（或者说在特定于IA64映像中的单独的一对重定位）。然而，.reloc区段既可以包括.tls区段的开始和结束位置的重定位，还包括被称为data on data的重定向（就是说，数据常量指向其它的数据常量）。在这些现有的托管的编译器中，只有VC++和IL编译器可以生成这些项。VC++的7.0版本和7.1版本（对应CLR的1.0版本和1.1版本）并没有设置这个标记，因为他生成的映像文件从来不是纯净的IL。在2.0版本中，这种情形有了改变，而当前，VC++和IL编译器是唯一的两个能够生成纯净IL映像文件的工具，而这些图像需要在.reloc区段中额外的重定向。为了解决这个问题，如果发布的是基于BLS的数据或data on data，IL编译器就会清除这个标记；如果目标平台是32位的，IL编译器就会替代地设置这个OMIMAGE_FLAGS_32BITREQUIRED标记。

COMIMAGE_FLAGS_32BITREQUIRED (0x00000002)：映像文件只可以被加载进一个32位进程中。这个标记是单独设置的——当本地非托管代码内嵌在PE文件中，或者当.reloc区段包括了额外的重定向的时候，或者与_ILONLY联合起来被设置——当可执行体不仅包括额外的重定向而且在某些方面是以特定于32位的（例如，调用一个非托管32位特定的API或者使用4字节的整型来存储指针）。

COMIMAGE_FLAGS_IL_LIBRARY (0x00000004)：这个标记是废弃的并且不能被设置。使用.corflags指令设置它——正如IL编译器允许的，将会生成你的未加载的模块。

COMIMAGE_FLAGS_STRONGNAMESIGNED (0x00000008)：映像文件是受强签名保护的。强签名。这个强签名包括了公钥和哈希签名，并作为一个编译集同一性的一部分，伴随着这个编译集的名称、版本号以及文化信息。当这个强签名过程被应用到一个映像文件的时候，就会设置这个标记。没有编译器，包括ILAsm在内，可以显示地设置这个标记。

COMIMAGE_FLAGS_NATIVE_ENTRYPOINT (0x00000010)：执行体的进入点是一个非托管的方法。CLR头的EntryPointToken/EntryPointRVA字段包括了这个本地方法的RVA。这个标记是在CLR 2.0版本中引进的。

COMIMAGE_FLAGS_TRACKDEBUGDATA (0x00010000)：CLR加载器和IL编译器被要求对方法的调试信息进行跟踪。这个方法没有被使用。

EntryPointToken字段

CLR头的EntryPointToken字段包括了一个符号（元数据标志符）——一个方法定义（MethodDef）或一个文件引用（File）。MethodDef符号将定义在模块（一个托管的PE文件）中的方法识别为入口点方法。File记号只用在一种情形中：在多模块编译集的主模块的CLR头中，当进入点方法定义在这个编译集的另一个模块中（由文件引用识别）。在这种情形中，这个由文件引用识别的模块包括了在它所在的CLR头的EntryPointToken字段中相应的MethodDef记号。

EntryPointToken必须在可以运行的执行体（EXE文件）中详细指明。例如，如果源代码没有定义入口点，IL编译器甚至都不会尝试生成一个EXE文件。CLR加载器利用了入口点方法的签名上的局限性：这个方法必须返回一个有符号或无符号的4字节的整数或者void，而且它至多必须有一个string或string[]（string向量）类型的参数。

没有这些不能运行的可执行体（DLL文件），这将是一个不一样的故事。纯IL的DLL并不需要定义了的入口点方法，并且在它们的CLR头中的EntryPointToken字段必需被设置为0。

混合代码的DLL——包括了IL和内嵌的非托管代码——由VC++编译器和链接器生成的，必须在这个DLL被调用时直接运行非托管本地函数DllMain，从而为非托管的本地DLL组件执行必要的初始化。这个非托管方法的签名必须是如下这样的：

int DllMain(HINSTANCE, DWORD, void *);

为了对托管代码和CLR可见，DllMain函数必须被声明为一个对内嵌的本地方法的平台调用（本地P/Invoke，也被称为IJW——It Just Works）。参见18章获取关于托管和非托管代码互操作的更多细节。

从2.0版本开始，你可以详细指明非托管的入口点方法而不用本地平台调用。既然这样，由OMIMAGE_FLAGS_NATIVE_ENTRYPOINT设定标记指定，这个EntryPointRVA字段（别名为EntryPointToken）包括了本地入口点方法的RVA。

这个被CLR头的EntryPointToken/EntryPointRVA字段指向的方法并没有对PE头指向的AddressOfEntryPoint方法做些什么。AddressOfEntryPoint总是指向CLR调用stub，这对于CLR是不可见的，不在元数据中反映出来并因此而没有一个符号。

VTableFixups字段

CLR头的VTableFixups字段是一个数据目录，包括了RVA和映像文件的V-表的修正表的大小。托管和非托管方法使用了不同的数据格式，因此当一个托管方法必须被非托管代码调用时，CLR就会为其创建一个封装的thunk，这将执行数据转换，而这个thunk的地址就被放置于相应的地址表中。如果托管方法是被内嵌在当前托管PE文件中的非托管代码调用的，这个thunk地址会进入这个文件的V-表。如果托管方法导出为非托管的，并且在这个托管PE文件外的任何地方使用，相应的v-表入口地址必须也进入导出型地址表。在加载的时候（也就是在磁盘的映像文件中），这个V-表的入口包括了相应的方法符号。

这些V-表的修正代表了创建这些thunk所必需的CLR初始信息。V-表的修正定义在下面的CorHdr.h中：

     在这个定义中，RVA指向了V-表的槽的位置，这个槽包括了方法的符号。Count详细指出了槽中入口的数量，1或者更多，例如，对同一个方法的多种实现是存在的，相互覆盖。Type是以下标记的位或运算，为CLR提供了关于槽的信息以及使用它能做些什么：

COR_VTABLE_32BIT (0x01)：每个入口都是32位宽的。

COR_VTABLE_64BIT (0x02)：每个入口都是64位宽的。

COR_VTABLE_FROM_UNMANAGED (0x04)：由CLR创建的thunk必须提供托管和非托管代码间的数据封送。

COR_VTABLE_CALL_MOST_DERIVED (0x10)：这个标志当前并不使用。

显然，头两个标记是互相排斥的。V-表的这些槽必须是一个紧跟着另一个——就是说，V-表必须是连续的。

V-表位于一个可读写的区段，因为它应该在图像被加载进内存后安排处理。相反，非托管图像中的V-表位于一个只读区段内。

在现有的托管编译器中，只有VC++和IL编译器可以定义V-表和它的修正。

StrongNameSignature字段

CLR头的StrongNameSignature字段包括了RVA和哈希强签名的大小，这将由CLR使用来确定映像文件的真实性。在映像文件被创建之后，使用由映像文件制造者提供的私钥对其进行哈希处理，而结果哈希块被写入到在映像文件中分配的空间。

如果即使连映像文件的一个单字节也是后期修改的，真实性检查就会失败，而且映像文件也不会被加载。强签名并不会经历一个反复的过程；如果你使用IL反编译器反编译一个强名称模块，接着重新编译它，这个模块必须重新进行强名称签名。

IL编译器将强名称签名放进映像文件的.text区段中。

小结

既然你已经了解元数据原则上是如何被组织的，你要准备好检测这些特定的元数据项和表示它们的表。所有进一步的考虑都将集中在4个元数据流上——#Strings、#Blob、#US和#~——因为#GUID只在一个元数据表中被引用到（Module表），而#-流（未优化的元数据）则从来不会被ILAsm编译器发布。

这里对一些人有一些建议，他们想知道这是否一个好的主意——在细微操作元数据的借口下，欺骗元数据头从而有权访问超越元数据之上的数据：忘记他！CLR加载器在分析元数据头的一致性和元数据本身时有安全保障。如果侦测到不一致性，加载器就拒绝打开这个元数据流。胡乱地修补这个元数据头并不会导致这个模块错误的或不可预计的行为；代替的，它会这段时期生成不可加载的模块。

一些翻译笔记: 

quit stalling! 不要拖延时间

It would be tempting to do （去做某事）非常诱人，有诱惑力

in minute detail: 细枝末节

emission翻译？？？

mutually exclusive 互斥的

翻译的有问题，bit和byte混淆了

Schema 翻译为规格

Stand-alone的翻译 独立的

per se 本身 本质上

Edit-and-Continue

元数据和验证

然而，这个“好的暗示”，仅仅是一个暗示。在前述的部分提供了关于你可以从一个列的确定的类型引用哪些表的信息。这并不意味着你应该引用所有你能够引用的表。在表5-10中列出的一些群组的符号类型比在CLR现有的发布版本中实际上可接受的要更加广阔。例如，MemberRefParent群组，描述了能够包含MemberRef记录的父级别的表，包括TypeDef表。但是这个元数据发布API不会接受TypeDef符号作为MemberRef的父级别符号；并且即使这样的元数据不知何故还是发布出来了，加载器将会忽略它。

元数据发布API提供了非常少的安全保证（它们中的大多数是相当琐碎的）直到元数据有效性被涉及。元数据是一个极其复杂的系统，并且是文字上的数以百计的需要被强制执行的有效性规则。

高级别的语言编译器，如VB.NET或C#，对元数据发布提供了一个重要级别的保护，因为它们防止了来自程序员的确切的元数据规格说明和发布。这种高级别语言是概念取代的和基于概念的，并且这是编译器的职责来把语言概念转换为元数据结构和IL代码构造，因此一个编译器可以被建造用来发布有效的结构和构造（好吧，或多或少。）另一方面，ILAsm，就像其它的编译器，是一个面向平台的语言并允许程序员生成巨大的范围的元数据结构和IL构造，其中只有小部分代表着一个有效的子集。

考虑到这种的艰难的情形，我们需要依赖于外部的有效性和验证性工具（说到有效性和验证不是在同义反复的练习——在CLR术语中，有效性经常应用于元数据，验证性择应用于IL代码。）一个这样的工具就是CLR本身。加载器依靠很多有效性工具来测试元数据，尤其是那些可以破坏系统的侵害。负责JIT编译器的运行时子系统执行IL代码的验证。这些工程被称为“运行时有效性和验证”。

PEVerify，一个独立的包括在.NET Framework SDK中的工具，提供了更彻底的有效性和验证。PEVerify使用了两种独立的子系统，MDValidator和ILVerifier。MDValidator也可以在IL反编译器中被调用。