Architecture

The architecture of AROS can be described as a modern reimplementation of the classic AmigaOS design. It keeps the Amiga-like structure and programming model, but is written as an open-source operating system that can run on different hardware platforms. Basic idea AROS is not simply an emulator. It is an operating system that is designed to be source-compatible with AmigaOS where possible. This means that software written for AmigaOS can often be recompiled for AROS, especially if it uses standard system APIs. Its architecture is modular. The system is built from many components such as libraries, devices, handlers, classes, and system services. Main architectural layers 

1. Kernel and Exec layer 

At the lowest level is the Exec-like kernel. This is inspired by AmigaOS Exec.

It is responsible for:
task scheduling
memory management
message passing
interrupts
semaphores and signals
system lists and resources
basic device and library management

AROS, like AmigaOS, uses a lightweight multitasking model. Programs run as tasks or processes and communicate through message ports. 

2. Libraries 

AROS uses shared system libraries heavily. Instead of putting all functionality into one large kernel, many services are provided through libraries. 

Examples include: 
graphics.library
intuition.library
dos.library
utility.library
layers.library
gadtools.library

Applications call these libraries to access system functions. This is very similar to classic AmigaOS.

Common AROS libraries

exec.library 
Core system library that provides multitasking, memory management, signals, message ports, and basic system services. 

dos.library 
Handles files, directories, volumes, command execution, processes, assigns, and Shell-related functions.
 
intuition.library 
Manages the graphical user interface, including screens, windows, menus, gadgets, and user input events. 

graphics.library 
Provides low-level graphics functions such as drawing, bitmaps, colors, viewports, and display handling.
 
layers.library Supports overlapping windows and layered screen areas used by the graphical interface. 

utility.library Offers general helper functions, including tag handling, hooks, lists, string utilities, and system support routines. 

gadtools.library 
Provides standard GUI gadgets and tools for building simple Amiga-style application interfaces. 

asl.library 
Provides standard requesters, such as file requesters, font requesters, and screen-mode requesters. 

icon.library 
Handles icon files and icon-related information used by Wanderer and desktop applications. 

datatypes.library 
Allows applications to load and display different file formats through a common datatype system. 

diskfont.library 
Loads and manages fonts stored on disk so they can be used by applications and the system. 

locale.library 
Provides localization support for languages, regional settings, catalogs, dates, and formatting. 

keymap.library 
Handles keyboard layouts and translates physical key input into characters according to the selected keymap. 

commodities.library 
Supports small background tools, hotkeys, and system-wide input utilities known as commodities.
 
iffparse.library 
Provides routines for reading and writing IFF-based file formats commonly used on Amiga-like systems. 

muimaster.library 
Provides the base for Zune, AROS’s MUI-compatible object-oriented GUI toolkit. 

workbench.library 
Provides desktop-related support functions for Workbench-like behavior used by Wanderer and applications. 

rexxsyslib.library 
Provides ARexx-compatible scripting support where available, allowing programs to communicate through scripts.

3. Devices 

Devices provide low-level access to hardware or virtual hardware. They are not necessarily physical devices; they are system modules that offer a standard interface. 

Typical examples are: 
keyboard device
timer device
input device
audio device
storage devices
serial or parallel devices

Applications and system components communicate with devices using I/O requests and message passing. 

Common AROS devices 

timer.device 
Provides timing functions, delays, alarms, and time-based events for applications and system components. 

input.device 
Collects and distributes input events from keyboard, mouse, and other input sources.

keyboard.device 
Handles keyboard input and passes key events into the input system. 

console.device 
Provides text console windows used by the Shell and command-line programs. 

audio.device 
Offers basic audio output services and sound-related I/O functions. 

trackdisk.device 
Controls floppy disk access on systems that support Amiga-style disk drives. 

scsi.device 
Provides access to hard disks and other mass-storage devices through SCSI-like interfaces.

ahi.device 
Used by AHI-compatible audio systems for more advanced sound playback and recording support.

gameport.device 
4Handles joystick, mouse, and game controller input on compatible systems. 

parallel.device 
Provides access to parallel-port hardware, traditionally used for printers and other peripherals.

serial.device 
Provides access to serial-port communication for modems, terminals, or other serial devices.

clipboard.device Supports clipboard-style data exchange between applications.4

4. DOS layer 

The DOS layer manages files, directories, volumes, command execution, and processes from the user’s point of view. 

It handles: 
files and directories
assigns
volumes
paths
command execution
Shell interaction
startup scripts

This is where concepts like SYS:, C:, LIBS:, DEVS:, S: and Prefs: become important. 5. Filesystem and handlers AROS uses handlers and filesystems to access different storage systems. 

A handler can represent: 
a disk filesystem
a console
a pipe
a network resource
another virtual device

This flexible design comes directly from the Amiga tradition. For example, CON: or RAM: behave like special devices that can be accessed through file-like paths. 

6. Graphics system 

The graphics system provides screen, window, bitmap, and drawing support. 

Important parts include:
graphics.library for low-level graphics
layers.library for overlapping windows
intuition.library for windows, screens, menus, and gadgets

AROS keeps the Amiga concept of separate screens. Applications can open their own screens or use the public screen. 

7. Intuition and GUI systemIntuition is the central GUI system. 

It manages: 
windows
screens
menus
mouse and keyboard events
gadgets
requesters
user interaction

On top of this, AROS also uses higher-level GUI systems such as Zune, which is an open-source implementation inspired by MUI. 8. Wanderer desktop The standard AROS desktop is called Wanderer. It is comparable to Workbench on AmigaOS. 

Wanderer provides: 
icons
drawers
desktop windows
file management
program launching
drag and drop

It sits above the lower system layers and uses the standard AROS APIs. 

9. Hardware abstraction 

AROS is designed to run on different architectures, including: 
x86
x86-64
ARM
PowerPC
m68k

Because of this, hardware-specific code is separated from portable system code where possible. On hosted versions, AROS runs on top of another operating system like Linux or Windows. On native versions, it talks more directly to the hardware. 

Native, hosted, and m68k versions 

AROS can exist in different forms: 
Native AROS Boots directly on hardware 
Hosted AROS Runs as a program on another OS 
m68k AROS Runs on Amiga-like m68k systems or UAE AROS ROM Can replace or complement Kickstart-like functionality 

This flexibility is one of the major architectural differences compared with the original AmigaOS. 

How programs interact with AROS 

A typical AROS program does not access hardware directly. Instead, it uses system APIs. 

For example: 
to open a window, it uses Intuition
to draw graphics, it uses graphics.library
to read files, it uses dos.library
to use timers, it sends requests to timer.device
to build a GUI, it may use Zune or GadTools

This keeps programs more portable and better integrated into the system. 

Summary AROS is built around a classic Amiga-style architecture: small system modules, shared libraries, message passing, devices, handlers, and a lightweight Exec-like kernel. Its goal is to preserve the Amiga programming model while making the system open-source, portable, and adaptable to modern or alternative hardware. It feels familiar to AmigaOS users but is structured so it can run on several platforms, from real m68k systems and UAE to x86 and hosted environments.