Amiga Hunk

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 25. Juni 2023 um 11:44 Uhr durch Aeroid (Diskussion | Beiträge) (→Referenzen). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen
Eine gesichtete Version dieser Seite, die am 25. Juni 2023 freigegeben wurde, basiert auf dieser Version.

Hunk ist das ausführbare Dateiformat von Programmen unter dem klassischen AmigaOS (bis zur Version 3.9) für Amigas basierend auf Prozessoren der Motorola 68000er-Familie. Ursprünglich wurde es von METACOMCO plc. im Rahmen von Tripos definiert, welches in AmigaDOS aufging.[1]

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.[2] 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 der 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. 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 einen Teil seiner Metadaten in den sogenannten .info-Filialdateien 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 die 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 die 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 beiliegenden 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

  • Commodore-Amiga Inc.: The AmigaDOS Manual. Bantam Computer, 1986, ISBN 0-553-34294-0 (englisch, archive.org).
  • Commodore-Amiga Inc.: The AmigaDOS Manual Third Edition. Bantam Computer, 1991, ISBN 0-553-35403-5 (englisch, archive.org).
  • 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

Einzelnachweise

  1. ↑ METACOMCO plc.: Introduction to Tripos. 1986 (englisch, archive.org).
  2. ↑ The AmigaDOS Manual, Chapter 10, Amiga Binary File Structture – Internet Archive
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Amiga_Hunk&oldid=234917302“