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 formó la base para AmigaDOS. [1] Este tipo de ejecutable obtuvo su nombre del hecho de que el software programado en Amiga está dividido en su estructura interna en muchas piezas llamadas trozos , en los que cada porción podría contener código o datos.
Los fragmentos de un archivo ejecutable de Amiga pueden ser de varios tipos: de 32 bits , de 16 bits e incluso de 8 bits .
Los tipos de bloques se estandarizaron en AmigaOS y están bien documentados en el Manual de AmigaDOS editado por Commodore para explicar a los programadores cómo codificar en Amiga, durante los años en los que Commodore fabricó las computadoras Amiga. Su estructura fue codificada oficialmente y solo podía ser cambiada 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 trozo de Amiga es muy simple: hay un encabezado al comienzo del trozo que indica que ese tipo de "porción de código" es un tipo de trozo de Amiga conocido y válido, luego sigue una ID que indica la longitud del trozo en sí, y en la parte inferior está el segmento del trozo que contiene el código o los datos reales.
Los archivos ejecutables de Amiga se pueden ejecutar desde el shell gráfico de Amiga, el Workbench o desde el intérprete de línea de comandos de Amiga (llamado CLI, más tarde AmigaShell).
No se requiere ninguna extensión de nombre de archivo en particular para los archivos ejecutables de Amiga. Por ejemplo, la aplicación de calculadora " Calculadora " se puede renombrar como " Calculadora.com ", " Calculadora.exe ", " Calculadora.bin " o incluso " Calculadora.jpeg ". Todos estos son nombres válidos para programas o herramientas, porque AmigaOS no diferencia entre extensiones de nombre de archivo .
AmigaOS adoptó otro método para reconocer que está tratando con un ejecutable válido. Hay una secuencia particular de bytes en el encabezado del archivo, que produce el valor hexadecimal $000003f3 . Esta secuencia, que significa un archivo ejecutable y le permite ejecutarse automáticamente, se llama galleta mágica (de las galletas mágicas de Alicia en el país de las maravillas de Lewis Carroll ). [ cita requerida ]
Este tipo de solución para identificar ejecutables en Amiga fue tomada de soluciones similares que fueron adoptadas por los sistemas operativos UNIX / similares a Unix , donde las cookies mágicas se denominan números mágicos .
La estructura interna de un archivo ejecutable de Amiga es muy sencilla. Al principio del archivo se encuentra la cookie mágica, luego se declara el número total de fragmentos del ejecutable y, justo después, el número progresivo de fragmentos, comenzando desde "0" (cero).
El primer trozo siempre se numera cero, por lo que si el ejecutable se subdivide (por ejemplo) en tres trozos, se numerarán "0" para el primero, "1" para el segundo y "2" para el tercer trozo, y así sucesivamente.
Justo antes de que comiencen los trozos reales hay una tabla que contiene información sobre la longitud de los trozos presentes en el ejecutable, y en la última parte del archivo se colocan los trozos 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 trozo extendido
Amiga podía guardar metadatos en trozos, ya que la estructura de trozos podía adaptarse fácilmente para soportar esta característica, pero el formato de trozos de ejecutables fue abandonado en favor de ELF y no hay una autoridad central (como el despedido Commodore) que pudiera implementar esta característica como uno de los estándares de Amiga.
Amiga guarda algunos metadatos en archivos sidecar conocidos como ".info" (llamados así por el sufijo de su extensión).
Los archivos ".info" se pueden crear en cualquier momento en que se guarde un proyecto (archivo de datos) en el disco. Ejemplo: cuando el usuario guarda un archivo llamado "MyProject", se pueden crear 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 ícono y la información sobre el software que originó el archivo, por lo que cada vez que se invoca el ícono del proyecto haciendo clic en él con el mouse, se abrirá el software principal (los usuarios pueden cambiar esta información en cualquier momento, lo que permite que otros programas crean que crearon el archivo del proyecto en lugar del software original que lo creó físicamente).
La vinculación de aplicaciones no existe en AmigaOS como en otros sistemas como MacOS.
El archivo ".info" también contiene algunas características particulares del archivo del proyecto y los comentarios de los usuarios.
Los archivos ".info" no aparecen en la pantalla 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 en sí y los metadatos almacenados en ".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ó. Cuando el usuario hace clic en el icono y elige el elemento de menú adecuado, aparece un cuadro de diálogo que permite al usuario 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 ícono con el mouse, y se pueden ver como un archivo independiente a través de las interfaces de línea de comandos de Amiga, como AmigaShell, o usando administradores de archivos de terceros o listados de directorios como Directory Opus o DiskMaster.
Si el archivo ".info" representa un programa ejecutable, entonces el archivo ".info" contiene información sobre la pila de buffers de RAM que podrían reservarse para el archivo ejecutable (por ejemplo, 4096, 8192 o 16384 o más bytes de RAM) e incluso los argumentos que podrían invocarse utilizando una interfaz de línea de comandos. Por ejemplo, un programa Amiga podría abrir su propia pantalla de interfaz gráfica de usuario independiente de la pantalla del escritorio. Al invocar argumentos como "Pantalla=800x600" y "Profundidad=8" en el cuadro de diálogo del archivo de información, el usuario puede guardar esta información en el archivo ".info" asociado y luego el programa abriría el software de productividad en su propia pantalla de tamaño 800x600 con 8 bits de profundidad de color (igual a 256 colores).
El usuario también puede eliminar archivos ".info", pero entonces renunciará a los beneficios de tener un icono que represente el archivo del proyecto en el escritorio, y también perderá todos los metadatos contenidos en él.
Una breve vista de los íconos de mapa de bits contenidos en los archivos de metadatos ".info":
Los iconos son datos de mapa de bits RAW contenidos en archivos ".info" y no son archivos IFF / LBM estándar de Amiga . Los usuarios pueden trabajar con iconos utilizando el programa estándar de AmigaOS "IconEdit", presente en el sistema operativo desde sus primeras versiones. A partir de la versión 2.0 de AmigaOS, IconEdit podía importar y guardar archivos IFF/LBM normales utilizados como archivos gráficos estándar en AmigaOS. [2]
Algunos programas de Amiga como Personal Paint de Cloanto pueden ver, cargar y guardar datos de mapa de bits como iconos normales de Amiga o como archivos ".info" de Amiga ya existentes.
Los iconos de Amiga antiguos pueden tener iconos de dos estados, utilizando dos imágenes de mapa de bits diferentes. El primer mapa de bits contiene los datos del icono "silencioso", también conocido como el "estado silencioso" del icono. La segunda imagen de mapa de bits contiene los datos del estado "seleccionado" del icono. Cuando el usuario hace clic en un icono y lo activa, los datos del mapa de bits del icono silencioso se reemplazan de repente por los datos del mapa de bits del icono seleccionado. Este comportamiento da a los iconos de Amiga el efecto de dibujos animados en movimiento. En caso de que este segundo mapa de bits no exista en el archivo ".info" (no es obligatorio crear ambos mapas de bits), se utiliza un efecto de color inverso cuando se selecciona el icono.
Existen "motores" de iconos de terceros que intentan mantener la apariencia de AmigaOS actualizada con los estándares modernos de otros sistemas operativos. Estos programas parchean las rutinas del sistema operativo dedicadas al manejo de iconos, reemplazándolas por otras personalizadas. Uno de estos intentos, NewIcons , se ha convertido prácticamente en el nuevo estándar de facto para AmigaOS 3.x. Fue tan popular que el nuevo sistema de iconos utilizado en AmigaOS 3.5 y posteriores, GlowIcons , se basa en su formato de archivo de iconos.
Todos los sistemas operativos modernos similares a Amiga ( AmigaOS 4 , MorphOS y AROS ) podrían asociar datos de mapa de bits RAW, archivos IFF/LBM o también archivos PNG como imagen de mapa de bits interna estándar de cualquier ícono.
El tipo HUNK_OVERLAY fue pensado 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 está en la 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 al código de modo que cuando se ramifican en un submódulo, se llama a un administrador de superposición, que carga el módulo requerido. Commodore definió un administrador de superposición estándar para que el código C pudiera tener automáticamente estos fragmentos insertados y también generar una tabla de superposición, que el administrador de superposición estándar sabía cómo leer.
Sin embargo, el formato de superposición rara vez se utilizó, especialmente en la forma en que se pretendía. Se usaba más comúnmente con un administrador de superposición personalizado. Un uso popular del formato de superposición fue 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 una superposición, por lo que solo se cargaba un pequeño descompresor en la memoria, luego leía y descomprimió los datos a medida que avanzaba.
Con complementos de terceros, AmigaOS hasta 3.9 reconoce varios tipos de archivos ejecutables distintos del formato Hunk creado para Motorola 68000.
Phase5 implementó ejecutables ELF para sus placas aceleradoras PowerUP. Se consideró que era complicado debido a su vinculación dinámica. Luego, este formato fue adoptado como estándar por AmigaOS 4.0 , MorphOS y AROS . Los desarrolladores externos agregaron soporte ELF a WarpUp y Hyperion Entertainment lanzó una serie de juegos de WarpUp solo en formato ELF. [5]
En 1997, Haage & Partner desarrolló el kernel WarpUp PowerPC para las placas aceleradoras PowerUP. En lugar del formato binario ELF, decidieron ampliar el formato de fragmentos existente. El problema con el formato binario ELF era que los usuarios tenían que parchear su sistema para cargar ejecutables ELF y no era posible mezclar código PPC/68k. El formato de fragmentos extendido (EHF), desarrollado por Haage & Partner, permitía mezclar código PPC y 68k en un único ejecutable sin modificar el sistema existente si no estaba instalado el acelerador PowerPC. [1] [2] .
AmigaOS 4.0 y MorphOS pueden ejecutar ELF de forma nativa, pero como estos sistemas fueron diseñados para ejecutarse en máquinas basadas en procesadores PowerPC, los desarrolladores añadieron también compatibilidad con el software WarpUP, utilizado en AmigaOS 3.9. Además, MorphOS implementa la compatibilidad del software PowerUp, tal como lo implementó Phase5 para las tarjetas aceleradoras PowerUP.
Ambos nuevos sistemas operativos también pueden ejecutar el formato Amiga Hunk porque implementan el antiguo entorno API de Amiga basado en AmigaOS 3.1 y pueden ejecutar código 68000 a través de emulación.
(la información de este conjunto de disquetes distribuidos por Commodore a los desarrolladores de Amiga está obsoleta y se actualiza y reemplaza en "El CD del desarrollador")
