【问题标题】：What is a Delphi DCU file?什么是 .Delphi DCU 文件？
【发布时间】：2014-07-10 00:47:04
【问题描述】：

什么是 Delphi DCU 文件？

我相信它代表“Delphi Compiled Unit”。我是否正确假设它包含目标代码，因此对应于从 C/C++ 源代码文件编译的“.o”文件？

【问题讨论】：

它与 '.o 或 '.obj' 文件属于类似的类，是的。它包含可以链接的目标代码。
它本质上是在编译过程中用作一种缓存。没有改变的单元不需要重新编译，所以在这种情况下重新使用DCU来加速项目的编译。
@Jerry：它是编译的（二进制）代码，几乎与 .c 目标文件完全一样。它不是任何类型的“缓存”。它可以复制到另一台计算机并用于新项目。这是一个目标文件。现在的孩子，不记得目标文件、库和链接器的时代。嘘。 :-)
@Ken 是的，我只是指出了 DCU 文件性质的优势之一。如果只修改 10 个单元中的一个，如果其他 9 个已经有 DCU 文件，则只编译 1 个，从而加快进程。当然，除非您选择进行完整构建。
@Jerry：是的，这与任何编译的目标文件的行为完全相同。 :-) 目标文件是编译器和链接器之间必要的中间步骤，以便将内容放入链接器可以处理的格式并（与运行时和其他库一起）解析符号以“链接”在一起以形成可执行文件文件。

标签： c++ c delphi compilation dcu

【解决方案1】：

我相信 .dcu 通常表示“Delphi 编译单元”，而不是简单的“Pascal 源代码”的 .pas 文件。

.dcu 文件是 DCC 编译器将 .pas 文件编译后生成的文件（.dfm 文件被转换为二进制资源，然后由链接器直接处理）。

它类似于其他编译器生成的 .o 和 .obj 文件，但包含有关符号的更多信息（因此您可以 reverse engineer the interface section of a unit from it 省略 cmets 和编译器指令）。

.dcu 文件在技术上不是“缓存”文件，尽管如果您不删除它们并且不需要重新编译它们，您的构建将运行得更快。 .dcu 文件与生成它的编译器版本相关联。从这个意义上说，它的可移植性不如 .o 或 .obj 文件（尽管它们也存在兼容性问题）

这是一些历史记录，以防它添加任何内容。

编译器传统上将源代码语言翻译成某种中间形式。解释器不这样做——他们只是直接解释语言并立即运行应用程序。 BASIC 是解释型语言的经典例子。 DOS 和 Windows 中的“命令行”具有一种可以写入名为“batch files”且扩展名为 .bat 的文件的语言。但是在命令行上输入内容会直接执行它们。在 *nix 环境中，有很多不同的命令行解释器（CLIs），例如sh、csh、bash、ksh、and so on。您可以从所有这些文件中创建批处理文件——这通常被称为“脚本语言”。但是现在有很多其他语言既可以解释也可以编译。

无论如何，Java 和 .Net，例如，编译成称为中间“byte-code”表示的东西。

Pascal 最初是 written as a single-pass compiler 和 Turbo Pascal（源自 PolyPascal） - 对于 CP/M、CP/M-86 和 CP/M-86 和 DOS 有不同的版本 - 直接生成一个二进制可执行文件 (COM)在那些操作系统下运行。

Pascal 最初被设计为一种小型、高效的语言，旨在鼓励使用结构化编程和数据结构化的良好编程实践； Turbo Pascal 1 最初被设计为一个带有内置非常快速编译器的IDE，并且是 DOS 和 CP/M 市场上一个可负担得起的竞争对手，可对抗当时漫长的编辑/编译/链接周期。 Turbo Pascal 和 Pascal 与当时的任何编程环境都有类似的限制：内存和磁盘空间以kilobytes 衡量，处理器速度以Megahertz 衡量。

链接到可执行二进制文件会阻止您链接到单独编译的单元和库。

在 Turbo Pascal 之前，有 UCSD p-System 操作系统（支持多种语言，包括 Pascal。当时的 UCSD Pascal 编译器已经用单位扩展了 Pascal 语言）编译成伪机器字节码（称为 p-代码）格式，允许将多个单元链接在一起。虽然速度很慢，

同时，c 在VAX 和Unix 环境中演变，它编译成.o 文件，这意味着“目标代码”而不是“源代码”。注意：这与我们今天所说的“objects”完全无关。

