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)