Amiga Hunk

Hunk ist das ausführbare Dateiformat von Programmen unter dem klassischen AmigaOS (bis zur Version 3.9) für Amigas basierend auf der 68000 Prozessor Familie. Der Name „Hunk“ ist dabei von der Art und Weise abgeleitet, wie die Software intern strukturiert ist; nämlich als mehrere kleine Brocken oder Stücken (englisch hunks). Jeder einzelne dieser Hunks kann dabei Daten und ausführbaren Programmcode enthalten.

Hunk-Struktur

Die Hunks in den ausführbaren Programmen des Amigas existieren in mindestens drei verschiedenen Formen. Es gibt 32-Bit-, 16-Bit- und vereinzelt auch 8-Bit-Hunks.

Die verschiedenen Hunks sind im AmigaOS standardisiert und im The AmigaDOS Manual ausführlich dokumentiert. Diese Standardisierung wurde von Commodore selber überwacht und bei Bedarf erweitert.

Die Standardisierungen galten für Entwickler über die Jahre hinweg als Richtlinien für Amiga-systemkonforme Programmierung. Die Strukturen waren offiziell im System kodiert und konnten nur von einem Commodore-Komitee für neue Versionen des AmigaOS verändert werden. Anschließend wurden sie an die Entwickler herausgegeben.

Die Struktur des Amiga-Hunk-Formates ist sehr einfach gehalten. Es besteht im Prinzip aus drei Teilen: einem Kopf (Header), einer ID (die Größe des Hunks) und anschließend ein Segment, welches den Programmcode oder die Daten enthält.

Der Header muss dabei einem dem AmigaOS bekannten Typ entsprechen.

Merkmale eines ausführbaren Amigaprogrammes

Die Programme können entweder von der grafischen Betriebssystem-Shell des AmigaOS, des Desktops (Workbench), aus dem Amiga-CLI (AmigaShell) oder aus einem Dateimanager heraus gestartet werden.

Dateien unter dem AmigaOS benötigen keine Dateiendungen. Dateien können beliebig, inklusive der Dateiendung umbenannt werden und ändern dabei nicht ihren Dateityp. Unter AmigaOS werden Dateitypen über Hunks, Header oder einem Magic Cookie erkannt. Dieses Magic Cookie ($000003f3) wird zum Beispiel vom AmigaOS zur Kennzeichnung von ausführbaren Programmen verwendet und ist ein Bestandteil des Headers. Der Name stammt aus dem Märchen Alice im Wunderland. Ein ähnliches Verfahren wird auch von Unix-artigen Betriebssystemen verwendet und dort Magic Number genannt.

Struktur eines ausführbaren Amigaprogrammes

Die interne Struktur eines Amigaprogrammes ist ebenfalls recht einfach gehalten. Die Struktur beginnt mit dem Magic Cookie, gefolgt von der Anzahl aller vorhandenen Hunks und dann einem Segment, das alle Hunks in ihrer Reihenfolge (bei 0 beginnend) enthält. Der erste Hunk trägt immer die Nummer Null.

Kurz bevor das Hunksegment startet, steht eine Tabelle, die die Länge eines jeden Hunks enthält. Jeder Hunk beginnt dabei mit einer ID, der ein gewisser Hunktyp (HUNK_CODE oder HUNK_DATA) zugeordnet ist.

Magic Cookie

Anzahl der Hunks

Progressive Anzahl der Hunks

Hunk-Längen-Tabelle

Verschiedene Hunks (Hunk_Code, Hunk_Data, etc.)

Hunktypen

Dem AmigaOS bekannte Hunktypen:

Name	Nummer
HUNK_UNIT	999
HUNK_NAME	1000
HUNK_CODE	1001
HUNK_DATA	1002
HUNK_BSS	1003
HUNK_RELOC32	1004
HUNK_RELOC16	1005
HUNK_RELOC8	1006
HUNK_EXT	1007
HUNK_SYMBOL	1008
HUNK_DEBUG	1009
HUNK_END	1010
HUNK_HEADER	1011
(unbenutzt)	1012
HUNK_OVERLAY	1013
HUNK_BREAK	1014
HUNK_DREL32	1015
HUNK_DREL16	1016
HUNK_DREL8	1017
HUNK_LIB	1018
HUNK_INDEX	1019
HUNK_RELOC32SHORT	1020
HUNK_RELRELOC32	1021
HUNK_ABSRELOC16	1022
HUNK_PPC_CODE	1257
HUNK_RELRELOC26	1260

Metadaten

