Bienvenido a nuestro sitio web, en este sitio encontrarás la resolución que buscas.
Solución:
Creo que .dcu generalmente significa “Unidad compilada de Delphi” en lugar de un archivo .pas que es simplemente “código fuente de Pascal”.
Un archivo .dcu es el archivo que produce el compilador DCC después de compilar los archivos .pas (los archivos .dfm se convierten en recursos binarios y luego el enlazador los procesa directamente).
Es similar a los archivos .o y .obj que producen otros compiladores, pero contiene más información sobre los símbolos (por lo tanto, puede aplicar ingeniería inversa a la sección de interfaz de una unidad omitiendo los comentarios y las directivas del compilador).
Un archivo .dcu técnicamente no es un archivo de “caché”, aunque sus compilaciones se ejecutarán más rápido si no las elimina y cuando no necesita volver a compilarlas. Un archivo .dcu está vinculado a la versión del compilador que lo generó. En ese sentido, es menos portátil que los archivos .o u .obj (aunque también tienen su parte de problemas de compatibilidad)
Aquí hay algo de historia en caso de que agregue algo.
Los compiladores tradicionalmente han traducido los lenguajes del código fuente a alguna forma intermedia. Los intérpretes no hacen eso, simplemente interpretan el idioma directamente y ejecutan la aplicación de inmediato. BASIC es el ejemplo clásico de un lenguaje interpretado. La “línea de comando” en DOS y Windows tiene un lenguaje que se puede escribir en archivos llamados “archivos por lotes” con una extensión .bat. Pero escribir cosas en la línea de comando las ejecutó directamente. En entornos *nix, hay un montón de diferentes intérpretes de línea de comandos (CLI), como sh, csh, bash, ksh, etc. Puede crear archivos por lotes a partir de todos ellos, lo que generalmente se conoce como “lenguajes de secuencias de comandos”. Pero ahora hay muchos otros lenguajes que se interpretan y compilan.
De todos modos, Java y .Net, por ejemplo, se compilan en algo llamado representación intermedia de “código de bytes”.
Pascal se escribió originalmente como un compilador de un solo paso, y Turbo Pascal (que se originó en PolyPascal), con diferentes ediciones para CP/M, CP/M-86 y DOS, generó directamente un archivo ejecutable binario (COM) que se ejecutaba bajo los que operaban. sistemas
Pascal se diseñó originalmente como un lenguaje pequeño y eficiente destinado a fomentar las buenas prácticas de programación mediante la programación estructurada y la estructuración de datos; Turbo Pascal 1 se diseñó originalmente como un IDE con un compilador muy rápido incorporado y un competidor asequible en el mercado de DOS y CP/M contra los largos ciclos de edición/compilación/enlace en ese momento. Turbo Pascal y Pascal tenían limitaciones similares a las de cualquier entorno de programación en ese entonces: la memoria y el espacio en disco se medían en kilobytes, las velocidades del procesador en megahercios.
La vinculación a un binario ejecutable le impedía vincularse a unidades y bibliotecas compiladas por separado.
Antes de Turbo Pascal, existía el sistema operativo UCSD p-System (compatible con muchos lenguajes, incluido Pascal. El compilador UCSD Pascal en ese entonces ya ampliaba el lenguaje Pascal con unidades) que compilaba en un código de bytes de pseudo-máquina (llamado p-code) formato que permitía vincular varias unidades entre sí. Aunque fue lento,
Mientras tanto, c evolucionó en entornos VAX y Unix, y se compiló en archivos .o, lo que significaba “código objeto” en lugar de “código fuente”. Nota: esto no tiene ninguna relación con nada de lo que hoy llamamos “objetos”.
Turbo Pascal hasta la versión 3 incluida, generó directamente archivos de salida binarios .com (aunque podría modificar esos archivos superpuestos) y, a partir de la versión 4, admitía la separación del código en unidades que primero se compilaban en archivos .tpu antes de vincularse al binario ejecutable final. . El compilador Turbo C generó archivos .obj (código de objeto) en lugar de códigos de bytes, y Delphi 2 introdujo la generación de archivos .obj para cooperar con C++ Builder.
Los archivos de objetos utilizan direccionamiento relativo dentro de cada unidad y requieren lo que se denomina “reparaciones” (o reubicación) más adelante para que se ejecuten. Las correcciones apuntan a etiquetas simbólicas que se espera que existan en otros archivos o bibliotecas de objetos.
Hay dos tipos de “reparaciones”: una se realiza de forma estática mediante una herramienta llamada “vinculador”. El enlazador toma un montón de archivos de objetos y los une en algo análogo a una colcha de retazos. Luego “arregla” todas las referencias relativas conectando punteros a todas las etiquetas definidas externamente.
Las segundas correcciones se realizan dinámicamente cuando el programa se carga para ejecutarse. Están hechos por algo llamado “cargador”, pero nunca se ve eso. Cuando escribe un comando en la línea de comandos, se llama al cargador para cargar un archivo EXE en la memoria, reparar los enlaces restantes en función de dónde se carga el archivo y luego el control se transfiere al punto de entrada de la aplicación.
Entonces, los archivos .dcu se originaron como archivos .tpu cuando Borland introdujo unidades en Turbo Pascal, luego cambió de extensión con la introducción de Delphi. Son muy diferentes de los archivos .obj, aunque puede vincular archivos .obj de Turbo Pascal y Delphi.
Delphi también ocultó el enlazador por completo, por lo que solo haces una compilación y una ejecución. Sin embargo, todas las configuraciones del enlazador todavía están allí, en uno de los paneles de opciones de Delphi.
Además de la respuesta de David Schwartz, hay un caso en el que un dcu en realidad es bastante diferente de los típicos archivos obj generados en otros idiomas: definiciones de tipo genérico. Si se define un tipo genérico en una Unidad Delphi, el compilador compila este código en una representación de árbol de sintaxis en lugar de código de máquina. Esta representación del árbol de sintaxis se almacena en el archivo dcu. Cuando el tipo genérico se usa y se instancia en otra unidad, el compilador usará esta representación y la “fusionará” con el árbol de sintaxis de la unidad que usa el tipo genérico. Podría pensar que esto es algo análogo al método en línea. Esto, por cierto, también es la razón por la que una unidad que hace un uso intensivo de genéricos tarda mucho más en compilarse, aunque los tipos genéricos están “vinculados” desde un archivo dcu.
Aquí puedes ver las comentarios y valoraciones de los usuarios
Agradecemos que desees añadir valor a nuestra información cooperando tu experiencia en las observaciones.