Article 8: Inside the Amiga System Disk – C:, DEVS:, L:, LIBS:, S: and More 

When you first look at an AmigaOS system disk, its directory structure can seem rather unusual. Instead of directories with names such as Windows, Program Files or /usr, you encounter short names like:
C:
DEVS:
L:
LIBS:
S:
T:
ENV:
ENVARC:
FONTS:

 The colon makes these names look like disk drives. But in many cases they are not drives at all. They are part of one of AmigaOS's most useful concepts: assigns. In this article, we will explore the most important AmigaOS system directories, understand what they contain, and see how they work together to create the operating-system environment. 

1. The Logical Structure of AmigaOS 

Suppose your Amiga boots from a hard disk partition called:
System: 

Its physical directory structure might look something like this:
System:
  C/
  Devs/
  L/
  Libs/
  S/
  Fonts/
  Prefs/
  Tools/
  Utilities/ 

But AmigaOS does not require applications to know that these directories are physically located on System:. 

Instead, it creates logical names such as:
C:
DEVS:
L:
LIBS:
S:
FONTS:

For example:
C:       → System:C/
DEVS:    → System:Devs/
LIBS:    → System:Libs/
S:       → System:S/
FONTS:   → System:Fonts/ 

The exact locations can vary. That is the important point. An application can look for something in:LIBS: without necessarily having to know where LIBS: physically exists. 

2. SYS: –  The System Volume 

One of the most important names is:
SYS: SYS: represents the system volume from which the operating system was booted. 

For example, your physical partition might be named:
Workbench: or: System: 

But applications can use:
SYS: to refer to the current system volume. Therefore:
SYS:C/
SYS:Devs/
SYS:Libs/
SYS:S/

refer to directories belonging to the current system environment. This is useful because software does not have to assume that the user has called the system partition Workbench:. 

One user might have:
Workbench: while another uses:
System: and yet software can still use: SYS:
  
3. C: – AmigaDOS Commands 

The C: directory contains executable commands used by AmigaDOS and the Shell. 

Typical commands include:
Copy
Delete
Dir
List
Assign
Execute
Mount
Rename
MakeDir
Protect
Set
Echo 

When you enter a command such as: "Copy test.txt RAM:" the Shell can locate the Copy command through the command search mechanism, commonly using C: as an important command location. 

You can also run the command explicitly: C:Copy test.txt RAM: 

So a useful beginner's description is: C: is the home of many AmigaDOS command programs. This also demonstrates an interesting AmigaOS philosophy. Many Shell commands are not built permanently into one giant command interpreter. They are individual executable programs.

4. LIBS: – Shared Libraries 

We encountered LIBS: in Article 7. It contains libraries that can be loaded from disk. Examples on an AmigaOS installation may include libraries providing functionality for applications and operating-system components. 

The basic relationship is:

Application
     |
     v
OpenLibrary()
     |
     v
LIBS:
     |
     v
requested library

Not every library necessarily resides in LIBS:. Some fundamental libraries are provided by Kickstart or may already be resident in memory. Nevertheless, LIBS: provides the standard logical location for many disk-based libraries. 

A useful mental model is: LIBS: contains shared functionality used by programs. 

5. DEVS: – Devices and System Configuration 

DEVS: is another central part of the AmigaOS installation. Its name is derived from devices. Depending on the operating-system version and installation, it can contain device drivers as well as configuration data and related system components. 

Typical items and subdirectories may include things related to:
DOSDrivers
Monitors
Printers
Keymaps
Datatypes 

The exact organization varies between AmigaOS versions. One particularly important directory is: DEVS:DOSDrivers/ 

6. DEVS:DOSDrivers – Mounting DOS Devices 

AmigaDOS can support additional filesystems and other DOS-accessible resources. The DOSDrivers directory provides a convenient way to configure resources that should be mounted. For example, an installed filesystem or storage device may have an appropriate DOSDriver entry. At startup, the system can process these entries and make the corresponding DOS devices available. 

Conceptually:

DEVS:DOSDrivers/
       |
       v
configuration
       |
       v
Mount
       |
       v
DOS device becomes available 

This helps explain why devices can appear dynamically while the Amiga is running. 

7. DEVS:Monitors – Display Drivers 

On later AmigaOS configurations you will commonly encounter: DEVS:Monitors/

This directory contains monitor-driver related files used to make display modes available to the system. 

Examples may relate to:
PAL
NTSC
Productivity
VGA-style modes
graphics hardware

This demonstrates that the Amiga's display environment is not limited simply to one fixed resolution. Screen modes can be made available through the operating-system display architecture. Workbench and applications can then select suitable modes. 

8. DEVS:Keymaps 

