窺探 Delphi 的 dcp文件

之前我猜測 Delphi里的 dcp類似 java里的 maven 的 pom.xml，經過測試 發現，和猜想的才不多，既包含了pom.xml 的信息，又包含了本bpl的信息；測試如下：

DCP 英文全稱：delphi compiled package，是 package 編譯時跟 bpl 一起產生出來的，記錄著 package 中公開的 class、procedure、function、variable、const.... 等等的名稱和相對位址

在本文中，我將展示如何從 Delphi 的 DCP 文件中讀取一些非常基本的信息。這包括要鏈接的 BPL 名稱、所需的 DCP 和包含的單元。在過去的幾周里，我編寫了一個 Project-Analyzationtool，它能夠完全解開所有單元依賴關系并修復搜索路徑。但是，要做到這一點，我也必須與 DCP 合作。一些搜索并沒有透露太多（除了和我相同的問題）。我知道從 XE 到 XE8 的情況可能已經發生了變化，但我希望這篇文章仍然有助于讓 XE 以外的任何人開始。

因此，讓我們開始我們的骯臟工作。為了分析 DCP，我創建了一個名為 TestPackage.bpl 的新包。它只需要 RTL，并且有 2 個空單元：MyUnit 和 Foo.OtherUnit。這應該可以完成實驗的工作。拿起你選擇的十六進制編輯器并研究它。您將看到如下內容：

您會注意到的是，流以 4 個 AnsiChars “PKX0” 開頭。所有 DCP 似乎都以它開頭，所以我將其聲明為我們的 DCP 簽名。您可能會在加載文件時驗證這一點，以確保您擁有 DCP。在第 3 行，您將看到“TestPackage.bpl”。這是鏈接器將鏈接到的 BPL 的名稱。在處理具有后綴的 BPL 時，這是必需的。例如，對于 VCL150.bpl，僅存在 VCL.dcp。在這里，您可以找到最終的 BPL 名稱。通過比較不同的 DCP，您會注意到 BPL-Name 始終從同一位置（字節 33）開始。因此，我們的前 32 個字節肯定是某種標頭。讓我們仔細看看：

我已經概述了我已經分析過的領域并在這里進行了描述。如前所述，Red-Field 是我們的簽名。綠色和藍色包含數字，這些數字根據包含的單位數量和所需的 DCP 而變化。通過擺弄，您會注意到綠色是所需的 DCP 數量，藍色是包含的單元數量。等等，我們必須單位，為什么它告訴我有 3 個？很簡單，包的 DPK 文件（在本例中為 TestPackage.dpk）也包含在此列表中。橙色框僅包含標頭后面的 BPL-Name 的長度（以 Bytes 為單位）（不包括終止的 NULL-Character）。總而言之，我們的標題在 Delphi 中是這樣的：

但是等等，還有更多！

在我們的 BPL 名稱之后，我們會注意到“RTL”。這是因為它后面直接跟著一個零終止字符串列表，其中包括所需 DCP 的名稱。在我們的例子中，它只是“RTL”。因此，要獲取所需 DCP 的列表，只需根據標頭中注明的所需 DCP 數量，在零終止字符串之后讀取零終止字符串。之后，將出現包含的單元列表，并帶有自己的標題。總而言之，此列表的每個元素都包含一個 60 字節的 Blob，我還沒有調查過。每個塊后面有 2 個以零結尾的字符串。第一個字符串是我們的 Unit-Name，第二個字符串似乎是某種 NameSpace。當單位未帶點時，第二個字符串始終為空，僅由 NULL 字符組成。但是，當您的單位像“Foo.OtherUnit”一樣點綴時，它將包含“Foo”。這種模式適用于“Foo.Bar.MyUnit”等單位，其中命名空間為“Foo.Bar”。我用綠色/棕色和藍色/橙色突出顯示了這些字段。因此，要在此處獲取包含的單元列表，您只需跳過 60 個字節，并根據標頭中包含的單元數為每個元素讀取 2 個字符串。最后一個元素始終是 Package-DPK 單元。因此，如果你做對了所有事情，你可以得到這樣的輸出：

這里需要注意的是：最后一個條目，即 DPK-Entry，似乎有一個長度為 61 的 Header。我只是在這里循環了 60 字節的模式，這就是為什么我在姓氏前面有一個額外的字符。您可能想跳過那個。

我希望這篇文章能讓你開始了解 Delphi 的 DCP-File。