Article 2: AROS for Amiga Users – What Is Familiar and What Is Different? 

If you already know AmigaOS, your first experience with AROS can feel strangely familiar. There is a desktop. There is a Shell. There are familiar concepts such as libraries, devices, handlers, assigns and startup scripts. But AROS is not simply another version of AmigaOS. It is an independently developed operating system that follows many of the architectural ideas and APIs of AmigaOS while extending them beyond the original Amiga environment. In this article, we will take a first tour through AROS from the perspective of an Amiga user. 

1. Familiar Territory 

Let us begin with a simple comparison. 

The names may occasionally differ and the implementation can be different, but many of the underlying ideas are familiar. 

2. Workbench and Wanderer 

On a classic Amiga, the graphical desktop environment is Workbench. AROS normally provides a desktop environment called Wanderer. Both serve a similar basic purpose. 

They allow users to interact graphically with:
disks and volumes
drawers
files
programs
system utilities
preferences

If you come from AmigaOS, Wanderer therefore provides a recognizable starting point. However, it is important to distinguish between the desktop and the operating system underneath it. Workbench is not AmigaOS itself. In the same way, Wanderer is not AROS itself. It is a graphical interface through which you interact with the system. This distinction will become important later when we start looking beneath the desktop. 

3. Drawers, Files and Volumes 

Classic Amiga users will immediately recognize the idea of drawers. Where many operating systems normally talk about directories or folders, the graphical Amiga environment traditionally uses the term drawer. The same concept is found in AROS. 

A volume might contain drawers such as:
System:
    C
    Devs
    Libs
    Prefs
    S
    System
    Tools
    Utilities 

The exact contents can vary depending on the AROS distribution and installation. But the organizational philosophy should already look familiar. We encountered many of these names in our Amiga course. 

4. The Importance of Assigns 

One particularly important idea carried over from AmigaOS is the assign. Instead of forcing programs to use fixed physical paths, the operating system can associate logical names with locations. 

For example:
C:
DEVS:
LIBS:
S:
SYS:
T:
ENV: 

These names are not simply ordinary directory names. They provide logical locations that the operating system and applications can use. 

For example, instead of requiring a program to know exactly where a library is physically stored, the system can use: LIBS: This contributes to the flexible structure of AmigaOS and AROS. 

5. SYS: as a Starting Point 

One particularly useful assign is: SYS: 

Conceptually, it represents the system volume or system location. 

For example:
SYS:C
SYS:Devs
SYS:Libs
SYS:Prefs
SYS:S
SYS:System
SYS:Tools 

This gives applications and scripts a predictable way to locate important system components. The physical device or partition containing the system does not have to be hard-coded everywhere. This is a good example of the Amiga philosophy surviving in AROS. 

6. The Shell 

The graphical desktop is only one way to use the operating system. AROS also provides a Shell. For an Amiga user, this environment feels much more familiar than command-line environments such as the Windows Command Prompt or a Unix shell. 

Commands and concepts inherited from the Amiga tradition can include operations such as:
Dir
List
Copy
Delete
Rename
Assign
Path
Set
Echo
Type 

The precise set of commands, options and behavior can vary, so we should not automatically assume that every AmigaDOS command behaves identically under every AROS installation. But the overall command-line philosophy is very similar. Later in this course, we will dedicate several articles specifically to the AROS Shell. 

7. C: and Commands 

In AmigaOS, many Shell commands are stored in: C: 

AROS follows the same general philosophy. The operating system can search command locations through its command path. 

This means that when you enter something such as: Dir you normally do not have to type the complete location of the program every time. 

Instead of entering something like: SYS:C/Dir the Shell can locate the command through its configured search path. Again, this should be very familiar to anyone who followed our Amiga Shell articles. 

8. Libraries 

Another major connection between AmigaOS and AROS is the use of libraries. Applications can open libraries and call functions provided by them. 

Conceptually:

Application
     |
     v
  Library
     |
     v
Operating System 

This modular approach means applications do not have to implement every service themselves. AROS provides numerous system libraries implementing operating-system functionality. The details can differ from classic AmigaOS, but the fundamental principle remains recognizable. This will become especially interesting when we eventually begin programming for AROS. 

9. Devices 

Devices are another familiar part of the architecture. A device provides a standardized software interface through which programs can communicate with particular system services or hardware-related functions. 

Conceptually:

Application
     |
     v
   Device
     |
     v
Driver / Hardware 

On the classic Amiga, we encountered this idea when discussing components such as trackdisk.device, serial.device and other device drivers. AROS continues the device-oriented approach, although the actual devices available depend on the AROS platform and hardware. This is an important difference. A classic Amiga was built around comparatively standardized Amiga hardware. AROS can operate in very different environments. Therefore its hardware support must be much more flexible. 

10. Handlers 

Handlers are another Amiga concept that remains important. A handler can provide a DOS-level interface for a particular type of resource or filesystem. This is one of the reasons why Amiga-style systems can expose very different resources through familiar DOS mechanisms.

Conceptually:

Application
     |
     v
    DOS
     |
     v
  Handler
     |
     v
Resource 

If you found handlers somewhat abstract during the Amiga course, don't worry. When we later examine the AROS filesystem and DOS architecture in more detail, we will return to this subject with practical examples. 

