「Use Debug DCU's」的編譯選項？

Question

在我寫的一個組件中，我想包含automatic detection of registered image formats，但它是一個解決方案，只有在使用調試DCU的編譯器選項被禁用時纔有效。

什麼我真的想知道是這種解決方案，不涉及編譯器選項依賴關係的替代方案。

但是暫時我只想知道我在運行時是否可以檢查是否設置了使用調試DCU的編譯器選項。

Answer 1

沒有可靠的方法來在運行時獲取的信息

Use Debug DCUs編譯器選項僅切換搜索路徑;編譯器最終會發現什麼是未知的。 （誤導的）用戶可能已將Release dcu複製到調試目錄中，反之亦然。

即使沒有錯誤的用戶，也可能會將一些文件添加到項目中（並與項目一起編譯）以包含一些錯誤修復。例如，如果用戶將Graphics.pas添加到項目中，執行發佈/非調試版本，但保留Use Debug DCU's編譯器選項，那麼實際鏈接的Graphics.dcu不是調試版本，因爲它是用可執行文件重新構建的。所以你會得到一個「混合」的調試和非調試dcus包。

您可以嘗試檢測與某些對象或方法相關的調試信息的存在，但這也不可靠：如果您使用「Build with Debug Dcus」，但將「Debug Information」設置爲false，那麼您基本上扔掉了調試信息，所以你不能再尋找它。

但是，鏈接代碼失敗在調試DCU的

從GLScene中項目的代碼是不是一個很好的破解，它採用硬編碼偏移到了TPicture.RegisterFileFormat的代碼，然後繼續使用硬編碼的偏移獲取全局變量FileFormats的地址（不調用GetFileFormats例程）。那裏有太多的魔法數字！

我的第一個雖然是比較使用GLScene方法我已經確定了TList確定的TList，但你猜怎麼着：在我的機器沒有什麼問題，都得到了套路相同的結果，在這兩種情況下。在我的機器上，GLScene很醜，不會因調試DCU而損壞。我甚至嘗試過「指紋」一些rtl/vcl單元（SysUtils，Graphics，Classes）。我列出了所有公共類的列表，爲每個類中的每個方法生成了一些使用RTTI的代碼，並將代碼的前1024個字節轉儲爲字符串文件。該程序與調試DCU和非調試DCU和我得到了相同的結果。我的文本文件包含大約3500個方法的指紋！

不是一個好主意

由於該選項並沒有真正影響的方式編譯器編譯（僅適用於什麼樣的連接器鏈接），創建取決於此選項的代碼是非常不可靠的，不是一個好主意。 這隻影響低級別攻擊，並且您不希望低級別的黑客可能會在絕對無法控制的情況下使您的應用程序崩潰。

唯一真實的選擇是用一個不會失敗的（或者至少以可控的方式失敗）替換潛在的失敗破解。

Answer 2

由於Ken comments，可能無法檢測此編譯器選項涉及的路徑更改。命令行編譯器documentation沒有提到編譯器開關，因此這意味着它根本不存在。如果沒有編譯器開關，所以無法檢查編譯器選項是否設置

---

...但它是一個解決方案，只有在使用調試DCU的編譯器選項被禁用工作。

如果只能意味着它，否則結果異常，則可以使用以下替代：

try 
    // AutoDetectRegisteredImageFormats 
except 
    // Handle case when Use Debug DCU's is on 
end;