Another familiar location is: DEVS:Keymaps/ 

This contains keyboard mapping information. The purpose becomes obvious when you consider that users may have different keyboard layouts:
American
German
British
French
Italian 

The physical keyboard generates key codes, but the operating system must determine how those codes should be interpreted for a particular national keyboard layout. Keymaps provide this abstraction. 

9. DEVS:Printers 

Classic AmigaOS also provides printer-driver support. Printer-related drivers and configurations can be stored beneath: DEVS:Printers/ 

This again follows the modular Amiga philosophy. Applications should not all need to contain code for every possible printer. Instead, printer support can be provided through the operating system. 

10. L: – Handlers and Filesystem Components 

If LIBS: contains libraries and DEVS: contains device-related components, what is L:? L: traditionally contains handlers and related AmigaDOS components. Filesystem-related components are an important example. In Article 7 we learned that handlers can provide DOS-style interfaces to resources. 

The relationship can be simplified to:

Application
     |
     v
AmigaDOS
     |
     v
Handler
     |
     v
Resource 

This makes L: fundamentally different from LIBS:. A useful distinction is: LIBS:    shared program functions

L:       handlers and DOS-related modules 

Although both contain executable system components, they have very different roles. 11. S: – Scripts and Startup Files S: is another extremely important directory. It contains scripts used by AmigaDOS. 

Most famously: S:Startup-Sequence As discussed in Article  6, the Startup-Sequence is executed during the normal boot process. Another historically important startup-related file is: S:User-Startup Depending on the particular AmigaOS installation, this can contain commands added by software packages or users. The distinction is useful because it can keep custom startup configuration separate from the core system startup script. S: can also contain other command scripts. 

A useful mental model is: S: contains scripts that AmigaDOS can execute. 

12. FONTS: – System Fonts 

The purpose of: FONTS: is relatively straightforward. It provides access to fonts used by the operating system and applications. Again, the logical name is important. 

An application can refer to: FONTS: rather than having to know the physical disk and directory containing the fonts. This also means that the underlying storage arrangement can potentially be changed without requiring every application to be modified. 

13. T: – Temporary Files 

T: is intended for temporary files. Programs sometimes need somewhere to store information that is required only temporarily. Rather than placing such data permanently on the system disk, AmigaOS provides: T: On many configurations, T: points to a location in RAM. 

Conceptually:

Program
   |
   v
temporary data
   |
   v
T:
   |
   v
RAM 

Because the contents are temporary, losing them when the machine is switched off normally does not matter. 

14. RAM: – The RAM Disk 

One of the most famous Amiga devices is: RAM: 

RAM: behaves like a disk but stores its contents in memory. You can use normal AmigaDOS operations with it. 

For example: Copy test.txt RAM: Then: Dir RAM: and: Delete RAM:test.txt 

From the user's perspective, this looks very much like working with a disk. But the data exists in memory. This makes RAM: very fast. The obvious disadvantage is that its contents disappear when the Amiga is switched off or restarted. RAM: also consumes memory as files are stored in it. This was particularly significant on classic Amigas where available RAM could be very limited. 

15. ENV: – The Active Environment 

ENV: contains environment settings used by the currently running system. A typical configuration places ENV: in RAM. This means that programs can quickly access current settings. For example, preferences and other system components may store information in the environment. 

But this creates a problem: ENV: is temporary. If it resides in RAM, its contents disappear when the computer is switched off. 

This is why AmigaOS also uses: ENVARC: 

16. ENVARC: – Persistent Environment Settings 

ENVARC: provides persistent storage for environment settings. 

Typically the relationship is:

ENVARC:
   |
   | during startup
   v
ENV:

 Imagine that you change a preference. The active setting can be placed in: ENV: 

But if you want the setting to survive a reboot, the corresponding information must also be stored persistently, commonly through:
ENVARC:

This creates two related environments:

ENV: current configuration
ENVARC: saved configuration 

This idea is particularly useful when trying to understand Amiga preference programs. 

17. Prefs – Configuration Programs 

The system volume normally also contains: Prefs/ 

Unlike C: or LIBS:, this is generally a directory rather than an assign that applications universally depend upon. It contains graphical preference editors. 

Depending on the AmigaOS version, these can include settings for things such as: 
screen modes
input
fonts
locale
printers
Workbench
sound

This provides a graphical way to configure many operating-system settings. Behind the graphical interface, preferences ultimately have to be represented as configuration information usable by the system. The ENV:/ENVARC: mechanism is important here. 

18. Tools and Utilities 

