一.摘要
   在我们使用了任何支持CLR的语言来创建了源代码文件之后，无论使用什么编译器，编译出的文件都是一个托管模块（managed module），这个托管模块可以在CLR上运行。所以，我们把这种文件称为托管可执行文件（Managed Executable File）。关于通用PE文件的格式已经在笔记三中间记录了，这里只记录一些托管文件自身比较有特色的部分。

二.托管执行文件的重要组成部分
1.CLR Header
   我们知道，在PE头中，包含一个数据目录表（Data Directory Table），这个表的第15项就是一个包含了CLR头的RVA和大小，可以通过它找到CLR Header。简单记录一下CLR Header中的几个主要的字段：
（1）Flags
   这是一个二进制的标记，其可选值包括：
   A.COMIMAGE_FLAGS_ILONLY (0x00000001) 文件中只包含纯的IL代码，未嵌入任何Native Code（除了Dos Stub，这个stub会被所有能够识别CLR的系统忽略掉）。
   B.COMIMAGE_FLAGS_32BITREQUIRED (0x00000002) 文件只能被加载到32位的进程空间中。
   C.COMIMAGE_FLAGS_STRONGNAMESIGNED (0x00000008) 文件受到强名称签名的保护
（2）EntryPointToken
   这是一个指明了此PE文件入口点的元数据标志符（MeteData Identifier），它指向一个方法定义或者文件引用，而指向文件引用的唯一可能是：一个多模块程序集的入口点不在其主模块中，那么主模块里的入口点标记指向包含入口点的模块文件。入口点只能出现在可执行文件里，如果你的代码里不包含入口点，IL汇编器会拒绝为你编译EXE文件。但对于非可执行文件，却分为两种情况：如果程序是一个纯的托管程序，则不需要入口点；如果程序中即包含IL代码又包含机器码（由MC++编译器和链接器生成），则必须把DLLMain()作为入口点函数，它要对程序集里的非托管代码进行一些必要的初始化操作。
（3）VTableFixups
    要理解这个字段，首先要理解v-table的概念。这是我摘了一个老外的描述，应该很精确，“Certain languages, which choose not to follow the common type system runtime model, may have virtual functions which need to be represented in a v-table. These v-tables are laid out by the compiler, not by the runtime. Finding the correct v-table slot and calling indirectly through the value held in that slot is also done by the compiler”。v-table是为虚方法调用服务的，而VTableFixups包含了一组v-table的地址和大小。 
   根据笔者当前的认识，v-table只有在此托管文件需要和非托管环境交互的时候才有用（比如这个托管代码要被一个非托管环境调用），在纯的托管环境下可能是没用的。当然，大家都知道C#作为典型的OO语言，也有虚函数的概念，但它的虚函数实现机制和C++中的v-table的实现方式有什么不同，我暂时还不清楚。

2.文本段（.Text section）
    整个CLR Header是放置在一个文本段中的。这是一个只读的段，包含了元数据表、IL代码、引入表等，整个结构如下图所示：