Chapter 1, “Simple Sample,” introduced the managed executable file, known as a managed module and executed in the environment of the common language runtime. In this chapter, we’ll take a detailed look at the general structure of such a file. The file format of a managed module is based on the standard Microsoft Windows Portable Executable and Common Object File Format (PE/COFF) and is an extension of this format. Thus, formally, any managed module is a proper PE/COFF file, with additional features that identify it as a managed executable file.
在第一章，“简单示例”里，介绍了托管可执行文件，也就是一个在clr环境里执行的托管模块。在这一章，我们将深入看看这种文件的结构的细节。托管模块的文件格式是基于Windows PE/COFF文件格式，也是它的一个扩展。因此，形式上，任何托管模块都是一个特殊的PE/COFF文件，并且包含了一些附加的特征标识它是一个托管理的执行文件。
Because the file format of a managed module conforms to the Windows PE/COFF standard, the operating system treats the managed module as an executable. And the extended, common language runtime–specific information allows the runtime to immediately seize control over the module execution as soon as the operating system invokes the module. Figure 3-1 shows the structure of a managed PE/COFF file.
因为托管模块的文件格式符合Windows PE/COFF标准，操作系统把托管模块当作是一个可执行文件。在操作系统调用该模块时，clr相关的扩展信息让运行时接过模块的控制权。插图3-1展示了托管PE/COFF文件的结构。
Figure 3-1 托管可执行文件的一般结构.
Because IL assembly language (ILAsm) produces PE files only, this chapter concentrates on managed PE files—executables, also known as image files because they can be thought of as “memory images”—rather than pure COFF object files. (Actually, only one of the current managed compilers, Microsoft Managed C++ [MC++], produces object files as an intermediate step to PE files.)
因为IL汇编语言(ILAsm)只生成PE文件，本章将专注于托管可执行文件，也就是镜像文件，因为相对于纯COFF object文件，我们也可以看成是“内存镜像”（实际上，当前的托管编译器，只有Microsoft Managed C++ [MC++]将生成object文件当作一个中间步骤）
This analysis of the managed PE file structure employs the following common definitions:
托管PE文件结构的分析会用到如下常用定义：
· File pointer The location of an item within the file itself, before it is processed by the loader. This location is a position (an offset) within the file as it is stored on disk.
文件指针 item在被加载至内存前在文件内部的位置，是在存储在磁盘上的一个文件的内部位置或offset
· Relative virtual address (RVA) The address of an item once it has been loaded into memory, with the base address of the image file subtracted from it—in other words, the offset of an item within the image file loaded into memory. The RVA of an item almost always differs from its position within the file on disk (the file pointer).
相对虚拟地址 item在被加载至内存后，将基址从虚拟地址里减去后的一个offset值，也就是在加载至内存后，相对于镜像文件的一个位移(offset),相对虚拟地址几乎和它在磁盘文件内的地址位移不一样（文件指针）。
· Virtual address (VA) The same as the RVA except that the base address of the image file is not subtracted. The address is referred to as virtual because the operating system creates a distinct virtual address space for each process, independent of physical memory. For almost all purposes, a virtual address should be considered as simply an address. A virtual address is not as predictable as an RVA because the loader might not load the image at its preferred location if a conflict exists with any image file already loaded—a so-called base address conflict.
虚拟地址 跟相对虚拟地址一样，除了不用减去镜像文件基址。因为操作系统给每个进程创建了不相同的独立于物理内存的虚拟地址空间，所以这个地址叫虚拟地址。几乎对于所有的用途，一个虚拟地址应仅仅作为一个地址。一个虚拟地址并不像相对虚拟地址是确定的，因为如果有其他镜像文件被加载到其首选的位置（所谓的基址冲突）时，加载器（loader）是不会将这个镜像文件加载到其首选的位置。
· Section The basic unit of code or data within a PE/COFF file. In addition to code and data sections, an image file can contain a number of sections, such as .tls (thread local storage) or .reloc (relocations), that have special purposes. All the raw data in a section must be loaded contiguously.
段 PE/COFF文件内的代码或数据的基本单元。除了code和data段，一个镜像文件可以包含许多段，比如.tls(线程本地存储)或.reloc（重定位），用于特殊用途。所有段内的原始数据一定会被连续地加载。
Throughout this chapter (and indeed throughout the book), I use the term managed compiler to mean a compiler that targets the common language runtime and produces managed PE files. The term does not necessarily imply that the compiler itself is a managed application.
本章自始至终（故意贯穿本书），我使用了术语“托管编译器”示表示定位于clr并且生成托管PE文件的编译器。该术语并不表示编译器本身是一个托管应用程序。