Der Amiga wäre durchaus in der Lage, Metadaten in Hunks abzulegen. Die Struktur der Hunks könnte jedenfalls relativ einfach dafür angepasst werden. Diese Änderungen wurden aber zugunsten des ELF-Formates verworfen. Heute existiert aber kein Commodore-Komitee mehr, welches diese Änderungen überwachen und implementieren könnte.

Der Amiga speichert daher ein Teil seiner Metadaten in den sogenannten .info-Dateien ab. Das Prinzip dieser Dateien gleicht ein wenig den alten ausführbaren Programmen des Macintosh und dabei deren resource fork.

Die .info-Dateien werden in der Regel bei jeder Erstellung von Dateien (Projektdateien) unter AmigaOS mit erstellt. Die .info-Datei enthält Informationen wie zum Beispiel das eigentliche Icon der Datei, Informationen über den Ersteller der Datei, Erstellungszeit, nötige Anzeigesoftware, Dateigrundtyp oder Benutzerkommentare. Im AmigaOS existiert keine feste Bindung an Anwendungen wie zum Beispiel in MacOS.

.info-Dateien sind nicht direkt auf der Workbench sichtbar. Die Workbench stellt die Datei und ihre .info-Datei als eine Einheit dar, wobei zur Darstellung eines Icons die Bitmap-Informationen aus der .info-Datei genutzt werden.

Wenn der Benutzer das Icon mit der linken Maustaste doppelt zum Ausführen anklickt, wird jenes Programm gestartet, welches als Anzeigeprogramm in der .info-Datei eingestellt ist und die eigentliche Datei als Argument übergeben. Mit der rechten Maustaste kann ein Menü geöffnet werden, in dem die Datei umbenannt oder ein Informationsfenster geöffnet werden kann. In dem Informationsfenster kann der Benutzer ein Großteil der Metainformationen ändern.

Beide Dateien, die eigentliche Datei und die .info-Datei, werden immer zusammen bewegt, wenn man sie auf der Workbench mit der Maus verschiebt oder markiert. Sie werden immer als eine Einhalt behandelt. Möchte man die Dateien einzeln manipulieren, ist man auf den CLI oder einen Dateimanager wie Directory Opus angewiesen.

Wenn die .info-Datei ein ausführbares Programm repräsentiert, enthält sie Informationen über die Stack-Größe des Programmes (4096 Bytes, 8192 Bytes, etc.). Die Informationen werden auch dann beachtet, wenn sie über den CLI des AmigaOS gestartet wird.

Der Benutzer hat auch die Möglichkeit, die .info-Datei zu entfernen, entfernt dabei aber auch alle Metainformationen und das Icon.

Icons

Die Icons sind ein Bestandteil der .info-Dateien und sind im Prinzip eingebettete rohe Bitmaps und nicht das Standard-Amiga-IFF/ILBM-Format. Der Benutzer kann die Bitmaps in den .info-Dateien mit dem AmigaOS beiligenden Standardprogramm IconEdit bearbeiten. Seit AmigaOS 2.0 ist das Programm auch in der Lage, IFF/ILBM-Bilder zu im- und exportieren.

Einige weitere Amigaprogramme, wie zum Beispiel das verbreitete Personal Paint von Cloanto, sind in der Lage, die Bitmap-Informationen aus den .info-Dateien zu laden, zu speichern und anzuzeigen. Die klassischen Amiga-Icons (bis AmigaOS 3.1) sind sogenannte two-state Icons. Sie beinhalten zwei Bitmaps, eine für den normalen Zustand und eine für den gedrückten Zustand. Die beiden Bitmaps werden sozusagen on-the-fly ausgetauscht, wenn ein Icon selektiert oder unselektiert wird.

Modernere Amiga-Oberflächen wie die ReAction GUI (AmigaOS 3.9 bis 4.1) oder das MUI (klassisches AmigaOS, AROS und MorphOS) verwenden weitere Möglichkeiten, Icons zu nutzen.

Alle modernen Amiga-ähnlichen Betriebssysteme (AmigaOS 4.0/4.1, MorphOS und AROS) sind in der Lage, rohe Bitmaps, IFF/ILBM- und PNG-Daten/Dateien als Icondaten zu nutzen.

Weitere dem AmigaOS bekannte ausführbare Formate

Klassisches AmigaOS

AmigaOS (bis 3.9) erkennt folgende weitere Formate.

Hunk_Overlay

Der Hunk_Overlay-Typ ist einer der von Commodore erstellten Standard-Hunks. Er war dazu gedacht, Speichermangelprobleme zu lösen. Dieser Hunk implementiert eine Methode, Programme zu laden, die größer sind als die eigentliche Arbeitsspeichermenge im Betriebssystem.

