Amiga Hunk

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (May 2012) (Learn how and when to remove this message)

Hunk is the executable file format of tools and programs of the Amiga Operating System based on Motorola 68000 CPU and other processors of the same family. The file format was originally defined by MetaComCo. as part of TRIPOS, which formed the basis for AmigaDOS.^[1] This kind of executable got its name from the fact that the software programmed on Amiga is divided in its internal structure into many pieces called hunks, in which every portion could contain either code or data.

The hunks in an Amiga executable file could exist in various types. There are 32-bit hunks, 16-bit hunks, and even some 8-bit hunks.

Types of hunks were standardized in AmigaOS, and well documented in The AmigaDOS Manual edited by Commodore to explain to programmers how to code on the Amiga, during the years in which Commodore manufactured Amiga computers. Their structure was officially codified and could be changed only by a Commodore committee, which then communicated the modifications to the developers for new releases of the Amiga operating system.

The structure of an Amiga hunk is very simple: There is a header at the beginning of the hunk indicating that that kind of "portion of code" is a known and valid Amiga hunk type, then follows an ID which indicates the length of the hunk itself, and at the bottom is the segment of the hunk which contains the real code or data.

Amiga executable files can be launched either from the graphical shell of the Amiga, the Workbench or from the Amiga's command line interpreter (called CLI, later AmigaShell).

No particular filename extension is required for Amiga executable files. For example, the calculator applet "Calculator" can be renamed to "Calculator.com", "Calculator.exe", "Calculator.bin", or even "Calculator.jpeg". These are all valid names for programs or tools, because AmigaOS does not differentiate between filename extensions.

AmigaOS adopted another method to recognize it is dealing with a valid executable. There is a particular sequence of bytes in the file header, yielding the hexadecimal value $000003f3. This sequence, which signifies an executable file and lets it be self-running, is called a magic cookie (from the magic cookies in Alice's Adventures in Wonderland by Lewis Carroll).^{[citation needed]}

This kind of solution to identify executables on the Amiga was taken from similar solutions which were adopted by UNIX/Unix-like operating systems, where magic cookies are called magic numbers.

This section may be confusing or unclear to readers. In particular, it does not clearly explain what the file header actually consists of. Please help clarify the section. There might be a discussion about this on the talk page. (May 2015) (Learn how and when to remove this message)

The internal structure of an Amiga executable file is very simple. In the beginning of the file there is the magic cookie, then is declared the total number of hunks in the executable, and just after this is the progressive numbers of hunks starting from "0" (zero).

The first hunk is always numbered zero, so if the executable is (for example) subdivided into three hunks, they will be numbered "0" for the first one, "1" the second and "2" the third hunk, and so on.

Just before the real hunks start is a table containing information about the length of any hunks present in the executable, and in the last part of the file are positioned the real hunks, each one described by its type name: HUNK_CODE, HUNK_DATA, et cetera.

Representation of the structure:

Known hunk types for the Amiga are:

* Extended Hunk Format

The Amiga could save metadata into hunks, as the hunk structure could be easily adapted to support this feature, but the hunk format of executables was abandoned in favour of ELF and there is no central authority (as the dismissed Commodore) which could implement this feature as one of the Amiga standards.

The Amiga saves some metadata into sidecar files known as ".info" (so called from the name of their extension suffix).

".info" files may be created any time a project (datafile) is saved on disk. Example: When user saves a file called "MyProject" two files may be created on disk called "MyProject" and MyProject.info".

The "MyProject" file contains the real data of the project file, while the "MyProject.info" file contains the icon, and the information regarding the software which originated the file, so any time the project icon is invoked by clicking on it with mouse, the parent software will be opened (users can change this information at any time, allowing other programs to believe they created the project file rather than the original software which physically created it).

Application Binding does not exist in AmigaOS as in other systems like MacOS.

The ".info" file also contains some particular characteristics of the project file and the user comments.

".info" files do not appear on the Workbench Screen (Workbench is the default Amiga Desktop GUI). On the desktop screen only the icon of the project file taken out of the "info" file appears. In fact the icon is the virtual medium that connects the project itself and the metadata stored into ".info".

When the user clicks on the icon with left mouse button, the project ".info" calls the program which originated it. When the user clicks on the icon and chooses the appropriate menu item, then a dialog box will appear, allowing the user to interact with metadata contained in the ".info" file.

The ".info" files are copied or moved together with their associated project file, by moving the icon with the mouse, and can be viewed as a standalone file through the command line interfaces of Amiga such as AmigaShell, or using third party filemanagers or directory listers like Directory Opus or DiskMaster.

If the ".info" file represents an executable program, then the ".info" file contains information about the stack of RAM buffers that could be reserved to the executable file (e.g. 4096, 8192 or 16384 or more bytes of RAM) and even the arguments that could be invoked by using a command line interface. For example, an Amiga program could open its own graphic user interface screen independent from the desktop screen. By invoking arguments such as "Screen=800x600" and "Depth=8" into the info file dialog box, the user can save this information into the associated ".info" file and then program would open the productivity software into its own screen sized 800×600 with 8 bits of colour depth (equal to 256 colors).

The user can also delete ".info" files, but then they will renounce the benefits of having an icon representing the project file on the desktop, and will also lose all the metadata contained in it.

The HUNK_OVERLAY type was intended to reduce the amount of RAM needed to run a program. Executables with an overlay structure have a root node which is in memory at all times, and the rest of the program is split into smaller modules which are loaded and unloaded automatically when needed.^[3]

The Overlay format works by adding little stubs to code so that when they branch into a sub-module, it calls an overlay manager, which loads the requisite module. Commodore defined a standard overlay manager so that C code could automatically have these stubs inserted, and also generate an overlay table, which the standard overlay manager knew how to read.

However, the Overlay format was rarely used, especially in the way it was intended. It was more commonly used with a custom overlay manager. A popular use of overlay format was with the Titanics Cruncher,^[4] which compressed executables. Instead of loading the entire compressed executable into memory before unpacking, the Titanics Cruncher used an overlay, so only a tiny decruncher was loaded into memory, then it read and decompressed data as it went.

With third party add-ons AmigaOS up to 3.9 recognizes various kinds of executable files other than Hunk format created for Motorola 68000.

• Comparison of executable file formats
• vasm, a free assembler part of vbcc

• 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

(information from this set of floppies distributed by Commodore to Amiga developers are obsolete and updated and replaced into "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

• Amiga goes PowerUP Unofficial PowerUP Support Homepage
• Third party description of Amiga hunk format