Amiga Hunk

Hunk es el formato de archivo ejecutable de herramientas y programas del sistema operativo Amiga basado en la CPU Motorola 68000 y otros procesadores de la misma familia. El formato de archivo fue definido originalmente por MetaComCo. como parte de TRIPOS , que constituyó la base de AmigaDOS. ^{[ 1 ]} Este tipo de ejecutable recibió su nombre del hecho de que el software programado en Amiga está dividido en su estructura interna en muchas partes llamadas hunks , en las que cada porción puede contener código o datos.

Los fragmentos de código en un archivo ejecutable de Amiga pueden ser de varios tipos. Existen fragmentos de 32 bits , de 16 bits e incluso algunos de 8 bits .

Los tipos de fragmentos de código se estandarizaron en AmigaOS y se documentaron detalladamente en el Manual de AmigaDOS, editado por Commodore para explicar a los programadores cómo codificar en Amiga durante los años en que Commodore fabricó ordenadores Amiga. Su estructura estaba oficialmente codificada y solo podía ser modificada por un comité de Commodore, que luego comunicaba las modificaciones a los desarrolladores para las nuevas versiones del sistema operativo Amiga.

La estructura de un fragmento de código Amiga es muy simple: al principio del fragmento hay una cabecera que indica que ese tipo de "porción de código" es un tipo de fragmento de código Amiga conocido y válido, a continuación sigue un ID que indica la longitud del fragmento en sí, y en la parte inferior se encuentra el segmento del fragmento que contiene el código o los datos reales.

Los archivos ejecutables de Amiga se pueden iniciar tanto desde la interfaz gráfica de Amiga, Workbench , como desde el intérprete de línea de comandos de Amiga (llamado CLI, posteriormente AmigaShell).

No se requiere ninguna extensión de archivo específica para los archivos ejecutables de Amiga. Por ejemplo, el miniaplicativo de calculadora " Calculadora " se puede renombrar a " Calculadora.com ", " Calculadora.exe ", " Calculadora.bin " o incluso " Calculadora.jpeg ". Todos estos son nombres válidos para programas o herramientas, ya que AmigaOS no distingue entre extensiones de archivo .

AmigaOS adoptó otro método para reconocer que se trata de un ejecutable válido. Existe una secuencia particular de bytes en la cabecera del archivo, que produce el valor hexadecimal $000003f3 . Esta secuencia, que indica que se trata de un archivo ejecutable y permite su auto-ejecución, se denomina cookie mágica (en referencia a las galletas mágicas de Alicia en el País de las Maravillas de Lewis Carroll ).

Este tipo de solución para identificar archivos ejecutables en Amiga se tomó de soluciones similares que fueron adoptadas por sistemas operativos UNIX / tipo Unix , donde las cookies mágicas se llaman números mágicos .

La estructura interna de un archivo ejecutable de Amiga es muy simple. Al principio del archivo se encuentra la cookie mágica, luego se declara el número total de fragmentos en el ejecutable, y justo después se encuentran los números progresivos de fragmentos comenzando desde "0" (cero).

El primer fragmento siempre se numera como cero, por lo que si el ejecutable se subdivide (por ejemplo) en tres fragmentos, estos se numerarán como "0" para el primero, "1" para el segundo y "2" para el tercero, y así sucesivamente.

Justo antes de que comiencen los fragmentos reales hay una tabla que contiene información sobre la longitud de cualquier fragmento presente en el ejecutable, y en la última parte del archivo se ubican los fragmentos reales, cada uno descrito por su nombre de tipo: HUNK_CODE , HUNK_DATA , etcétera.

Representación de la estructura:

Los tipos de hunk conocidos para Amiga son:

* Formato de fragmento extendido

El Amiga podía guardar metadatos en bloques, ya que la estructura de bloques se podía adaptar fácilmente para admitir esta función, pero el formato de bloques de los ejecutables se abandonó en favor de ELF y no existe ninguna autoridad central (como la destituida Commodore) que pueda implementar esta función como uno de los estándares del Amiga.

El Amiga guarda algunos metadatos en archivos auxiliares conocidos como ".info" (llamados así por el nombre de su sufijo de extensión).

Los archivos ".info" pueden crearse cada vez que se guarda un proyecto (archivo de datos) en el disco. Por ejemplo: cuando el usuario guarda un archivo llamado "MyProject", pueden crearse dos archivos en el disco llamados "MyProject" y "MyProject.info".

El archivo "MyProject" contiene los datos reales del archivo del proyecto, mientras que el archivo "MyProject.info" contiene el icono y la información relativa al software que originó el archivo, por lo que cada vez que se haga clic en el icono del proyecto con el ratón, se abrirá el software principal (los usuarios pueden cambiar esta información en cualquier momento, permitiendo que otros programas crean que ellos crearon el archivo del proyecto en lugar del software original que lo creó físicamente).

En AmigaOS no existe la vinculación de aplicaciones como en otros sistemas como MacOS.

