一直都想写篇文章来说说那些尘封在PE/Coff文件格式下的那些事，还有Metadata和EEClass是如何表现了一个静态的PE格式文件在内存中的映射结构。
   在这篇文章里，我不去介绍windows下PE文件的具体格式，也不去介绍一个托管或者是非托管PE文件的加载运行方式，更加不去介绍一个PE文件里面的各个头部以及整体结构的各个部分的含义。

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

而是侧重于介绍，基于托管环境下，DotNet对基本的PE/CoFF文件格式做了那些扩充，CLR头部介绍，以及元数据和IL代码详析解析。主要侧重从静态文件的角度，来剖析DotNet下最基本的模块的结构，以及这样的结构如何适应一个托管的环境。

拟把PE文件格式里里外外从上到下一点一点的完全解剖一遍，当然，不可能做到很全面，不然，如果想知道PE文件的各个方面的具体的细节，可以参阅文章底部推荐的那个白皮书文档，这份文档相当详尽介绍了PE文件格式的点点滴滴。

首先，还是从一段C#代码开始：

class Program

{

public const int conField=122*1119;

public readonly int roField;

private int _property;

public int Property

{

get {return _property; }

set{_property = value; }

}

static void <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Main(string[] args)

{

(new Program()).Method();

}

public void Method()

{

System.Console.ReadLine();

}        
    }

之所以定义这么多类型和字段，主要是为了在解说托管PE文件格式的时候，元数据表中相关的表都会出现相关记录。

编译之后，得到一个叫做TestConsoleApp.exe的托管PE文件。在继续下面的叙述之间，首先先概括的说一下Metadata。不说IL语言是因为，在我以前的博文中，已经有相关的介绍。

一个托管PE文件，粗略的讲，由4个部分组成。PE32(+)的头部，CLR头部，Metadata以及IL。

首先，我们来说说CLR的头部。这个东西，是托管的PE文件所特有的东西。

我们打开DotNet Framework里面的include文件夹里面一个叫做CorHdr.h的文件，找到一个叫做IMAGE_COR20_HEADER这个数据结构的定义。这个数据结构，定义的就是CLR的header里面内容。下面对其的定义：

// COM+ 2.0 header structure.

typedef struct IMAGE_COR20_HEADER

{

// Header versioning

DWORD                   cb;

//CLR的主版本号

WORD                    MajorRuntimeVersion;

//CLR的副版本号

WORD                    MinorRuntimeVersion;

// Symbol table and startup information

//标识元数据在这个PE文件里面起始位置。

IMAGE_DATA_DIRECTORY    MetaData;

//标识这个runtime的Flags

DWORD                   Flags;           
            // DDBLD - Added next section to replace following lin
            // DDBLD - Still verifying, since not in NT SDK
            // DWORD                   EntryPointToken;

// If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is not set, EntryPointToken represents a managed entrypoint.

// If COMIMAGE_FLAGS_NATIVE_ENTRYPOINT is set, EntryPointRVA represents an RVA to a native entrypoint.
            //EnterPoint Token，这个定义的是这个image的MethodDef的入口点。

union {

DWORD               EntryPointToken;

DWORD               EntryPointRVA;

};
           // DDBLD - End of Added Area

// Binding information

//标识CLI资源的目录

IMAGE_DATA_DIRECTORY    Resources;

//强命名的签名文件。标识对这个PE文件计算得到的一个Hash文件的地址。这个是在CLI的loader在加载一个PE文件的时候，验证版本和加载的时候需要使用的。可以为空。

IMAGE_DATA_DIRECTORY    StrongNameSignature;

// Regular fixup and binding information

//代码管理表的地址

IMAGE_DATA_DIRECTORY    CodeManagerTable;

//这个module里面的一个包含地址的数组，数组的每一项，都包含了对一个founction的指针。

IMAGE_DATA_DIRECTORY    VTableFixups;

//这个也是包含的一个数组，数组里面都是方法需要jump的地址。

IMAGE_DATA_DIRECTORY    ExportAddressTableJumps;

// Precompiled image info (internal use only - set to zero)

//这个地址，保存的是这个Module对应的在本机上面的Jit过后了的本地代码的目录。

IMAGE_DATA_DIRECTORY    ManagedNativeHeadesr;

} IMAGE_COR20_HEADER, *PIMAGE_COR20_HEADER;

接下来，我们就直接打开上面编译好的那个托管模块的CLR头部，看看里面有些什么：

----- CLR Header:

Header size:                       0x00000048

Major runtime version:              0x0002

Minor runtime version:              0x0005

0x00002094 [0x00000660] address [size] of Metadata Directory:

Flags:                            0x00000001

Entry point token:                  0x06000003

