Article 7: AmigaOS Under the Hood – Libraries, Devices and Handlers

In the previous article, we followed the Amiga from power-on through Kickstart, the boot process and finally to Workbench.

Now we can go one level deeper.

One of the most interesting characteristics of AmigaOS is that the operating system is not a single large program. Instead, it consists of many relatively small components that cooperate with each other.

Three particularly important types of components are:
Libraries
Devices
Handlers

They may initially sound similar, but they perform quite different jobs.

Understanding them is an important step toward understanding how AmigaOS really works.

1. The Modular Architecture of AmigaOS

Programs normally do not need to control every piece of hardware or implement every operating-system function themselves.

Instead, they use services provided by the operating system.

For example, a program might:

use graphics.library to perform graphics operations,
use intuition.library to create windows and user-interface elements,
communicate with serial.device to use the serial port,
or access a file through AmigaDOS.

This separation makes the operating system highly modular.

2. Exec: The Foundation

Before looking at libraries and devices, we should briefly return to Exec.

Exec is the fundamental system component underneath much of AmigaOS.

It provides essential mechanisms including:
task scheduling
memory allocation
interrupt handling
message passing
library management
device management

Exec also maintains important system structures.

For example, applications can ask Exec to open a library.

Conceptually:

Application
|
| OpenLibrary()
v
Exec
|
v
graphics.library


The application does not need to know where the library exists in memory. Exec manages that part of the process.

This principle appears throughout AmigaOS:
Applications ask the operating system for a service rather than directly manipulating the internal implementation of that service.

3. What Is an Amiga Library?

An Amiga library is a collection of functions that can be shared by multiple programs.

Instead of every program implementing the same functionality independently, applications can call functions provided by a library.

Some famous Amiga libraries include:
exec.library
dos.library
graphics.library
intuition.library
utility.library
icon.library
diskfont.library


Each library has a particular purpose.

For example:

dos.library AmigaDOS functionality
graphics.library Graphics operations
intuition.library Windows, screens and GUI handling
icon.library Workbench icon handling
diskfont.library Access to disk-based fonts
utility.library General utility functions

Libraries therefore allow programs to share operating-system functionality.

4. ROM Libraries and Disk Libraries

Not every library has to be stored as a file on disk.

Some important operating-system components are already contained in Kickstart ROM.

Others can be loaded from disk.

The familiar directory:
LIBS:


is the logical location where AmigaOS can find many disk-based libraries.

On a typical system, LIBS: may be assigned to something similar to:

SYS:Libs/


Applications normally do not care about the physical location.

They simply request a library by name.

For example:

dos.library


This separation between the library's logical identity and its physical storage location is another example of the abstraction used throughout AmigaOS.

5. Opening a Library

Imagine that an application needs functions provided by graphics.library.

In simplified form, the program asks Exec to open it:

OpenLibrary("graphics.library", version);

Exec looks for the requested library.
If the library is available, the application receives a pointer to the library structure and can use the functions provided by it.

Conceptually:

Program
|
| request
v
OpenLibrary()
|
v
Exec
|
+-- Is library already available?
|
+-- If necessary, locate/load it
|
v
Library Base
|
v
Program can call library functions


The concept of a library base is important in classic Amiga programming.
A program keeps a pointer to the opened library and uses that base when accessing its functions.

6. Library Versions

Amiga libraries also have version numbers.
A program can request a minimum version when opening a library.

For example, conceptually:
Open graphics.library version 39 or newer

If the required version is not available, the program can detect the problem instead of blindly attempting to use functions that may not exist.
This became increasingly important as AmigaOS evolved.Software written for newer versions of AmigaOS could therefore explicitly depend on newer library functionality.
 
7. Libraries Can Be Shared

One of the major advantages of the library system is that libraries are shared.

Imagine three applications:

Program A
Program B
Program C


All three need graphics functions.

They do not each require a separate implementation of the graphics system.

Instead:

Program A ----\
Program B -----+----> graphics.library
Program C ----/

This saves memory and provides a common interface to operating-system functionality.

AmigaOS keeps track of libraries that are in use. Programs should therefore properly open the libraries they require and close them again when they are finished.

8. What Is an Amiga Device?

The word device can be slightly confusing.
In everyday computer terminology, a device usually means physical hardware:

a keyboard
a hard disk
a printer
a serial port

