Hunk is the executablefile format of tools and programs of the Amiga Operating System based on Motorola68000CPU 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.
Features of Amiga executable files
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.
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:
Magic Cookie
Total number of hunks
Progressive number of hunks
Table of length
Various Hunks (Hunk_Code, Hunk_Data, etc.)
Hunk Types
Known hunk types for the Amiga are:
Name
Value (decimal)
Value (hex)
HUNK_UNIT
999
3E7
HUNK_NAME
1000
3E8
HUNK_CODE
1001
3E9
HUNK_DATA
1002
3EA
HUNK_BSS
1003
3EB
HUNK_RELOC32
1004
3EC
HUNK_RELOC16
1005
3ED
HUNK_RELOC8
1006
3EE
HUNK_EXT
1007
3EF
HUNK_SYMBOL
1008
3F0
HUNK_DEBUG
1009
3F1
HUNK_END
1010
3F2
HUNK_HEADER
1011
3F3
HUNK_OVERLAY
1013
3F5
HUNK_BREAK
1014
3F6
HUNK_DREL32
1015
3F7
HUNK_DREL16
1016
3F8
HUNK_DREL8
1017
3F9
HUNK_LIB
1018
3FA
HUNK_INDEX
1019
3FB
HUNK_RELOC32SHORT
1020
3FC
HUNK_RELRELOC32
1021
3FD
HUNK_ABSRELOC16
1022
3FE
HUNK_PPC_CODE *
1257
4E9
HUNK_RELRELOC26 *
1260
4EC
* Extended Hunk Format
Metadata
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.
Icons
A brief view of the bitmap icons contained into ".info" metadata files:
The icons are RAW bitmap data contained in ".info" files and are not standard Amiga IFF/LBM files. The users can deal with icons by using the AmigaOS standard program "IconEdit", present in the operating system since its early versions. Starting from AmigaOS version 2.0, IconEdit could import and save normal IFF/LBM files used as standard graphics files in AmigaOS.[2]
Some Amiga programs like Personal Paint from Cloanto are able to view, load and save bitmap data as normal Amiga Icons or as Amiga ".info" files already existing.
Legacy Amiga Icons can have two-state icons, using two different bitmap images. The first bitmap contains the data of the "quiet" icon, also known as the "quiet state" of the icon. The second bitmap image contains data of the "selected" state of the icon. When the user clicks on an icon and activates it, then the quiet icon bitmap data is suddenly replaced by the selected icon bitmap data. Such behaviour gives the Amiga icons the effect of moving cartoons. In case this second bitmap does not exist in the ".info" file (it is not mandatory to create both bitmaps), then an inverse color effect is used when the icon is selected.
Third-party icon "engines" exist, which try to keep the look of AmigaOS up to date with modern standards of other Operating Systems. These programs patch the OS routines dedicated to icon handling, replacing them with custom ones. One of such attempts, NewIcons, has become almost the new de facto standard for AmigaOS 3.x. It was so popular that the new icon system used in AmigaOS 3.5 and above, GlowIcons, is based on its icon file format.
All modern Amiga-like operating systems (AmigaOS 4, MorphOS and AROS) could associate either RAW bitmap data, IFF/LBM files or also PNG files as standard internal bitmap image of any icon.
Overlaid executables
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.
Other executable file formats used on Amiga
With third party add-ons AmigaOS up to 3.9 recognizes various kinds of executable files other than Hunk format created for Motorola 68000.
ELF
Phase5 implemented ELF executables for its PowerUP accelerator boards. It was found cumbersome due to its dynamic linking. This format was then adopted as standard by AmigaOS 4.0, MorphOS and AROS. ELF support was added to WarpUp by 3rd party developers and Hyperion Entertainment released number of WarpUp games in ELF format only.[5]
Extended Hunk format
In 1997 Haage & Partner developer WarpUp PowerPC kernel for PowerUP accelerator boards. Instead of ELF binary format they had chosen to expand existing hunk format. Problem with ELF binary format was that users had to patch their system to load ELF executables and mixing PPC/68k code was not possible. Extended Hunk Format (EHF), developed by Haage & Partner, allowed mixing PPC and 68k code to single executable without modifying the existing system if PowerPC accelerator was not installed. [1][2].
AmigaOS 4 and MorphOS
AmigaOS 4.0 and MorphOS can run ELF natively, but as these systems were designed to run on PowerPC processor-based machines, the developers added also compatibility for WarpUP software, used in AmigaOS 3.9. In addition MorphOS implements PowerUp software compatibility as implemented by Phase5 for PowerUP accelerator cards.
Both new operating systems can also run Amiga Hunk format because they implement the old Amiga API environment based on AmigaOS 3.1, and can run 68000 code through emulation.
In computing, the Executable and Linkable Format, is a common standard file format for executable files, object code, shared libraries, and core dumps. First published in the specification for the application binary interface (ABI) of the Unix operating system version named System V Release 4 (SVR4), and later in the Tool Interface Standard, it was quickly accepted among different vendors of Unix systems. In 1999, it was chosen as the standard binary file format for Unix and Unix-like systems on x86 processors by the 86open project.
Interchange File Format (IFF) is a generic digital container file format originally introduced by Electronic Arts in 1985 to facilitate transfer of data between software produced by different companies.
AmigaDOS is the disk operating system of the AmigaOS, which includes file systems, file and directory manipulation, the command-line interface, and file redirection.
The resource fork is a fork or section of a file on Apple's classic Mac OS operating system, which was also carried over to the modern macOS for compatibility, used to store structured data along with the unstructured data stored within the data fork.
A filename extension, file name extension or file extension is a suffix to the name of a computer file. The extension indicates a characteristic of the file contents or its intended use. A filename extension is typically delimited from the rest of the filename with a full stop (period), but in some systems it is separated with spaces.
The Amiga Fast File System is a file system used on the Amiga personal computer. The previous Amiga filesystem was never given a specific name and known originally simply as "DOS" or AmigaDOS. Upon the release of FFS, the original filesystem became known as Amiga Old File System (OFS). OFS, which was primarily designed for use with floppy disks, had been proving slow to keep up with hard drives of the era. FFS was designed as a full replacement for the original Amiga filesystem. FFS differs from its predecessor mainly in the removal of redundant information. Data blocks contain nothing but data, allowing the filesystem to manage the transfer of large chunks of data directly from the host adapter to the final destination.
A FourCC is a sequence of four bytes used to uniquely identify data formats. It originated from the OSType or ResType metadata system used in classic Mac OS and was adopted for the Amiga/Electronic Arts Interchange File Format and derivatives. The idea was later reused to identify compressed data types in QuickTime and DirectShow.
The XAD system is an open-source client-based unarchiving system for the Amiga. This means there is a master library called xadmaster.library which provides an interface between the client and the user application and there are clients handling the special archive formats. Three different types to handle file and disk archives and also disk image files (filesystem) are possible. They can be made by anyone. The master library itself includes some of these clients internally to make the work somewhat easier for the package maintainer and the user installing it.
NewIcons is a third-party extension to the icon handling system for AmigaOS 2 and newer. NewIcons was first invented and developed by the Italian programmer Nicola Salmoria. Subsequent development was done by Eric Sauvageau and Phil Vedovatti.
AmigaOS is the proprietary native operating system of the Amiga personal computer. Since its introduction with the launch of the Amiga 1000 in 1985, there have been four major versions and several minor revisions of the operating system.
Workbench is the desktop environment and graphical file manager of AmigaOS developed by Commodore International for their Amiga line of computers. Workbench provides the user with a graphical interface to work with file systems and launch applications. It uses a workbench metaphor for representing file system organisation.
AmigaOS 4 is a line of Amiga operating systems which runs on PowerPC microprocessors. It is mainly based on AmigaOS 3.1 source code developed by Commodore, and partially on version 3.9 developed by Haage & Partner. "The Final Update" was released on 24 December 2006 after five years of development by the Belgian company Hyperion Entertainment under license from Amiga, Inc. for AmigaOne registered users.
This article deals with productivity software created for the Amiga line of computers and covers the AmigaOS operating system and its derivatives AROS and MorphOS. It is a split of the main article, Amiga software.
Amiga support and maintenance software performs service functions such as formatting media for a specific filesystem, diagnosing failures that occur on formatted media, data recovery after media failure, and installation of new software for the Amiga family of personal computers—as opposed to application software, which performs business, education, and recreation functions.
WarpOS is a multitasking kernel for the PowerPC (PPC) architecture central processing unit (CPU) developed by Haage & Partner for the Amiga computer platform in the late 1990s and early 2000s. It runs on PowerUP accelerator boards developed by phase5 which contains both a Motorola 68000 series CPU and a PowerPC CPU with shared address space. WarpOS runs alongside the 68k-based AmigaOS, which can use the PowerPC as a coprocessor. Despite its name, it is not an operating system (OS), but a kernel; it supplies a limited set of functions similar to those in AmigaOS for using the PowerPC. When released, its original name was WarpUP, but was changed to reflect its greater feature set, and possibly to avoid comparison with its competitor, PowerUP.
Sidecar files, also known as buddy files or connected files, are computer files that store data which is not supported by the format of a source file.
AmigaOS is a family of proprietary native operating systems of the Amiga and AmigaOne personal computers. It was developed first by Commodore International and introduced with the launch of the first Amiga, the Amiga 1000, in 1985. Early versions of AmigaOS required the Motorola 68000 series of 16-bit and 32-bit microprocessors. Later versions were developed by Haage & Partner and then Hyperion Entertainment. A PowerPC microprocessor is required for the most recent release, AmigaOS 4.
A file format is a standard way that information is encoded for storage in a computer file. It specifies how bits are used to encode information in a digital storage medium. File formats may be either proprietary or free.
This is a comparison of binary executable file formats which, once loaded by a suitable executable loader, can be directly executed by the CPU rather than being interpreted by software. In addition to the binary application code, the executables may contain headers and tables with relocation and fixup information as well as various kinds of meta data. Among those formats listed, the ones in most common use are PE, ELF, Mach-O and MZ.
References
The AmigaDOS Manual Third Edition (Bantam Books), Commodore Business Machines, July 1991. ISBN0-553-35403-5
Amiga ROM Kernel Reference Manual, Includes and Autodocs (3rd edition; dark gray cover) Addison-Wesley, 1991. ISBN0-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. ISBN0-87455-028-9
Eugene P. Mortimore: Amiga Programmer's Handbook, Sybex, 1985. ISBN0-89588-343-0
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
