孟岩《来自巴西的Lua语言新星让我脸红》及网友评论

一种自由软件的脚本语言 Lua ，由于在游戏界日益成为主流脚本语言（得到著名的卢卡斯艺术公司两款游戏采用，并在GameDev.net的调查中高居脚本语言榜首），最近引起了业界的广泛关注。
Lua （葡萄牙语，义为月亮）是一种轻量级的强大的扩展语言，用纯ANSI C编写，最初版本只有6000行代码，却实现了垃圾收集、反射、面向对象等机制。Lua 是由巴西里约热内卢天主教大学计算机系的Roberto Ierusalimschy 等人于1993年开发的。
最近，Roberto Ierusalimschy 撰写的《Programming in Lua》一书也已经出版
---tangl_99

Python是荷兰人写的，Ruby是日本人写的，Lua是巴西人写的，我这个中国人只能在这里脸红。
---孟岩

不必人人制轮胎，难道你不想躺在轮胎做的吊床上休息？
---牡蛎

只选对的，不选贵的。
---路人甲

转载自tangl_99的blog和孟岩的blog

Python是荷兰人写的，Ruby是日本人写的，Lua是巴西人写的，我这个中国人只能在这里脸红。
Lua是所有动态语言中间平均效率最高的一个。它最初是以Library的形式存在，纯粹只是用作C/C++的一个扩展。现在不仅发展出了解释器，还发展 出了编译器。游戏开发里Lua是使用最广泛的脚本语言。当世界上第一本Lua图书上市销售的时候，一位读者评价道："Lua is a real gem."
（牡蛎到没有听过Lua、Python或者Ruby的编译器——.NET的冒牌货除外）

Lua很棒，Lua是巴西人发明的，这些都令我不爽，但是还不至于脸红，最多眼红。
让我脸红的是Lua的源代码，百分之一百的ANSI C，一点都不掺杂。在任何支持ANSI C编译器的平台上都可以轻松编译通过。我试过，真是一点废话都没有。
我1996年就学会了C，1997年就跑去研究Win32 API，后来是C++，STL，Java... 直到2002年看到C Interfaces and Implementations，才知道仅仅用ANSI C就可以实现一个强大的优美的library，直到2004年看到Lua的源代码才知道仅仅用ANSI C就可以实现一个非常快的虚拟机、非常棒的解释器/编译器和非常漂亮的语言实现。
这8年我都干什么去了？
---孟岩

http://www.chinaitpower.com/2005September/2005-09-13/204728.html

Complete syntax of Lua in extended BNF

