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 de AmigaDOS. [1] Este tipo de ejecutable debe su nombre al hecho de que el software programado en Amiga está dividido en su estructura interna en muchas piezas llamadas trozos , en las que cada porción puede contener código o datos.
Los fragmentos de un archivo ejecutable de Amiga pueden existir en varios tipos. Hay trozos de 32 bits , trozos de 16 bits e incluso algunos trozos de 8 bits .
Los tipos de trozos se estandarizaron en AmigaOS y estaban 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 fabricaba computadoras Amiga. Su estructura fue codificada oficialmente y sólo 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 Amiga es muy simple: hay un encabezado al principio del fragmento que indica que ese tipo de "porción de código" es un tipo de fragmento de Amiga conocido y válido, luego sigue un ID que indica la longitud del fragmento. en sí, y en la parte inferior está el segmento del fragmento que contiene el código o los datos reales.
Los archivos ejecutables de Amiga se pueden iniciar 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 particular para los archivos ejecutables de Amiga. Por ejemplo, el subprograma de calculadora " Calculator " se puede cambiar de nombre a " Calculator.com ", " Calculator.exe ", " Calculator.bin " o incluso " Calculator.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 se trata de 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 cookie mágica (de las galletas mágicas de Alicia en el país de las maravillas de Lewis Carroll ). [ cita necesaria ]
Este tipo de solución para identificar 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 sencilla. Al principio del archivo está la cookie mágica, luego se declara el número total de fragmentos en el ejecutable, y justo después está el número progresivo de fragmentos comenzando desde "0" (cero).
El primer fragmento siempre tiene el número cero, por lo que si el ejecutable se subdivide (por ejemplo) en tres fragmentos, se numerarán "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 los fragmentos presentes 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. .
Representación de la estructura:
Los tipos de trozos conocidos del Amiga son:
* Formato de trozo extendido
Amiga podría guardar metadatos en fragmentos, ya que la estructura del fragmento podría adaptarse fácilmente para admitir esta característica, pero el formato de fragmento de los ejecutables se abandonó en favor de ELF y no existe una autoridad central (como el comodoro despedido) que pueda implementar esta característica. como uno de los estándares de Amiga.
Amiga guarda algunos metadatos en archivos secundarios conocidos como ".info" (llamado así por el nombre de su sufijo de extensión).
Los archivos ".info" se pueden crear cada vez que se guarda un proyecto (archivo de datos) en el disco. Ejemplo: cuando el usuario guarda un archivo llamado "MiProyecto", se pueden crear dos archivos en el disco llamados "MiProyecto" y MiProyecto.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 mouse, se abrirá el software principal (los usuarios pueden cambiar esta información en cualquier momento, permitiendo que otros programas crean que fueron ellos los que crearon el archivo del proyecto en lugar del software original que lo creó físicamente).
El enlace 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 del usuario.
Los archivos ".info" no aparecen en la pantalla Workbench (Workbench es la GUI predeterminada de Amiga Desktop). En la pantalla del escritorio sólo aparece el icono del archivo del 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ú apropiado, 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 ícono con el mouse, y se pueden ver como un archivo independiente a través de las interfaces de línea de comando 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 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 mediante una interfaz de línea de comandos. Por ejemplo, un programa Amiga podría abrir su propia pantalla de interfaz gráfica de usuario independientemente 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á el software de productividad en su propio tamaño de pantalla. 800×600 con 8 bits de profundidad de color (igual a 256 colores).
El usuario también puede eliminar archivos ".info", pero entonces renunciará a tener un icono que represente el archivo del proyecto en el escritorio, y también perderá todos los metadatos que contiene.
Una breve vista de los iconos 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 estándar IFF / LBM 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 mapas de bits como iconos Amiga normales o como archivos ".info" de Amiga ya existentes.
Los íconos Legacy Amiga pueden tener íconos de dos estados, usando dos imágenes de mapa de bits diferentes. El primer mapa de bits contiene los datos del icono "silencioso", también conocido como "estado silencioso" del icono. La segunda imagen de mapa de bits contiene 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 repentinamente 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 esos intentos, NewIcons , se ha convertido casi 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 superiores, GlowIcons , se basa en su formato de archivo de iconos.
Todos los sistemas operativos modernos tipo Amiga ( AmigaOS 4 , MorphOS y AROS ) pueden 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 icono.
El tipo HUNK_OVERLAY estaba destinado a reducir la cantidad de RAM necesaria para ejecutar un programa. Los ejecutables con estructura superpuesta 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 agregando pequeños resguardos al código de modo que cuando se ramifican en un submódulo, 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 insertar automáticamente estos resguardos y también generar una tabla de superposición, que el administrador de superposición estándar sabía leer.
Sin embargo, el formato Overlay rara vez se utilizó, especialmente en la forma en que estaba previsto. 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 archivos ejecutables. En lugar de cargar todo el ejecutable comprimido en la memoria antes de descomprimirlo, Titanics Cruncher usó una superposición, por lo que solo se cargó en la memoria un pequeño decruncher, luego leyó 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. Resultó engorroso debido a su vinculación dinámica. Este formato luego fue adoptado como estándar por AmigaOS 4.0 , MorphOS y AROS . Desarrolladores externos agregaron compatibilidad con ELF a WarpUp y Hyperion Entertainment lanzó varios juegos WarpUp solo en formato ELF. [5]
En 1997, Haage & Partner desarrolló el kernel WarpUp PowerPC para placas aceleradoras PowerUP. En lugar del formato binario ELF, habían optado por ampliar el formato de trozo 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. Extended Hunk Format (EHF), desarrollado por Haage & Partner, permitía mezclar código PPC y 68k en un único ejecutable sin modificar el sistema existente si no se instalaba 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 también agregaron compatibilidad para el software WarpUP, utilizado en AmigaOS 3.9. Además, MorphOS implementa la compatibilidad del software PowerUp implementado por Phase5 para las tarjetas aceleradoras PowerUP.
Ambos nuevos sistemas operativos también pueden ejecutar el formato Amiga Hunk porque implementan el antiguo entorno Amiga API basado en AmigaOS 3.1 y pueden ejecutar código 68000 mediante emulación.
(La información de este conjunto de disquetes distribuidos por Commodore a los desarrolladores de Amiga está obsoleta y actualizada y reemplazada en "El CD del desarrollador")