A normal Workbench installation also contains directories such as:
Tools/
Utilities/ These contain useful applications rather than fundamental parts of the low-level operating-system architecture. The exact programs depend on the version of AmigaOS. Conceptually we can distinguish:
C: system and Shell commands
LIBS: shared libraries
DEVS: device-related system components
L: handlers and DOS components
S: scripts
Prefs: configuration programs
Tools: system tools
Utilities: general utilities 

This makes the Amiga system disk much easier to understand. 19. Assigns – The Secret Behind the Colons Now we arrive at the mechanism connecting many of these names. 

Consider:
C:
LIBS:
DEVS:
S:
FONTS: 

These names do not necessarily represent physical disks. They can be assigns.  An assign associates a logical AmigaDOS name with a path.

Conceptually:
Assign LIBS: SYS:Libs Afterwards:
LIBS: refers to: SYS:Libs/ 

This gives AmigaOS a flexible logical filesystem structure. 

20. Why Assigns Are So Powerful 

Suppose an application expects to find data in:
MYPROG: The user might create:
Assign MYPROG: Work:Applications/MyProgram The application can now use:
MYPROG:Data/
MYPROG:Config/
MYPROG:Images/ without knowing that the program is actually installed in:
Work:Applications/MyProgram/ If the program is moved somewhere else, the assign can be changed. The application itself does not necessarily need to be modified. This is an elegant form of abstraction. 

21. Volumes, Devices and Assigns 

This leads to an important distinction for beginners. 

Consider:
DH0:
Workbench:
SYS:
LIBS: They may all appear similar because they use a colon. But they do not necessarily represent the same kind of thing. Conceptually:
DH0:
DOS device
Workbench: volume name
SYS: system-related logical name
LIBS: assign At the Shell level they can often be used in very similar ways. For example:
Dir DH0:
Dir Workbench:
Dir SYS:
Dir LIBS: 

This common syntax hides considerable complexity underneath. And that is exactly the point. AmigaDOS gives the user and applications a relatively consistent naming system for very different resources. 

22. Paths on AmigaOS 

Amiga paths therefore look different from those on many modern operating systems. 

For example:
SYS:Prefs/ means the Prefs directory on the system volume. Similarly:
DEVS:Monitors/ means the Monitors directory within whatever location DEVS: currently represents. A file might be addressed as:
S:Startup-Sequence or:
LIBS:example.library or:
RAM:test.txt The colon separates the DOS name from the remaining pathname. This naming system is central to AmigaDOS. 23. How Everything Works Together Let us imagine that an application starts from Workbench. 

The program might:
1. Load an icon using icon.library
2. Open intuition.library to create a window
3. Open graphics.library for graphics operations
4. Read configuration information from ENV:
5. Load a font from FONTS:
6. Read additional files from its program directory
7. Create temporary information in T: 

The program is using several operating-system services, but it does not necessarily know where all these resources physically reside. AmigaOS provides the abstraction. That is a recurring theme throughout the architecture. 

24. A Practical Mental Map 

For everyday use, this compact map is useful:
SYS: The current system environment 
C: Commands
DEVS: Devices and related configuration
L: Handlers and DOS components
LIBS: Shared libraries
S: Scripts and startup files
FONTS: Fonts
T: Temporary files
ENV: Current environment settings
ENVARC: Persistent environment settings
RAM: RAM-based filesystem
Prefs/ Preference editors
Tools/ System tools
Utilities/ Utility programs 

Once you remember this map, examining an AmigaOS installation becomes much less mysterious. 

25. Why the Amiga Does It This Way 

At first glance, this system can appear more complicated than a simple fixed directory structure. But it provides considerable flexibility.

Applications can ask for:
LIBS: instead of assuming:
DH0:Libs/ Commands can be found through:
C: Fonts can be accessed through:
FONTS: temporary data can go to:
T: and configuration can be accessed through:
ENV: The physical organization is separated from the logical organization. That makes the operating-system environment much more flexible than the short directory names initially suggest. 

Conclusion The AmigaOS system disk is not merely a collection of directories. It forms a logical operating-system environment. The most important idea is not simply remembering what each directory contains. 

It is understanding why AmigaOS uses logical names such as:
C:
DEVS:
LIBS:
S:
FONTS:
ENV: 

Applications can work with these names without needing to know exactly where the corresponding resources are physically stored. Together with libraries, devices and handlers, this creates the highly modular architecture we explored in Article 7. We can now see another important principle behind AmigaOS: The physical location of a resource and the logical name used to access it do not have to be the same thing. This principle appears throughout AmigaDOS and becomes especially powerful when working from the Amiga Shell. Next: Article 9 – The Amiga Shell and AmigaDOS In the next article, the natural next step is to explore the Amiga Shell itself: how commands are executed, how paths and assigns are used in practice, command templates, redirection, pipes, wildcards and scripts.