In AmigaOS, however, a .device is normally a software component providing a standardized interface to some type of I/O functionality.

Examples include:

trackdisk.device
serial.device
parallel.device
printer.device
audio.device
timer.device

A device may communicate with hardware, but the device itself is software.

This distinction is important:

Hardware ≠ AmigaOS Device

Rather:

Program
|
v
AmigaOS Device
|
v
Hardware / system resource

The device provides an abstraction between applications and the underlying resource.

9. Example: serial.device

Consider a program that wants to communicate through the Amiga's serial interface.

The program should not need to know every detail of the serial hardware.

Instead, it can communicate with:

serial.device

Conceptually:

Application
|
v
serial.device
|
v
Serial hardware
|
v
External device


This has an important advantage.

Applications can use a defined operating-system interface instead of directly controlling hardware registers.

10. Device I/O

Devices work differently from normal libraries.

With a library, a program usually calls functions and receives the result.
Device communication is generally organized around I/O requests.
A program creates an I/O request describing what operation should be performed.

In simplified form:

Application
|
| I/O Request
v
Device
|
| performs operation
v
Hardware / Resource

The completed request can then return information to the application.
This mechanism fits naturally into the message-based design of Exec.

11. Synchronous and Asynchronous I/O

One particularly interesting characteristic of Amiga device I/O is that operations can be performed in different ways.

A program may issue an operation and wait until it completes.

Conceptually:

Send request
|
v
Wait
|
v
Request finished
|
v
Continue

But I/O can also be performed asynchronously.
The program can start an operation and continue doing other work while the request is being processed.

Application
|
+----> Start I/O
|
+----> Continue working
|
+<---- I/O completed

This fits very well with the Amiga's multitasking architecture.
A program does not necessarily have to stop completely while an external operation is taking place.

12. Devices and Exec Message Passing

This brings us to one of the most elegant aspects of AmigaOS: message passing.
Exec provides message ports that allow tasks to exchange messages.

A simplified communication model can look like this:

Task
|
| sends request
v
Message Port
|
v
Device
|
| operation completes
v
Message Port
|
v
Task

Message passing appears in many parts of the Amiga operating system.
It allows relatively independent components to communicate without becoming tightly coupled to each other's internal implementation.
This is one reason why understanding Exec is so important when studying AmigaOS internals.

13. But What Is a Handler?

Handlers belong primarily to the AmigaDOS world.
They provide DOS-style access to resources.
This is an important distinction.
A device typically provides an Exec-level I/O interface.

A handler can make a resource accessible through the familiar AmigaDOS naming system.

For example:

RAM:
CON:
SER:
PAR:
PIPE:

These names behave like DOS resources.

You can often interact with them using normal AmigaDOS commands.

For example:
COPY file.txt TO RAM:

Here RAM: behaves much like a disk volume.
But RAM: is not a physical disk.
Instead, the DOS system presents a RAM-based filesystem through the appropriate system components.

14. Devices and Handlers Are Not the Same Thing

This distinction is extremely important.

A device generally provides low-level I/O functionality through Exec.
A handler provides a resource through the AmigaDOS filesystem-style interface.
A simplified comparison looks like this:

Component Main Interface Typical PurposeLibrary Function calls Shared operating-system services
Device I/O requests Device/resource access
Handler DOS packets DOS/filesystem-style resource access

This is why a device and a handler should not be treated as interchangeable concepts.

15. Example: SER:

Consider:
SER:


From the AmigaDOS user's perspective, this looks like another DOS device.

You can conceptually perform operations such as:

COPY test.txt TO SER:

But internally there may be several layers involved.

A simplified model is:

COPY command
|
v
AmigaDOS
|
v
SER: handler
|
v
serial.device
|
v
Serial hardware

This demonstrates one of the central ideas behind AmigaOS:
A simple command at the user level may pass through several independent operating-system components before reaching the hardware.
Each layer has its own responsibility.

16. Why Do Handlers Exist?

Handlers allow AmigaDOS to treat very different resources through a relatively consistent interface.

A program operating at the DOS level can work with names such as:

DF0:
DH0:
RAM:
CON:
SER:
PIPE:


These resources are obviously not all the same type of thing.
DF0: may represent a floppy drive.
RAM: represents a filesystem held in memory.
CON: represents a console window.
SER: provides access related to the serial interface.