Turbo Pascal 版本 3 之前并包括版本 3 直接生成的 .com 二进制输出文件（尽管您可以使用修改那些覆盖文件），并且从版本 4 开始支持将代码分离为首先编译成 .tpu 文件然后链接到最终的可执行二进制文件。 Turbo C 编译器生成 .obj（目标代码）文件而不是字节码，Delphi 2 引入了 .obj 文件生成，以便与 C++ Builder 合作。

目标文件在每个单元中使用相对寻址，并且需要稍后使用所谓的“修复”（或relocation）来使它们运行。修复指向预期存在于其他目标文件或库中的符号标签。

有两种“修复”：一种是由名为“linker”的工具静态完成的。链接器获取一堆目标文件并将它们缝合在一起，形成类似于拼布被子的东西。然后它通过插入指向所有外部定义标签的指针来“修复”所有相对引用。

第二次修复是在程序加载运行时动态完成的。它们是由一种叫做“加载器”的东西完成的，但你永远看不到。在命令行键入命令时，会调用loader将EXE文件加载到内存中，根据文件加载位置修复剩余链接，然后将控制权转移到应用程序的入口点.

所以当 Borland 在 Turbo Pascal 中引入单位时，.dcu 文件起源于 .tpu 文件，然后随着 Delphi 的引入而更改了扩展名。它们与 .obj 文件非常不同，但您可以从 Turbo Pascal 和 Delphi 链接到 .obj 文件。

Delphi 还完全隐藏了链接器，因此您只需编译和运行即可。但是，所有链接器设置仍然存在，在 Delphi 的一个选项窗格中。

【讨论】：

+1。然而，虽然这是一个有趣的“历史”，但问题的实际答案是“是的，它们是 Delphi 编译单元，与 C/C++ 目标文件几乎完全相同”。那应该先上，再上历史课（这样那些对历史不感兴趣的人也能清楚地找到答案）。
“DCU”文件在 Turbo Pascal 4.0 中被引入为“TPU”文件。 Turbo Pascal 从未生成或“链接”目标文件。在交付新的 32 位编译器时，Delphi 2 中引入了对象文件创建。
是的，@user1420752，它是一种模糊的专有目标文件格式，就像你熟悉的OMF和COFF一样。已经对其进行了一些逆向工程hmelnov.icc.ru/DCU/FAQ.htm
在 Turbo Pascal 4 中引入单位之前，它是 UCSD P-System，而不是 USCS Pascal，并且最初的 Turbo Pascal（最高版本 3）生成 COM 文件。
行“Pascal 最初是作为单遍编译器编写的，它直接生成在 DOS 下运行的可执行（COM 或 EXE）文件。”有点瑕疵。 Pascal 比 DOS 早了大约 10 年。

【解决方案2】：

除了 David Schwartz 的回答之外，还有一种情况是 dcu 实际上与用其他语言生成的典型 obj 文件完全不同：通用类型定义。如果在 Delphi 单元中定义了泛型类型，编译器会将此代码编译为语法树表示而不是机器代码。然后将该语法树表示存储在 dcu 文件中。当泛型类型随后在另一个单元中使用和实例化时，编译器将使用此表示并将其与使用泛型类型的单元的语法树“合并”。你可以认为这有点类似于方法内联。这也是为什么大量使用泛型的单元需要更长的编译时间的原因，尽管泛型类型是从 dcu 文件“链接”的。

【讨论】：

COFF 文件格式允许编译器和工具编写者向其中添加被工具链的其余部分忽略的自定义字段。因此，您可以轻松地将模板 (C++) 或通用 (.NET/Delphi) 类定义等内容注入到标准对象文件中，而不会对其他工具产生不良影响。我想知道 C++ Builder 在这方面是否和 Delphi 做的一样？
@David，C++ 模板和 Delphi 泛型之间存在巨大差异。前者实际上是真正的源代码替换，因此要求模板源代码在另一个文件中使用时可用，而Delphi泛型是预编译的，使用时不需要源代码。假设 C++ Builder 与 C++ 标准兼容，我会假设 C++ Builder 处理模板与 Delphi 泛型非常不同。

【解决方案3】：

Delphi 编译单元包含目标代码和预编译头文件，因此在某种程度上与 obj 文件和 .pch / .gch 文件相当。

Delphi 源文件的“接口”部分对应于头文件，“实现”部分创建目标代码。

预编译的头文件可以显着减少编译和链接时间。 DCU 标头部分提供到其他引用单元的链接信息，不必重新发现。

在 Delphi / Turbo Pascal 环境中，预编译的头文件支持严格的类型检查，如果使用了像 .coff 或 .obj 这样的 Object 文件格式，则需要引用源代码。（在 C++ 中，名称修饰提供了类似但不太完整的功能）。

【讨论】：