Win32 二进制资源格式（续一）

1.概述

本文档详细描述了Windows 32 API(Windows NT 3.1 和 Win32s)的二进制资源文件（.res）格式的结构。它与现有的Windows 16(Win 3.0/3.1)结构基本相似，但支持了更多更好的新特性，比如UNICODE字符串、版本头和双字对齐等等。因此若想支持这些新特性，资源编译器所生成的文件格式必须相对于Windows 16 有所改变。

1.1 Windows 3.0/3.1 与 Windows 32 对比

Windows 16资源文件包含了一个以上的二进制资源。每个资源都前置一个可变长度的数据结构，它包含：类型、名称、标志和大小。类型与名称域包含一个标识此类型的字符串或一个标识此资源ID的单字值。标志域告诉系统应当如何将此资源载入内存，大小域指出了资源的大小，以字节为单位。因此大小域实际上就是一个指向文件中下一个资源的指针。

Windows 32（NT和Win32s）资源文件继承了此节构，并扩充了头信息，增加了几个域。而且给一些预定义资源（如菜单和对话框）增加了一些域，并使这些结构能够单字或双字对齐，以及增加了UNICODE（16位字符）支持。

还有一个不同点，不过它没什么重要性。它不直接影响资源文件的结构，不过它影响了资源文件是如何合并在可执行文件中的方法。Windows NT使用COFF格式对象。因此，实际上Windows 32可执行文件格式与Windows 16大相径庭，SDK提供了一个转换工具：CVTRES，用来将一个资源文件转换为COFF对象。连接器会直接将这个对象合并到最终的可执行文件中去。和Windows 16一样，不能仅通过多次运行资源编译器来更新资源：必须重新进行连接。

不过Windows 32 API 提供了一些API，使程序可以枚举可执行文件内的所有资源，并可以单独更新其中的资源。

1.2 UNICODE字符串

资源文件中的所有字符串现在都存储为UNICODE格式。在这种格式下，所有的字符都由一个16位（单字）值表示。最开始的128个字符与Windows ANSI字符集完全相同（但这些字符都以16位格式存在，而不是8位）。第160－254个字符与标准Windows字符集相同（注意：第128－159个字符是非法Unicode代码点(codepoint)）。这意味着字符串将以UNICODE_NULL结束，而不是单独一个NULL。资源编译器调用Windows API 中的MultiByteToWideChar函数将ASCII字符串转换位UNICODE字符串。所有溢出(escaped)的字符都被当作合法UNICODE字符直接存储。当这些字符串被程序以ASCII字符读出（例如使用LoadString API）时，系统将把它们再由UNICDOE转换为ASCII字符。

仅有的例外是在RCDATA语句中的字符串。这些“伪”字符串并不是真正的字符串，只被当作一些字节的集合。用户可能会用RCDATA语句存储一些自定义的数据结构，认为确定的数据会被存储在确定的位移。如果一个“伪”字符串被自动转换为UNICODE字符串存储起来，可想而知会发生什么样的事情。因此这些“伪”字符串必须以它的本来面目存储下来：ASCII字节。若想在RCDATA语句中包含UNICODE字符串，用户可以使用L前缀的字符串。

1.3 双字(DWORD)对齐

为使二进制资源文件更容易读写，在Windows 32下，文件中的所有对象都是双字对齐的。包括头信息（headers）和数据项（data entries）。这并不会改变资源数据结构中域的顺序，但会在这些域中间增加一些填充域。

font和fontdir结构是仅有的一个例外。因为这两个结构是直接拷贝自别的文件的，它们并不被RC(Resource Compiler,资源编译器)所使用。