Bei dieser Methode wird eine Wurzelstruktur mit Referenzen auf kleinere Codefragmente/-module im Arbeitsspeicher gehalten, wobei die eigentlichen Codefragmente nur bei Bedarf in den Arbeitsspeicher geladen werden, also praktisch eine Art der Overlay-Programmierung.

Dieser Designansatz war relativ clever, aber in der Praxis war dessen Nutzung so umständlich, dass diese Methode nur sehr selten eingesetzt wurde. Die meisten Entwickler ignorierten diese Möglichkeit schlichtweg.

Extended Hunk Format (EHF)

1997 führte der Hardware-Hersteller Phase5 PowerPC-basierte Beschleunigerkarten ein. Da das AmigaOS aber nach wie vor auf 680x0-Prozessoren lief, wurde der PowerPC-Prozessor wie eine Art CoProzessor genutzt. Daraus resultierte, dass beide Prozessoren immer abwechselnd auf den Arbeitsspeicher zugreifen mussten (Task-/Contextswitching) und das System dabei stark ausgebremst wurde. Um dem Problem Herr zu werden, präsentierte der AmigaOS-3.5/3.9-Entwickler Haage&Partner eine andere Möglichkeit, um Daten und Code mit der PowerPC-Hardware auszutauschen. Die Möglichkeit bestand aus einem neuen PowerPC-API/Kernel names WarpOS/WarpUP, der sich durch die Erweiterung des Amiga-Hunk-Formates systemkonform verhielt. Dieses neue Format nennt sich Extended Hunk Format (EHF) und erweitert die klassischen Amiga-Hunks um den Typ HUNK_PPC_CODE.

ELF

Der Hardware-Hersteller Phase5 führte zusammen mit seiner PowerPC-Hardware das aus der Unixwelt bekannte ELF-Format ein (Bestandteil der PowerPC-API/Kernel PowerUP). Das Format wurde später von AmigaOS 4.x, MorphOS und AROS übernommen. Eine ELF-Emulation wurde später durch Dritte auch in WarpOS/WarpUP integriert.

AmigaOS 4.0 und MorphOS

AmigaOS 4.x und MorphOS können das ELF-Format nativ auf der Hardware ausführen, da beide Betriebssysteme nativ auf PowerPC-Hardware laufen. Beide sind ebenfalls in der Lage, EHF nativ auszuführen. MorphOS ist zusätzlich in der Lage, das ELF Format für die m68k/PowerPC-Beschleunigerkarten (PowerUP) für die klassischen Amigas auszuführen.

Beide Betriebssysteme sind zusätzlich in der Lage, das klassische Amiga-Hunk-Format in einer Emulationsschicht auszuführen. Dabei wird nahezu die vollständige AmigaOS-3.1-API emuliert. Dies wird durch eine JITM (Just In Time Machine) realisiert, die alle 68000-Instruktionen auf PowerPC-Instruktionen abbildet und dadurch eine recht hohe Emulationsgeschwindigkeit erreicht. Die JIT-Maschine unter AmigaOS 4.x heißt Petunia und die JIT-Maschine von MorphOS nennt sich Trance.

Referenzen

• The AmigaDOS Manual Third Edition (Bantam Books), Commodore Business Machines, July 1991. ISBN 0-553-35403-5
• Amiga ROM Kernel Reference Manual, Includes and Autodocs (3rd edition; dark gray cover) Addison-Wesley, 1991. ISBN 0-201-56773-3
• Commodore Business Machines: 1989 Amiga Developers Conference Notes, Commodore, 1989. CATS part numbers: NOTES89 and NOTES89D
• Commodore Business Machines: V3.1 Amiga Developer Update Disk Set, Commodore, 1994. CATS part number: AMDEV3.1 (jetzt Bestandteil der The Developer CD)
• Commodore Business Machines: 1988 Amiga Developers Conference Notes Commodore, 1988. CATS part numbers: NOTES88 and NOTES88D
• Stephen Levy: Amiga Programmer's Guide, Compute! Publications, 1986. ISBN 0-87455-028-9
• Eugene P. Mortimore: Amiga Programmer's Handbook, Sybex, 1985. ISBN 0-89588-343-0

Weblinks

• Amiga goes PowerUP Inoffizielle PowerUP-Support-Website
• Geschichte des PowerPC auf dem Amiga (englisch)
• EHF Spezifikation
• Haage&Partner
• Amiga International (englisch)

Ausführbare Binär- und Objekt-Formate

a.out • COFF • COM • ECOFF • ELF • Hunk • Mach-O • MZ • NE • OMF • PE • PEF • XCOFF