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

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

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

不錯(cuò)，后來我就往這個(gè)方向琢磨了。之前曾寫過一個(gè)修改 PE 文件版本號(hào)的小工具，所以現(xiàn)在對(duì)于 PE 的資源格式有點(diǎn)并不那么恐懼了。但是，往細(xì)處做下去，問題就來了。現(xiàn)在網(wǎng)上的關(guān)于 PE 格式的文章，對(duì) NTHeader 解釋得很詳細(xì)，而資源段往往只講到資源目錄、資源項(xiàng)，具體各項(xiàng)的存儲(chǔ)結(jié)構(gòu)卻沒有詳細(xì)說明了。

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

首先來看一下幾個(gè)數(shù)據(jù)結(jié)構(gòu)（這些內(nèi)容好多文章也有提及）：

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

這是資源目錄，共 16 字節(jié)，其中最后兩個(gè) WORD 加起來是緊跟在后面的子項(xiàng)的數(shù)目。

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;

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

最后來看 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;

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

PE 文件中的資源就是通過這三個(gè)結(jié)構(gòu)表示的，它們都在 WinNT.h 中定義。通常會(huì)有 3 層結(jié)構(gòu)，第一層表示資源類型，第二層表示 ID，第三層標(biāo)識(shí)語言。

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

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

其資源段數(shù)據(jù)如下：

我用桔色框起來的是資源目錄，用粉色框起來的是資源目錄項(xiàng)，用淺綠色框起來的是資源數(shù)據(jù)項(xiàng)。

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

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

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

這三層結(jié)構(gòu)和 Resource Hacker 中顯示的是一一對(duì)應(yīng)的。

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

到現(xiàn)在為止，對(duì)于字串表的結(jié)構(gòu)，應(yīng)該說差不多清楚了。于是拿程序去生成似乎不是難事了，不過要注意的是，目錄項(xiàng)必須緊跟在目錄后面，目錄項(xiàng)指向的位置可以隨意。

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

當(dāng)然，本文的主要內(nèi)容還是討論字串表的格式，這個(gè)已經(jīng)講完了，所以，over~ bow~