前幾天公司里一個項目要做 MUI 支持，于是要生成一堆 XXX.dll.mui 的文件。如果這些 MUI DLL 的工程手動去建立、維護的話，那就太!@#@!#!了。當時是另外一個同事去做這方面的工作的，后來他給了個工具，按照它定義的簡單格式來書寫多語言字符串，這個工具會從一個已經設定好的 DLL 項目出發，更改 RC 文件里的字符串，然后調用 VS 的 IDE 來生成 DLL。再然后調用 MUIRCT.exe 來生成 MUI 文件。

這可以節省很多時間。但是，由于是調用 VS IDE 來編譯的，一個帶有近百個 Project 的 Solution 編譯起來并不快，需要一到兩分鐘。這讓我有了另辟蹊徑的念頭。

何不自己來“編譯”生成 DLL 呢？

不錯，后來我就往這個方向琢磨了。之前曾寫過一個修改 PE 文件版本號的小工具，所以現在對于 PE 的資源格式有點并不那么恐懼了。但是，往細處做下去，問題就來了。現在網上的關于 PE 格式的文章，對 NTHeader 解釋得很詳細，而資源段往往只講到資源目錄、資源項，具體各項的存儲結構卻沒有詳細說明了。

這里，關于 PE 頭等就不多說了，請參考網上的文章，特別是 http://bbs.pediy.com/showthread.php?threadid=21932。本文將著眼于資源段。

首先來看一下幾個數據結構（這些內容好多文章也有提及）：

typedef struct _IMAGE_RESOURCE_DIRECTORY {
    DWORD   Characteristics;
    DWORD   TimeDateStamp;
    WORD    MajorVersion;
    WORD    MinorVersion;
    WORD    NumberOfNamedEntries;
    WORD    NumberOfIdEntries;
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

這是資源目錄，共 16 字節，其中最后兩個 WORD 加起來是緊跟在后面的子項的數目。

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
    union {
        struct {
            DWORD NameOffset:31;
            DWORD NameIsString:1;
        };
        DWORD   Name;
        WORD    Id;
    };
    union {
        DWORD   OffsetToData;
        struct {
            DWORD   OffsetToDirectory:31;
            DWORD   DataIsDirectory:1;
        };
    };
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

這個就是緊跟在目錄后面的資源目錄項，共 8 字節。其中第一個成員為數據成員，最高位 1 表示數據是字符串，剩下 31 位是字符串的偏移；否則就是數值。第二個成員最高位為 1 表示下一層仍然是目錄，后 31 位指向另一個 IMAGE_RESOURCE_DIRECTORY 結構；否則整個成員指向一個 IMAGE_RESOURCE_DATA_ENTRY 結構（這個馬上會講到）。需要注意的是，這里的兩個 Offset 都表示從資源段開頭到目標位置的偏移。

最后來看 IMAGE_RESOURCE_DATA_ENTRY：

typedef struct _IMAGE_RESOURCE_DATA_ENTRY {
    DWORD   OffsetToData;
    DWORD   Size;
    DWORD   CodePage;
    DWORD   Reserved;
} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

這個結構是資源數據項，也就是資源樹的葉子，共 16 字節。其中第一個成員 OffsetToData 指向具體的數據，這個偏移是個 RVA，跟前面兩個不一樣。Size 表示具體數據的總字節數。后兩個成員可以為 0，CodePage 不建議使用。

PE 文件中的資源就是通過這三個結構表示的，它們都在 WinNT.h 中定義。通常會有 3 層結構，第一層表示資源類型，第二層表示 ID，第三層標識語言。

以上所說的是我能查到的資料里能夠提到的最大程度的內容了。但是具體的數據如何存儲，卻幾乎沒有文章提及。于是，花了一兩天時間來慢慢的看、加上試驗，我認為我對字符串資源的格式基本清楚了。（下面內容是我自己分析得出，其正確性我并不保證）。

我們先來看一個具體的例子。這是一個資源 DLL，用 Resource Hacker 查看如圖：

其資源段數據如下：

我用桔色框起來的是資源目錄，用粉色框起來的是資源目錄項，用淺綠色框起來的是資源數據項。

先看第一行，這是第一層目錄，最后兩個 WORD 是 0x0000 和 0x0001，表示后面“命名”的目錄項有 0 個，使用 ID 的目錄項有 1 個。第二行開頭的 8 字節就是這個目錄項，DWORD 0x00000006 表示資源類型是 6，也就是字串表，后面的地址是 0x80000018，最高位為 1，表示指向的仍然是一個目錄，其偏移是 0x00000018，也就是 0218h 處。

0218h 處這個資源目錄是第二層了。最后仍然是 0 和 1，于是我們來看 0228h 處的目錄項。第一個 DWORD 是 1，這個跟 ID 有關，稍候討論。他的第二個 DWORD 是 0x80000030，仍然指向目錄。

0230 處的目錄是第三層目錄。注意到最后是 0 和 2，下面將有連續兩個目錄項。第一個目錄項值為 0x00000409（1033，英語(美國)），偏移地址 0x00000050，最高位 0，表示指向的是數據項，而不是目錄了。第二個目錄項值為 0x00000804（2052，中文(中國)），偏移地址 0x0000009C。

這三層結構和 Resource Hacker 中顯示的是一一對應的。

我們先來看英語的那個數據項，OffsetToData 是 0x00001060（RVA），Size 是 0x0000003C。這個 DLL 文件的資源段的 VirtualAddress 是 1000h，1060h-1000h+200h = 260h，我們來看 260h 處（其實就是緊接著的地方）。我第一次看這段數據的時候也很奇怪，為什么前面空了 2 個字節，后面有多出好多字節。于是我改它的 ID，試了好些次，終于找到規律了。資源目錄第二層的 ID（下文稱 ResID）和最終的字符串 ID（下文稱 StrID）有這么一個對應關系：ResID = StrID / 16 + 1。StrID 0 到 15 所對應的 ResID 都是 1， StrID 16 到 31 對應 ResID 2，……。反過來說，資源目錄中的 ResID 不能完全表達 StrID 的信息。所以，在 260h 開始的 3Ch 個字節的數據塊里，其實要存儲 16 個字符串，其 StrID 分別是 0，1，2，……，15。這 16 個字符串是連續存儲的，結構是：字符串長度（WORD）+字符串內容（不含結束符 0）。那些空位就由一個 WORD 0 來填充（也可理解為長度為 0 的字符串）。我在圖中用紅褐色的豎線劃出了這 16 個字符串的界限。后面那個中文的也是如此，就不重復說了。

到現在為止，對于字串表的結構，應該說差不多清楚了。于是拿程序去生成似乎不是難事了，不過要注意的是，目錄項必須緊跟在目錄后面，目錄項指向的位置可以隨意。

事實上上面這個 DLL 是我用程序生成的。我現在做到了從內部數據結構到資源 DLL 這個過程的實現。如果這也可以被稱為“編譯”的話，現在是實現了后端。至于前端，我還沒想好原始資源格式。要想讓這個工具有點用處，原始資源格式必須要：1、足夠簡單（至少比 RC 文件簡單），并且維護方便；2、足夠存儲多語言字符串。這方面我希望大家能給我一些建議。

當然，本文的主要內容還是討論字串表的格式，這個已經講完了，所以，over~ bow~