11. Datatypes 

Datatypes are another concept Amiga users may recognize. Instead of requiring every application to contain code for every possible file format, a datatype system can provide standardized support for different forms of data. For example, an application might ask the system to load an image without implementing every image format itself. 

Conceptually:

Application
     |
     v
Datatype system
     |
     +--> JPEG support
     |
     +--> PNG support
     |
     +--> other formats 

The exact datatype support depends on the particular AROS system and installed components. But the architectural idea is very much in the Amiga tradition. 

12. Startup Scripts 

Another familiar area is system startup. In our Amiga course we learned about the importance of startup scripts, especially the traditional:
S:Startup-Sequence AROS also uses Amiga-style startup mechanisms and scripts. 

The general idea remains straightforward:

Computer starts
      |
      v
AROS initializes
      |
      v
System components are loaded
      |
      v
Startup configuration is processed
      |
      v
Desktop environment starts

 We will examine the AROS startup process separately later in the course. That will give us an excellent opportunity to compare it directly with the classic Amiga startup process we studied earlier. 

13. Where AROS Begins to Differ 

So far, everything may sound almost like AmigaOS. But there is a fundamental difference. Classic AmigaOS was originally designed for a specific computer architecture based around Motorola 68000-family processors and the Amiga custom chipset. AROS was designed as a portable operating-system implementation. Therefore, depending on the AROS port or distribution, the environment can be very different from a classic Amiga. 

You are no longer necessarily dealing with:
68000 CPU
+
Agnus
+
Denise
+
Paula 

The underlying hardware could be entirely different. This has major consequences for drivers, memory management and hardware access.

14. No Dependence on the Classic Amiga Chipset 

Remember how important the custom chips were in our Amiga course? 

We examined: 
Agnus
Denise
Paula
DMA
Chip RAM
Blitter
Copper

These components were fundamental to the architecture of the classic Amiga. AROS itself is not fundamentally tied to that chipset. This means we must separate two things in our minds: The Amiga hardware architecture and The AmigaOS software architecture AROS is primarily interesting because it carries forward many ideas from the software architecture without requiring the original Amiga hardware architecture. This is one of the most important concepts to understand about AROS. 

15. Hardware Independence 

Changes Things This portability creates possibilities that the original AmigaOS architecture did not originally need to address in quite the same way. 

Different AROS targets can have different: 
processors
graphics hardware
audio hardware
storage controllers
network interfaces
firmware
system buses

As a result, AROS needs hardware abstraction and drivers appropriate for those environments. This is an area where understanding classic AmigaOS alone is no longer enough. We now have to learn what AROS adds or changes. 

16. Familiar Does Not Mean Identical 

This deserves emphasis. When learning AROS, avoid assuming: “It looks like AmigaOS, therefore it must work exactly like AmigaOS.” A better approach is: “This concept comes from the Amiga world. Let us see how AROS implements it.” That small change in perspective is extremely useful. It allows us to use our existing Amiga knowledge without making incorrect assumptions. 

17. A Useful Mental Model 

We can therefore think of AROS in three layers. 

Layer 1: Familiar Amiga Concepts 

Examples include: 
Exec-style architecture
libraries
devices
handlers
assigns
datatypes
Shell
startup scripts

Layer 2: The AROS Implementation 

AROS independently implements these concepts and provides its own operating-system components. 

Layer 3: The Hardware or Host Environment 

Below AROS can be hardware very different from a classic Amiga. 

This gives us:

Applications
     |
     v
AROS APIs and system components
     |
     v
AROS kernel / Exec-style services
     |
     v
Drivers and hardware support
     |
     v
Hardware / platform 

Keep this model in mind. We will gradually fill in the details throughout the course. 

18. Amiga Knowledge Is Still Extremely Valuable 

Despite all these differences, someone who understands AmigaOS has an enormous advantage when learning AROS. 

Terms such as:
LIBS:
DEVS:
C:
S:
SYS: 

already mean something to us. When we encounter an assign, library, device, handler or Shell command, we already understand the basic idea behind it. We can therefore spend less time asking: “What is this?” and more time asking: “How has AROS implemented it?” And that is exactly the approach we will take throughout this course. Conclusion AROS is simultaneously familiar and different. 

For an Amiga user, familiar concepts are everywhere: 
Wanderer takes the role of the graphical desktop environment.
The AROS Shell continues the Amiga command-line tradition.
Assigns provide logical system paths.
Libraries provide reusable system functions.
Devices provide standardized interfaces.
Handlers integrate resources with DOS.
Datatypes provide standardized handling of data formats.
Startup scripts configure the system.

But underneath those familiar concepts is an independently developed operating system designed to operate beyond the limitations of the original Amiga hardware. That combination is what makes AROS so interesting. Our knowledge of AmigaOS gives us the map. Now we can begin exploring the territory. 

Coming Next Article 3: First Steps with AROS – Understanding Wanderer 

In the next article, we will move from theory to everyday use. 

We will explore Wanderer, including: 
the desktop
icons
volumes
drawers
files
menus
launching programs
system directories
accessing the Shell

This will also give us our first practical Workbench vs. Wanderer comparison before we later move deeper into the AROS Shell and the internal architecture of the operating system.