Complete syntax of Lua in extended BNF. (It does not describe operator precedences.)

 chunk ::= {stat [`;´]} [laststat [`;´]]

 block ::= chunk

 stat ::=  varlist1 `=´ explist1 |
   functioncall |
   do block end |
   while exp do block end |
   repeat block until exp |
   if exp then block {elseif exp then block} [else block] end |
   for Name `=´ exp `,´ exp [`,´ exp] do block end |
   for namelist in explist1 do block end |
   function funcname funcbody |
   local function Name funcbody |
   local namelist [`=´ explist1]

 laststat ::= return [explist1] | break

 funcname ::= Name {`.´ Name} [`:´ Name]

 varlist1 ::= var {`,´ var}

 var ::=  Name | prefixexp `[´ exp `]´ | prefixexp `.´ Name

 namelist ::= Name {`,´ Name}

 explist1 ::= {exp `,´} exp

 exp ::=  nil | false | true | Number | String | `...´ | function |
   prefixexp | tableconstructor | exp binop exp | unop exp

 prefixexp ::= var | functioncall | `(´ exp `)´

 functioncall ::=  prefixexp args | prefixexp `:´ Name args

 args ::=  `(´ [explist1] `)´ | tableconstructor | String

 function ::= function funcbody

 funcbody ::= `(´ [parlist1] `)´ block end

 parlist1 ::= namelist [`,´ `...´] | `...´

 tableconstructor ::= `{´ [fieldlist] `}´

 fieldlist ::= field {fieldsep field} [fieldsep]

 field ::= `[´ exp `]´ `=´ exp | Name `=´ exp | exp

 fieldsep ::= `,´ | `;´

 binop ::= `+´ | `-´ | `*´ | `/´ | `^´ | `%´ | `..´ |
   `<´ | `<=´ | `>´ | `>=´ | `==´ | `~=´ |
   and | or

 unop ::= `-´ | not | `#´

run_xiao2000:tiny解析的功能上增加了线程和缓存的功能

昨天在tiny解析的功能上增加了线程和缓存的功能，在我机器上Run了几次，基本上起两个线程耗费的时间是一个线程的两倍左右。想想自己机器是单核的，让prolj兄帮忙在他双核机器上run了一下，降到1.5倍左右。

跟当初设想的差距还是挺大，难度线程的切换和同步这么耗时间？


我把程序传上来，双核机器的兄弟可以帮我Run起来试试看

make multi:两个线程运行
make single:单线程运行

http://linux.chinaunix.net/bbs/attachment.php?aid=184614

Grid平台上的NGS编译技术

随 着网络技术的发展,在异构平台上使用共同的计算和信息资源将很快成为可能.Grid(网格)就是这样一种提供资源共享的新兴平台,而在其之上的下一代软件 程序(NGS)则对编译器提出了新的挑战[1].未来Grid平台上的编译系统将是能够进行动态编译和优化,根据实时系统以及网络的性能不断进行自我调整 的软件模型,同时它还能为具有自适应性的应用程序提供编译支持.

http://scholar.ilib.cn/Abstract.aspx?A=jsjgcyyy200324027

[Intro]Quick Build

QuickBuild is the professional version of the popular open source build server, Luntbuild. It is a cross-platform build automation and management server that unifies all levels of builds such as continuous integration, daily build, QA and release build. Build can be promoted from one level to another, triggering desired steps such as sending notification, source code re-labeling, etc. QuickBuild enables a build-centric process to drive the smooth delivery of builds between different groups of the team, for example, from developer to QA, from QA to release manager, etc.

http://www.pmease.com/app.do

DFA压缩论文链接

DFA压缩
http://linux.chinaunix.net/bbs/attachment.php?aid=211199

ANTLRWorks: The ANTLR GUI Development Environment

ANTLRWorks: The ANTLR GUI Development Environment

ANTLRWorks is a novel grammar development environment for ANTLR v3 grammars written by Jean Bovet (with suggested use cases from Terence Parr). It combines an excellent grammar-aware editor with an interpreter for rapid prototyping and a language-agnostic debugger for isolating grammar errors. ANTLRWorks helps eliminate grammar nondeterminisms, one of the most difficult problems for beginners and experts alike, by highlighting nondeterministic paths in the syntax diagram associated with a grammar. ANTLRWorks' goal is to make grammars more accessible to the average programmer, improve maintainability and readability of grammars by providing excellent grammar navigation and refactoring tools, and address the most common questions and problems encountered by grammar developers:

• Why is this grammar fragment nondeterministic?
• Does this rule match a sample input?
• Why is this grammar improperly matching this complete input?
• Why is there a syntax error given this input?
• Why is there no syntax error given this ungrammatical input?

ANTLRWorks speeds up development for experts and beginners alike.

D语言

Digital Mars C and C++ Compilers for Win32, Win16, DOS32 and DOS. Fastest compile/link times, powerful optimization technology, Design by Contract, complete library source, HTML browsable documentation, disassembler, librarian, resource compiler, make, etc., command line and GUI versions, tutorials, sample code, online updates, Standard Template Library, and much more.

D Programming Language spec

http://www.digitalmars.com/

沉积2+年，CodeBlocks升级！

Code::Blocks 8.02 has been released!
Thursday, 28 February 2008 18:34
Our long awaited release is finally here! Representing the hard work of 14+ developers for more 2+ years since our last official release (and many changes in the roadmap in between), it is finally made available to the general public.
For your convenience, we provide binaries for all platforms Code::Blocks supports:
Windows 2000 / XP / Vista
Linux (Ubuntu & Debian, 32 & 64 bits)
MacOSX 10.4+
Binaries for other Linux distros will be made available in the following days. So, without further ado, head over to the downloads section and get it while it's hot!
The Code::Blocks Team

http://www.codeblocks.org/

PE format

All you can find @
http://www.qqread.com/file-format/f348176_4.html

PE Format(23)

第一，当数组中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文件需要重定位时。

确定有没有重定位表对加载器来说不是问题，但该怎样找出版本的不同呢？这时IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的“时间戳”就派上用场了。如果它是0，表明输入列表没有被绑定，加载器总是要修复入口点。否则的话，输入被绑定，“时间戳”必须要和“文件头”中的输出DLL文件的“时间戳”相符；如果不符的话，加载器就认为该二进制文件被绑到一个“错误”的DLL文件上并重新补正输入列表。

　　这里有另外一个有关输入列表中的“中转”的怪事。一个DLL文件能输出一个不定义在本DLL文件中却需从另一个DLL文件中输入的符号；这样的符号据说就是被中转的（参见上面的输出目录描述）。

现在，很明显的，你不能通过查看那个实际上并不包含入口点信息的DLL文件的时间戳来确定一个符号的入口点是否有效。因此，出于安全的原因，中转符号的入口点必须总是被修正。在二进制文件的输入列表中，中转符号的输入必须被找出，以便加载器能补正它们。

PE Format(22)

总结一下：如果你想从“knurr”DLL中查找输入函数“foo”的信息，第一步你先找到数据目录中的 IMAGE_DIRECTORY_ENTRY_IMPORT（输入目录项）项，得到一个RVA，再在原始节数据中找到那个地址，现在你就得到一个 IMAGE_IMPORT_DESCRIPTOR（输入描述结构）数组了。
通过查看根据它们的“名称”被指向的字符串，得到和“knurr”DLL有关的这个数组的成员（即一个输入描述结构）。在你找到正确的IMAGE_IMPORT_DESCRIPTOR（输入描述结构）后，顺着它的“OriginalFirstThunk”（原始第一个换长）得到被指向的IMAGE_THUNK_DATA（换长数据）数组；再通过查询RVA找到“foo”函数。

　　好了，为什么我们有“两”列指向IMAGE_IMPORT_BY_NAME（输入名字）的指针呢？这是因为在运行时，应用程序不需要输入函数的名字，只需要地址。在这里输入地址表又出现了。加载器将从相关的DLL文件的输出目录中查找每一个输入符号，并用DLL文件入口点的线性地址替换“FirstThunk”（第一个换长）列表中的IMAGE_THUNK_DATA（换长数据）元素（到现在之前它还是指向 IMAGE_IMPORT_BY_NAME（输入名字）的）。

请记住带有象“__imp__symbol”标签的地址列表；被数据目录IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）所指向的输入地址表，就是被“FirstThunk”（第一个换长）所指向的列表。[在从好几个DLL文件输入的情况下，输入地址表是包含所有DLL文件的“FirstThunk”（第一个换长）数组。目录项 IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）可能会丢失，但输入（函数）仍能工作良好。]

　　“OriginalFirstThunk”（原始第一个换长）数组保持不变，因此你总能通过“OriginalFirstThunk”（原始第一个换长）列表查找原始的输入名字列表。

　　现在输入已经被用正确的线性地址修正，如下所示：
　　　原始第一个换长　　　　第一个换长
　　　　　　|　　　　　　　　　　|
　　　　　　|　　　　　　　　　　|
　　　　　　|　　　　　　　　　　|
　　　　　　V　　　　　　　　　　V
　　　　　　0-->　　函数1　　　　0-->　输出函数1
　　　　　　1-->　　函数2　　　　1-->　输出函数2
　　　　　　2-->　　函数3　　　　2-->　输出函数3
　　　　　　3-->　　foo　　　　　3-->　输出函数foo
　　　　　　4-->　　mumpitz　　　4-->　输出函数mumpitz
　　　　　　5-->　　knuff　　　　5-->　输出函数knuff
　　　　　　6-->0　　　　　　0<--6

这是简单情况下的基本结构。现在我们将要学习输入目录中的需细讲的东西。

PE Format(21)

ForwarderChain（中转链）

　　它是输入函数列表中第一个中转的、32位的索引。中转也是高级的东东。对初学者先将所有位设为-1。

　　Name（名称）

　　它是一个DLL文件的名称（0结尾的ASCII码字符串）的、32位的RVA。

　　FirstThunk（第一换长）

　　它也是一个RVA（32位），指向一个0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组是输入地址表的一部分，并且可以改变。

　　因此，数组中的每个IMAGE_IMPORT_DESCRIPTOR（输入描述结构）结构体都给出输出DLL文件的名称，并且，除了中转和时间日期戳，它还给出2个指向IMAGE_THUNK_DATA（换长数据）的数组的RVA，都是32位。（每个数组的最后一个成员都全部填充为0字节，以标志结尾。）

　　目前看来，每个IMAGE_THUNK_DATA（换长数据）都是一个RVA，指向一个描述输入函数的IMAGE_IMPORT_BY_NAME（输入名字）项。

　　现在，有趣的是两个数组并行运行，也就是说:它们指向同一组IMAGE_IMPORT_BY_NAME（输入名字）。

　　没有必要失望，我将再画一图。这里是IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的关键内容：
　　　原始第一个换长　　　　第一个换长
　　　　　　 |　　　　　　　　　　|
　　　　　　 |　　　　　　　　　　|
　　　　　　 |　　　　　　　　　　|
　　　　　　 V　　　　　　　　　　V
　　　　　　 0-->　　函数1　　<--0
　　　　　　 1-->　　函数2　　<--1
　　　　　　 2-->　　函数3　　<--2
　　　　　　 3-->　　foo　　　<--3
　　　　　　 4-->　　mumpitz　<--4
　　　　　　 5-->　　knuff　　<--5
　　　　　　 6-->0　　　　　　0<--6　　　/*最后的RVA是0!*/

　　图当中的名字就是尚未讨论的IMAGE_IMPORT_BY_NAME（输入名字）。每一个都是一个16位的数字（一个提示）跟着一些数量未定的字节，它们都是以0结尾的、输入符号的ASCII码名字。

　　提示就是指向输出DLL文件名字表的索引（参见上面的输出目录）。那个索引中的名字将被一一尝试，如果没有相符的，再使用二进制搜索来寻找名字。

　　（有些链接器不愿意查找正确的提示，总是只简单的将其指定为1，或者其它的随意数字。这并无大害，只是使解决名字的第一次尝试总是失败，并迫使每个名字都使用二进制搜索来进行。）

PE Format(20)

不管怎样，符号“x”的地址都被存在“__imp_x”的存储单元。所有这样的存储单元一起形成所谓的“输入地址表”，此表是由被用到的各DLL文件中的输入库提供给链接器的。输入地址表就是由下面这种形式的一组地址组成的：
　__imp__symbol:　0xdeadbeef
　 __imp__symbol2:　0x40100
　 __imp__symbol3:　0x300100
　 ...

　　这个输入地址表是输入目录的一部分，并且被IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录指针所指向（尽管有些链接器不设置此目录项，程序也能运行；很明显地，这是因为加载器不使用IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录也能解决输入问题）。

　　这些地址并不被链接器所知；链接器只插入一些伪地址（函数名称的RVA；参见后面的更多信息），这些伪地址会在载入时被加载器用输出DLL文件中的输出目录来修正。输入地址表，以及它是怎样被加载器找到的，将会在本章的后面被详细讲述。

　　注意:这个介绍是针对C语言规范的；有些别的应用程序构建环境是不使用输入库的，尽管它们都需要建立一个输入地址表，用来让它们的程序访问输入对象和函数。C语言编译器往往使用输入库，因为无论如何讲，这都有利于它们----它们的链接器使用好库。别的环境使用的是例如：一个列出需要的DLL文件名称和函数名称的描述文件（比如“模块定义文件”），或者一个源文件中的声明形式的列表等。

　　这就是程序的代码如何使用输入函数的；现在我们再来看看输入目录是如何建立以便加载器使用的。

　　输入目录应该存在于是“已初始化数据”并且“可读”的节中。

　　输入目录是一个多IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的数组，每个被使用的DLL文件都有一个。（它们的）列表由一个全部用0填充的IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）结构作为结束。

　　一个IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）是一个拥有下列成员的结构体：

　　OriginalFirstThunk（原始第一个换长）（汉译的说明见注释）

　　它是一个RVA（32位），指向一个以0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组永不改变。

　　TimeDateStamp（时间日期戳）

　　它是一个具有好几个目的的32位的时间戳。让我们先假设时间戳为0，一些高级的情况将在以后处理。

PE Format(19)

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指令的存根只合适于函数。）

PE Format(18)

符号名称可能会全部丢失，此时“AddressOfNames”（名字的地址）为0；否则，被指向的数组并行运行，这意味着它们的每个索引中的元素共同拥有。
“AddressOfNames”（名字的地址）数组由以0结尾的输出名称的RVA组成；这些名称以一个分类的列表排列（即：数组的第一个成员是按照字母顺序排列的最小的名称的RVA；这使当按名称查找一个输出符号时，搜索的效率更高。）

　　根据PE规范，“AddressOfNameOrdinals”（名字序数的地址）数组每个名称拥有一个相应的序数，然而，我发现这个数组却将实际的索引包含到“AddressOfFunctions”（函数地址）数组中去。

　　我将画一个有关这三个表的图：
　　　　函数地址
　　　　　　 |
　　　　　　 |
　　　　　　 |
　　　　　　 v
　　 带序数‘基址’的输出RVA
　　 带序数‘基址+1’的输出RVA
　　 ...
　　 带序数‘基址+函数数-1’的输出RVA
　　　 名字地址　　　　　　　　　　　名字序数地址
　　　　　 |　　　　　　　　　　　　　　　|
　　　　　 |　　　　　　　　　　　　　　　|
　　　　　 |　　　　　　　　　　　　　　　|
　　　　　 v　　　　　　　　　　　　　　　v
　　　 第一个名字的RVA　　　<->　　第一个名字的输出索引
　　　 第二个名字的RVA　　　<->　　第二个名字的输出索引
　　　 ...　　　　　　　　　　　　　　...
　　 第‘名字数’个名字的RVA　<->　第‘名字数’个名字的输出索引

　　举一些例子是适宜的。

　　为按序数找到一个输出符号，先减去“Base”（基址）值以得到索引值，再根据“AddressOfFunctions”（函数地址）的RVA得到输出项数组，并用索引值去找到数组中的输出RVA。如果结果没有指向输出节中，你就完了。否则，它就指向那里的一个描述输出DLL和（输出项）名称或序数的字符串，之后你就得在那里查找中转输出。

　　为按名称找到一个输出符号，先跟随“AddressOfNames”（名字的地址）的RVA（如果是0就没有名称）找到输出名称的RVA数组。在列表中搜寻你要找的名称。用该名称在“AddressOfNameOrdinals”（名字序数的地址）数组中的索引，得到和找到的名称相应的16位数字。根据 PE规范，这是一个序数，你需先减去“Base”（基址）值以得到输出索引值；但依据我的经验，这就是输出索引值，你不需要再减了。使用输出索引值，你就能在“AddressOfFunctions”（函数地址）数组中找到输出RVA了，要么是输出RVA本身，要么是一个描述中转输出的字符串的RVA。

PE Format(17)

3-4）往后我们看到2个16位的、有关版本信息的word单元（“MajorVersion”和“MinorVersion”，含义分别为‘主版本号’和‘小版本号’），同样，它们很多地被设为0。

　　5）下一个东东是32位的“Name”（名称）；它是一个指向以0结尾的ASCII字符串为DLL名称的RVA。（为防DLL被改名时的错误，名称是必须的----参见输入目录中的“绑定”部分。）

　　6）然后是32位的“Base”（基址）。稍后我们再讨论。

　　7）下一个32位值是输出条目的总数（“NumberOfFunctions”，意为‘函数数’）。除了它们的序数外，各条目还可能使用一个或多个名称来输出。接下来的一个32位数字是输出名称的总数（“NumberOfNames”，意为‘名字数’）。

　　在大多数情况下，每一个输出条目都准确的有一个相应的名称，并且将用这个名称来使用它；但是一个条目可能拥有好几个相关联的名称（那样它们的每一个名称都可访问）；或者它也可能没有名称，此时它只能以它的序数来访问。无名输出项（只有序数）的使用是不鼓励的，因为此时输出DLL的所有版本都必须使用相同的序数法，而这会造成维护的问题。

　　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”（名字数）个元素。

PE Format(16)

典型的名称有“.bss”、“BSS”之类。

　　有些节数据“没有”被数据目录指向。它们的内容和结构是由编译器而不是链接器提供。

　　（栈段和堆段不是二进制文件中的节，它们是由加载器根据可选头中的栈大小和堆大小项来创建的。）

　　5.版权（copyright）

　　-------------------

　　为了从一个简单的目录节开始讲解，让我们来看一看数据目录“IMAGE_DIRECTORY_ENTRY_COPYRIGHT”（版权目录项）项。它的内容是一个版权信息或ASCII形式的描述字符串（不是以0结尾的），象“Gonkulatorcontrolapplication,copyright(c)1848Hugendubel&Cie”这样。这个字符串，通常，是用命令行或者描述文件提供给链接器的。

这个字符串在运行时并不需要，并可能被丢弃。它是不可写的；事实上，应用程序根本不需要存取它。因此，如果已有一个可丢弃的、非可写的节存在，链接器就会找到它；如果没有，就创建一个（命名为“.descr”之类）。然后它就将那个字符串填入该节中并让版权目录项指针指向这个字符串。“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）标志位应置为1。

　　6.输出符号（exportedsymbols）

　　------------------------------

　　（注意：本文的1993年03月12日之前的各个版本中，输出目录的描述有误。文中没有描述中转、只以序数输出、或者使用好几个名称输出等内容。）

　　下一件最简单的事情是输出目录，是由“IMAGE_DIRECTORY_ENTRY_EXPORT”（输出目录项）指向的。它是一个典型的在DLL中常见到的目录；包含一些输出函数的入口点（以及输出对象等的地址）。当然可执行文件也可能拥有输出符号但一般没有。

　　包含它们的节应该有“已初始化数据的”和“可读的”特性。这样的节应该是不可丢弃的，因为在运行时，进程有可能调用“GetProcAddress()”来寻找一个函数的入口点。如果单独成节的话，本节通常被称作“.edata”；更常见的是，它被并入象“已初始化数据”之类的节中。

　　输出表（“IMAGE_EXPORT_DIRECTORY”）的结构由一个头和输出数据，也就是：符号名称、它们的序号和它们的入口点偏移量等构成。

　　1）首先，我们有一个没被使用并通常为0的、32位的“Characteristics”（特性）。

　　2）然后是一个32位的“TimeDateStamp”（时间日期戳），大概是提供此表被创建的time_t格式的时间；天呀，它的值并不总是有效（有些链接器将它设置为0）。

PE Format(15)

首先，我将提到代码节。
此节，至少，要将“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”（未初始化数据大小）确定。

PE Format(14)

试画映象文件的全图如下：
　　+-------------------+
　　 |　　DOS-根　　　　|
　　 +-------------------+
　　 |　　　文件头　　　|
　　 +-------------------+
　　 |　　　可选头　　　|
　　 |----------|
　　 |　　　　　　　　　|----------------+
　　 |　　数据目录　　　|　　　　　　　　|
　　 |　　　　　　　　　|　　　　　　　　|
　　 |　(指向节中　　　|-------------+　|
　　 |　　目录的RVA)　　|　　　　　　|　|
　　 |　　　　　　　　　|---------+　|　|
　　 |　　　　　　　　　|　　　　|　|　|
　　 +-------------------+　　　　|　|　|
　　 |　　　　　　　　　|-----+　|　|　|
　　 |　　　节头　　　　|　　|　|　|　|
　　 |　　(指向节　　　|--+　|　|　|　|
　　 |　　边界的RVA)　　|　|　|　|　|　|
　　 +-------------------+<-+　|　|　|　|
　　 |　　　　　　　　　|　　|<-+　|　|
　　 |　　　节数据1　　|　　|　　　|　|
　　 |　　　　　　　　　|　　|<-----+　|
　　 +-------------------+<----+　　　　　|
　　 |　　　　　　　　　|　　　　　　　　|
　　 |　　　节数据2　　|　　　　　　　　|
　　 |　　　　　　　　　|<--------------+
　　 +-------------------+

　　每个节都有一个节头，并且每个数据目录都会指向其中的一个节（几个数据目录有可能指向同一个节，而且也可能有的节没有数据目录指向它们）。

　　八、节的原始数据（Sections'rawdata）

　　--------------------------------------

　　1.概述（general）

　　-------

　　所有的节在载入内存后都按“SectionAlignment”（节对齐）对齐，在文件中则以“FileAlignment”（文件对齐）对齐。节由节头中的相关项来描述：在文件中你可通过“PointerToRawData”（原始数据指针）来找到，在内存中你可通过“VirtualAddress”（虚拟地址）来找到；长度由“SizeOfRawData”（原始数据长度）决定。

　　根据节中包含的内容，可分为好几种节。大多数（并非所有）情况下，节中至少由一个数据目录，并在可选头的数据目录数组中有一个指针指向它。

　　2.代码节（codesection）

PE Format(13)

位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”（虚拟地址）的值来找到各节，因此实际上根本没必要在对齐上小题大做。

PE Format(12)

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，表示节在执行开始前应该被页载入？此位的含义不明。

PE Format(11)

输入地址表-参见输入目录的描述。

　　试举一例，如果我们在索引7中发现2个longword：0x12000和33,并且载入地址为0x10000,那么我们就知道版权信息数据位于地址0x10000+0x12000（在哪个节都有可能）处，并且版权信息有33字节长。

　　如果二进制文件中没有使用特殊类型的目录，Size（大小）和VirtualAddress（虚拟地址）的值就都为0。

　　七、节目录（Sectiondirectories）

　　---------------------------------

　　节由两个主要部分组成：首先，是一个节描述(IMAGE_SECTION_HEADER[意为“节头”]类型的)，然后是原始的节数据。因此，我们会在数据目录后发现一“NumberOfSections”个节头组成的数组，它们按照各节的RVA排序。

　　节头包括：

　　1）一个IMAGE_SIZEOF_SHORT_NAME(8)（意为“短名的大小”）个字节的数组，形成节的名称（ASCII形式）。如果所有的8位都被用光，该字符串就没有0结束符！典型的名称象“.data”或“.text”或“.bss”形式。开头的“.”不是必须的，名称也可能为“CODE”或“IAT”或类似的形式。

　　请注意：并不是所有的名称都和节中的内容相关。一个名叫“.code”的节可能包含也可能不包含可执行代码；它还可能只包含输入地址表；它也可能包含代码“和”地址表“和”未初始化数据。要找到节中的信息，你必须通过可选头的数据目录来查询它。既不要过分相信它的名称，也不要以为节的原始数据会从节的开头就开始。

　　2）IMAGE_SECTION_HEADER（“节头”）的下一个成员是一个32位的、“PhysicalAddress（物理地址）”和“VirtualSize（虚拟大小）”组成的共用体。在目标文件中，它是内容重定位到的地址；在可执行文件中，它是内容的大小。事实上，此域似乎没被使用；因为有的链接器输入大小，有的链接器输入地址，我还发现有一个链接器输入0，而所有的可执行文件都运行如风。

　　3）下一个成员是“VirtualAddress（虚拟地址）”，是一个32位的值，用来保存载入RAM（内存）后，节中数据的RVA。

　　4）然后，我们到了32位的“SizeOfRawData”（意味“原始数据大小”），它表示节中数据被大约到下一个“FileAlignment”的整数倍时节的大小。

　　5）下一个是“PointerToRawData”（意味“原始数据指针”，32位），它特别有用，因为它是从文件的开头到节中数据的偏移量。如果它为0，那么节的数据就不包含在文件中，并且要在载入时才定。

PE Format(10)

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中给定的大小。

　　稍后我将讨论我知道其结构的目录。

　　已定义的目录及索引有:

　　IMAGE_DIRECTORY_ENTRY_EXPORT(0)

　　输出符号目录；大多用于DLL文件。

　　后面介绍。

　　IMAGE_DIRECTORY_ENTRY_IMPORT(1)

　　输入符号目录；参见后面。

　　IMAGE_DIRECTORY_ENTRY_RESOURCE(2)

　　资源目录。后面介绍。

　　IMAGE_DIRECTORY_ENTRY_EXCEPTION(3)

　　异常目录-结构和用途不详。

　　IMAGE_DIRECTORY_ENTRY_SECURITY(4)

安全目录-结构和用途不详。

　　IMAGE_DIRECTORY_ENTRY_BASERELOC(5)

　　基址重定位表-参见后面。

　　IMAGE_DIRECTORY_ENTRY_DEBUG(6)

　　调试目录-内容编译器相关。此外,许多编译器将编译信息填入代码节，并不为此创建一个单独的节。

　　IMAGE_DIRECTORY_ENTRY_COPYRIGHT(7)

　　描述字符串-一些随意的版权信息之类。

　　IMAGE_DIRECTORY_ENTRY_GLOBALPTR(8)

　　机器值(MIPSGP)-结构和用途不详。

　　IMAGE_DIRECTORY_ENTRY_TLS(9)

　　线程级局部存储目录-结构不详；包含声明为“__declspec(thread)”的变量,也就是每线程的全局变量。

　　IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG(10)

　　载入配置目录-结构和用途不详。

　　IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT(11)

　　绑定输入目录-参见输入目录的描述。

　　IMAGE_DIRECTORY_ENTRY_IAT(12)

PE Format(9)

映象文件是一个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文件没有自己的堆或栈，所以它们的映象文件忽略这些值。我不知道驱动程序是否有它们自己的堆或栈，但我认为它们没有。

PE Format(8)

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)

PE Format(7)

8-9）下两个32位值分别是可执行代码的偏移值（‘BaseOfCode’，“代码基址”）和已初始化数据的偏移值（‘BaseOfData’，“数据基址”），两个都是RVA，并且两个对我们来说都没有多少意义，
因为你可以通过查看可选头后面的各个“节”来获得更可靠的信息。

　　未初始化的数据没有偏移量，正因为它没有初始化，所以在映象文件中提供这些数据是没有用处的。

　　10）下一项是个32位值，提供整个二进制文件包括所有头的优先（线性）载入地址(‘ImageBase’，“映象文件基址”)。这是一个文件已被链接器重定位后的地址（总是64KB的倍数）。如果二进制文件事实上能被载入这个地址，那么加载器就不用再重定位文件了，也就节省了一些载入时间。

　　优先载入地址在另一个映象文件已被先载入那个地址（“地址冲突”，在当你载入好几个全部按照链接器的缺省值重定位的DLL文件时经常发生）时，或者该内存已被用于其它目的（堆栈、malloc ()、未初始化数据、或不管是什么）时，就不能用了。在这些情况下，映象文件必须被载人其它的地址，并且需要重定位（参见下面的“重定位目录”）。如果是一个DLL文件，这么做还会产生其它问题，因为此时的“绑定输入”已不再有效，所以使用DLL的二进制文件必须被修正----参见下面的“输入目录”一节。

　　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'“映象文件小版本号”)。很多链接器不正确地设定这个信息，许多程序员也懒得提供这些，因此即便存在这样的信息，你最好也不要信赖它。

PE Format(6)

上一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 下一页

　　试举一例，假若你已知道执行开始处位于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()的地址。如果你敢于“手工”装载映象文件，那么在你完成所有的修正和重定位后，你可以从这个地址开始执行你的进程。

PE Format(5)

位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地址的信息，你得按照文件已被载入时的那样来计算偏移量，但要按照文件的偏移量来跳过。

PE Format(4)

这个时间戳是用来绑定各个输入目录的，我们稍后再讨论它。

　　警告：有一些链接器往往将时间戳设为荒唐的值，而不是如前所述的time_t格式的链接时间。

　　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（此位也不用于可执行文件）。

位4IMAGE_FILE_AGGRESIVE_WS_TRIM（强行工作集修剪文件）表示如果操作系统被假定为：通过将正在运行的进程（它所使用的内存数量）强行的页清除来修剪它的工作集时，此位置1。如果一进程是大部分时间处于等待，且一天中仅被唤醒一次的演示性的应用程序之类时，此位也应该被置1。

　　位7IMAGE_FILE_BYTES_REVERSED_LO（低字节变换文件）和位15IMAGE_FILE_BYTES_REVERSED_HI （高字节变换文件）表示如果一文件的字节序不是机器所预期的形式，因此它在读入前必须调换字节时，此位置1。这样做对可执行文件是不可靠的（操作系统期望可执行文件都已经被正确地按字节排整齐了）。

　　位8IMAGE_FILE_32BIT_MACHINE（32位机器文件）表示如果使用的机器被期望为32位的机器时，此位置1。现在的应用程序总将此位置1；NT5系统可能工作不同。

PE Format(3)

你可以通过确认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处理器或更高

　　0x014d

　　Intel80386处理器或更高

　　0x014e

　　Intel80386处理器或更高

　　0x0160　　　　　

　　R3000(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位的值。它是紧跟在头后面的节的数目。我们以后将讨论节的问题。

　　3）下一个成员是时间戳“TimeDateStamp”（32位），用来给出文件建立的时间。即使它的“官方”版本号没有改变，你也可通过这个值来区分同一个文件的不同版本。（除了同一个文件的不同版本之间必须唯一，时间戳的格式没有明文规定，但似乎是按照UTC时间“从1970年1月1日00: 00:00算起的秒数值”----也就是大多数C语言编译器给time_t标志使用的格式。）

PE Format(2)

可选头的一个有趣的部分是尾部的“数据目录”数组；这些目录包含许多指向各“节”数据的指针。
例如：如果一个二进制文件拥有一个输出目录，那么你就会在数组成员“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”之类的错误信息。

“PE文件格式”1.9版 完整译文（附注释）

原著：Bernd.Luevelsmeyer　　　　　　　　　　　　　　　

　　翻译：ah007

　　[注意：本译文的所有大小标题序号都是译者添加，以方便大家阅读。圆圈内的数字是注释的编号，其中注释②译自微软的《PECOFF规范》，其它译自网络。----译者]

　　一、前言（Preface）

　　------------------

PE（“portableexecutable”，可移植的可执行文件）文件格式，是微软WindwosNT,Windows95和Win32子集①中的可执行的二进制文件的格式；在WindowsNT中，驱动程序也是这种格式。它还能被应用于各种目标文件②和库文件中。

　　这种文件格式是由微软设计的，并于1993年被TIS（toolinterfacestandard,工具接口标准）委员会（由Microsoft,Intel,Borland, Watcom,IBM,等等组成）所批准，它明显的基于COFF文件格式的许多知识。COFF（“commonobjectfilefromat”,通用目标文件格式）是应用于好几种UNIX系统③和VMS④系统中的目标文件和可执行文件的格式。

　　Win32SDK⑤中包含一个名叫的头文件，其中含有很多用于PE格式的#define和typedef定义。我将逐步地提到其中的很多结构成员名字和#define定义。

　　你也可能发现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格式），用来说明该二进制文件将运行在何种机器之上、分几个区段、链接的时间、是可执行文件还是DLL、等等。（本文中可执行文件和DLL文件的区别在于：DLL文件不能被启动，但能被别的二进制文件使用，而一个二进制文件则不能链接到另一个可执行文件。）

　　那些之后，是可选头（尽管它一直都存在，却仍被称作“可选”----因为COFF文件格式仅为库文件使用一个“可选头”，却不为目标文件使用一个“可选头”，这就是为什么它被称为“可选”的原因）。它会告诉我们该二进制文件怎样被载入的更多信息：开始的地址呀、保留的堆栈数呀、数据段的大小呀、等等。