The Amiga Hunk format is the native file format of AmigaOS for loadable files (including all executable files), object code and link libraries.
Loadable files begin with the magic ID
00 00 03 F3. "Loadable" includes all directly executable files, as well as shared libraries, device drivers, filesystem handlers, datatypes and other "plugins".
Object code and link libraries begin with the magic ID
00 00 03 E7. These files have to be combined into a loadable file using a linker to get an executable program.
Hunks themselves can contain optional blocks, for code relocations and debug symbols.
All Amiga programs share the same address space and are loaded to wherever there is free memory. They cannot be loaded to specific absolute addresses. This means code must either be written in a position-independent fashion, or it can use relocation blocks to specify where the loader has to fix up absolute address references.
Amiga programs do their own dynamic linking with OS functions such as OpenLibrary, which loads and returns a pointer to a shared library, whose functions can then be executed by jumping to specific offsets from the pointer. This is unlike Windows and UNIX where the loader is expected to fetch and link in other libraries while loading the program.
The loadable format is limited compared to the object code format. Many types of hunk and block are intentionally unrecognised by the AmigaOS LoadSeg() function in order to keep the core OS complexity low. The format is as follows:
- A fixed header (HUNK_HEADER) including a count of all hunks to follow and their lengths
- One or more HUNK_CODE, HUNK_DATA or HUNK_BSS hunks, each of which comprises:
- The code/data for a code/data hunk
- Zero or more blocks for this hunk: all can have HUNK_SYMBOL or HUNK_DEBUG blocks. Code/data can also have HUNK_RELOC32, HUNK_RELOC32SHORT, HUNK_DREL32 or HUNK_ABSRELOC16 relocation blocks
- Hunks always end with a HUNK_END block
The load format also supports overlays (HUNK_OVERLAY and HUNK_BREAK), where the file is not fully loaded, but control is passed to an overlay manager, which can then decide to load or unload hunks at any time, allowing a program to be much larger than would fit in memory, provided the program can keep track of which of its parts need to be in RAM at any given them. There is a "standard" overlay manager and overlay format, but programs do not have to use it.