Yet AmigaDOS can expose them through a common naming concept:

NAME:

This is a remarkably powerful abstraction.

17. The Importance of L:

Handlers and related system components are traditionally associated with the logical system directory:

L:

On a normal system this may correspond to: SYS:L/

The directory can contain components such as filesystem handlers. For example, classic systems may contain components associated with filesystems and other DOS functionality here.

This gives us another useful distinction between two familiar directories:
LIBS:

contains libraries, while: L: contains handlers and related AmigaDOS components

They serve very different purposes despite both containing operating-system modules.

18. DOS Packets

Handlers communicate with AmigaDOS using messages commonly known as DOS packets.

Suppose an application wants to access:

RAM:example.txt

AmigaDOS determines which subsystem is responsible for RAM:.
Requests relating to the file can then be passed to the appropriate handler.

Conceptually:

Application
|
v
dos.library
|
v
AmigaDOS
|
| DOS packet
v
Handler
|
v
Requested resource

The handler receives requests such as operations involving files or directories and performs the appropriate work.
Again we see the Amiga philosophy of independent components communicating through defined interfaces.

19. A Practical Example: Opening a File

Suppose an application performs something conceptually equivalent to:

Open("RAM:example.txt", MODE_OLDFILE);

Several layers can be involved.

The application uses DOS functionality.

AmigaDOS examines:

RAM:example.txt

and identifies RAM: as the filesystem or DOS device responsible for the path.

The request is routed to the relevant handler.

The process can therefore be imagined as:

Application
|
v
dos.library
|
v
AmigaDOS
|
v
RAM: Handler
|
v
RAM Filesystem

From the application's point of view, however, it simply opened a file.
That is abstraction in action.

20. Library vs Device vs Handler

We can now summarize the three concepts.

Library

Provides functions that programs can call.

Example: graphics.library

Think: "I need an operating-system function."

Device

Provides an Exec-compatible I/O interface to a device or system resource.

Example: serial.device

Think: "I need to perform an I/O operation."

Handler

Provides DOS-style access to a resource.

Example: CON:

Think: "I need to access a resource through AmigaDOS."

21. The Bigger Picture

Now we can expand our earlier overview of AmigaOS:

AmigaOS is built from many cooperating components rather than one monolithic block.

Applications can combine these services as required.

22. Why This Architecture Matters

This modularity has several advantages.
Components can be shared
Multiple programs can use the same libraries and operating-system services.
Hardware access can be abstracted
Programs can communicate through devices instead of directly programming hardware.
Resources can be represented logically
Handlers allow very different resources to appear through the AmigaDOS naming system.
Components can be replaced or extended
Parts of the operating-system environment can be loaded from disk and added to the running system.
Multitasking is built deeply into the design
Tasks, message ports, asynchronous I/O and message-based communication are fundamental parts of the architecture rather than features added later.

23. A Useful Mental Model

For beginners, the following mental model is useful:

Librar = functions

Device = I/O

Handler = DOS resource

That is deliberately simplified, but it makes the three concepts much easier to distinguish.

When you encounter: graphics.library
think about functions.

When you encounter: serial.device
think about I/O requests.

When you encounter: CON:
think about AmigaDOS access to a resource.

This simple distinction provides a good foundation for exploring the system in greater depth.

Conclusion

The internal architecture of AmigaOS can initially appear unusual because concepts such as libraries, devices, handlers, assigns and DOS devices do not correspond directly to the structures familiar from modern Windows, macOS or Linux systems.

But there is a clear philosophy behind it.

AmigaOS consists of independent components with well-defined responsibilities:

Libraries → provide functions
Devices → provide I/O services
Handlers → provide DOS-style resources
Exec → provides the foundation connecting many of these components

Once this concept is understood, many other parts of AmigaOS suddenly become easier to understand.

In particular, names such as:
C:
DEVS:
L:
LIBS:
S:
ENV:
RAM:
CON:

no longer appear to be a strange collection of disks and directories. They are parts of a carefully structured logical operating-system environment.

And that brings us naturally to Article 8: “Inside the Amiga System Disk – C:, DEVS:, L:, LIBS:, S: and More”, where we can explore the complete AmigaOS directory structure, explain what belongs in each location, and follow practical examples of how these directories work together.