0x00000000 [0x00000000] address [size] of Resources Directory:

0x00000000 [0x00000000] address [size] of Strong Name Signature:

0x00000000 [0x00000000] address [size] of CodeManager Table:

0x00000000 [0x00000000] address [size] of VTableFixups Directory:

0x00000000 [0x00000000] address [size] of Export Address Table:

0x00000000 [0x00000000] address [size] of Precompile Header:

从上面的这个托管模块的头部可以看到，这个头部里面包含的内容，和这个头部的结构体所定义的东西，是完全一致的。

几个需要说明的，一个是Major runtime version，以及Minor runtime version标识的是不同的runtime的版本。在上面的头部中，主要是一个文件的偏移的offset，就是Entry point token的地址。

这里要特别提出来一点，这里的Entry point token表示的是入口点，是MethodDef的入口点。

而不是整个托管PE文件的入口点。整个PE文件的入口点，在这里，用PEID打开可以看到，是

Addr. of entry point:           0x000027be

这个EnterPoint是在一个32位的PE Optional Header里面定义的。这个入口点，才是整个应用程序的入口点。

这个入口点里面，我们使用IDA之类的逆向工程工具可以看到，托管PE模块在这个地址上面的代码：

004027BE: FF 25 00 20 40 00              jmp dword ptr ds:[402000] ; _CorExeMain

在这里，我们看到了熟悉的CorExeMain这个入口函数 ^_^ 关于这个函数，我就不多说了，在前面的博文里面有详析的分析。参见那篇探索托管模块加载过程的文章。

接下来，我们介绍下元数据表，以及一些对这个PE文件的统计信息，首先查看这个托管PE文件的统计信息，使用的还是ildasm工具，我的最爱：

File size            : 16384

PE header size         : 4096 (496 used)    (25.00%)

PE additional info      : 1075              ( 6.56%)

Num.of PE sections   : 3

CLR header size        : 72                 ( 0.44%)

CLR meta-data size      : 1632               ( 9.96%)

CLR additional info      : 0                  ( 0.00%)

CLR method headers    : 16                 ( 0.10%)

Managed code         : 49                ( 0.30%)

Data                 : 8192              (50.00%)

Unaccounted          : 1252              ( 7.64%)

Num.of PE sections   : 3

.text    - 4096

.rsrc    - 4096

.reloc   - 4096

CLR meta-data size  : 1632

Module        -    1 (10 bytes)

TypeDef       -    2 (28 bytes)      0 interfaces, 0 explicit layout

TypeRef       -   18 (108 bytes)

MethodDef     -    5 (70 bytes)      0 abstract, 0 native, 5 bodies

FieldDef      -    3 (18 bytes)      0 constant

MemberRef     -   17 (102 bytes)

ParamDef      -    2 (12 bytes)

Constant      -    1 (6 bytes)

CustomAttribute-   13 (78 bytes)

StandAloneSig -    1 (2 bytes)

PropertyMap   -    1 (4 bytes)

Property      -    1 (6 bytes)

MethodSemantic-    2 (12 bytes)

Assembly      -    1 (22 bytes)

AssemblyRef   -    1 (20 bytes)

Strings       -   680 bytes

Blobs         -   236 bytes

UserStrings   -     8 bytes

Guids         -    16 bytes

Uncategorized -   194 bytes

CLR method headers : 16

Num.of method bodies  - 5

Num.of fat headers    - 1

Num.of tiny headers   - 4

Managed code : 49

Ave method size - 9

可以看到，在上面的统计信息中，显示了一个托管的PE模块的各个部分的组成。从各个部分的统计的大小里面，PE Header和CLR的Metadata占据了相当大的比例，而IL代码，仅仅占据了整个托管模块大小的0.3％。只有49个字节。

顺便提一下，如果Unaccounted显示的是负数，是不能相信的，那是以前的版本存在的一个bug。

就写到这里吧，如果觉得看了上面的东西还是不知所云或者觉得不完整，那我推荐一本MS的白皮技术文档：Visual Studio, Microsoft Portable Executable and Common Object File Format Specification

可以在msdn上面下载到，它完整的讲述了PE文件格式的各个部分的细节。

接下来的一篇博文，就说说元数据以及元数据表的内存结构，逻辑结构和在SSCLI中的设计和实现。

最后做个广告：   
   欢迎园子里面的朋友加入SSCLI团队，这里，我们致力于对.Net底层核心技术及其实现的研究。如果你想真正的了解.Net最核心的实现，我们热忱的欢迎你的加入：
   圈子地址：http://sscli.cnblogs.com
   加入地址：http://www.cnblogs.com/lbq1221119/archive/2008/03/10/1097627.html
   
   圈子刚刚建立，希望园子里的朋友多多支持,:)