El archivo ".info" también contiene algunas características particulares del archivo del proyecto y los comentarios del usuario.

Los archivos ".info" no aparecen en la pantalla de Workbench (Workbench es la interfaz gráfica de usuario predeterminada de Amiga Desktop). En la pantalla del escritorio solo aparece el icono del archivo de proyecto extraído del archivo ".info". De hecho, el icono es el medio virtual que conecta el proyecto con los metadatos almacenados en el archivo ".info".

Cuando el usuario hace clic en el icono con el botón izquierdo del ratón, el proyecto ".info" llama al programa que lo originó. Al hacer clic en el icono y seleccionar la opción de menú correspondiente, aparecerá un cuadro de diálogo que le permitirá interactuar con los metadatos contenidos en el archivo ".info".

Los archivos ".info" se copian o mueven junto con su archivo de proyecto asociado, moviendo el icono con el ratón, y se pueden ver como un archivo independiente a través de las interfaces de línea de comandos de Amiga, como AmigaShell, o utilizando gestores de archivos o listadores de directorios de terceros como Directory Opus o DiskMaster .

Si el archivo ".info" representa un programa ejecutable, contiene información sobre la pila de búferes de RAM que podrían reservarse para dicho archivo (por ejemplo, 4096, 8192 o 16384 bytes o más de RAM) e incluso los argumentos que podrían invocarse mediante una interfaz de línea de comandos. Por ejemplo, un programa de Amiga podría abrir su propia pantalla de interfaz gráfica de usuario, independiente de la pantalla del escritorio. Al introducir argumentos como "Screen=800x600" y "Depth=8" en el cuadro de diálogo del archivo info, el usuario puede guardar esta información en el archivo ".info" correspondiente, y el programa abriría el software de productividad en su propia pantalla de 800x600 píxeles con una profundidad de color de 8 bits (equivalente a 256 colores).

El usuario también puede eliminar los archivos ".info", pero entonces renunciará a las ventajas de tener un icono que represente el archivo del proyecto en el escritorio, y también perderá todos los metadatos que contiene.

El tipo HUNK_OVERLAY se diseñó para reducir la cantidad de RAM necesaria para ejecutar un programa. Los ejecutables con una estructura de superposición tienen un nodo raíz que permanece en memoria en todo momento, y el resto del programa se divide en módulos más pequeños que se cargan y descargan automáticamente cuando es necesario. ^{[ 3 ]}

El formato Overlay funciona añadiendo pequeños fragmentos de código para que, al ramificarse en un submódulo, se llame a un gestor de superposiciones, que carga el módulo necesario. Commodore definió un gestor de superposiciones estándar para que el código C pudiera insertar automáticamente estos fragmentos y, además, generar una tabla de superposiciones que el gestor estándar supiera leer.

Sin embargo, el formato Overlay se usaba raramente, especialmente de la forma prevista. Era más común usarlo con un gestor de overlay personalizado. Un uso popular del formato overlay era con Titanics Cruncher, ^{[ 4 ]} que comprimía ejecutables. En lugar de cargar todo el ejecutable comprimido en la memoria antes de descomprimirlo, Titanics Cruncher usaba un overlay, de modo que solo se cargaba en la memoria un pequeño descompresor, que luego leía y descomprimía los datos sobre la marcha.

Mediante complementos de terceros, AmigaOS hasta la versión 3.9 reconoce varios tipos de archivos ejecutables distintos del formato Hunk creado para Motorola 68000.

• Comparación de formatos de archivos ejecutables
• vasm, un ensamblador gratuito que forma parte de vbcc

• Manual de AmigaDOS, tercera edición (Bantam Books), Commodore Business Machines, julio de 1991. ISBN 0-553-35403-5
• Manual de referencia del kernel de la ROM de Amiga, incluye y Autodocs (3.ª edición; cubierta gris oscuro). Addison-Wesley, 1991. ISBN 0-201-56773-3
• Commodore Business Machines: Notas de la Conferencia de Desarrolladores de Amiga de 1989 , Commodore, 1989. Números de pieza CATS: NOTES89 y NOTES89D
• Commodore Business Machines: V3.1 Amiga Developer Update Disk Set , Commodore, 1994. Número de pieza CATS: AMDEV3.1

(La información de este conjunto de disquetes distribuidos por Commodore a los desarrolladores de Amiga está obsoleta y ha sido actualizada y reemplazada en "The Developer CD").

• Commodore Business Machines: Notas de la Conferencia de Desarrolladores de Amiga de 1988. Commodore , 1988. Números de pieza CATS: NOTES88 y NOTES88D.
• Stephen Levy: Guía del programador de Amiga , Compute! Publications, 1986. ISBN 0-87455-028-9
• Eugene P. Mortimore: Manual del programador de Amiga , Sybex, 1985. ISBN 0-89588-343-0

• Amiga se vuelve PowerUP Página de inicio de soporte no oficial de PowerUP
• Descripción de terceros del formato Amiga Hunk