Drivers explained

In AROS OS, drivers are integrated through the Amiga-like system structure, especially through drawers such as DEVS:, Libs:, Classes:, and sometimes Storage:. AROS does not usually use one single “driver manager” like Windows. Instead, drivers are stored as files in specific system locations and are loaded automatically during boot or when a device is mounted. 

Basic idea of drivers 

in AROS A driver is a piece of software that allows AROS to communicate with hardware or a virtual device. Drivers may be responsible for things such as:
hard disks and partitions
CD/DVD drives
USB devices
graphics output
sound cards
network adapters
printers
file systems
input devices such as mouse and keyboard

The basic idea is: 
Application or system component↓
AROS device/library/class↓
Driver↓
Hardware or virtual hardware 

For example, a program does not normally access a disk controller directly. It asks the operating system, and the operating system uses the correct driver to talk to the device. 

What does DEVS: mean? 

DEVS: is an important AROS assign. It points to the system drawer that contains device-related files. 

Usually it corresponds to something like: SYS:Devs But users and programs normally refer to it as: DEVS: This is because Amiga-like systems use assigns: logical names that point to real paths. A beginner can think of DEVS: as: the drawer where AROS keeps many device drivers and device descriptions. 

Typical contents of DEVS: 

Depending on the AROS distribution, DEVS: may contain items such as: 
device drivers
monitor/display drivers
DOS drivers
printer drivers
mount files
file system components
keymaps
datatypes-related device files
storage-related configuration

Typical subdrawers may include names like: 
DEVS:DOSDrivers
DEVS:Monitors
DEVS:Keymaps
DEVS:Printers
DEVS:Networks
DEVS:Storage 

The exact structure depends on the AROS version and distribution. 

What is Storage:? 

Some Amiga-like systems use a Storage: drawer for drivers or mount files that are available but not active automatically. 

A simple distinction is: LocationMeaning 
DEVS: Active device files used by the system Storage: Optional device files stored for later use For example, a DOS driver file may be kept in Storage:DOSDrivers if it should not be mounted automatically at boot. If the user wants it to become active automatically, it may be copied to DEVS:DOSDrivers. In simple words: DEVS: = active or system-used device setup
Storage: = optional or inactive device setup

What is a MountList? 

A MountList is a configuration file that describes how a device or volume should be mounted. 

It tells the system things such as: which device driver to use
which unit number to access
which file system to use
block size
buffers
volume name
startup options
whether the device is removable
other low-level disk or device settings

A MountList is especially important for disk-like devices and volumes. 

A simplified beginner example could look conceptually like this: 
Device = ata.device
Unit = 0
FileSystem = FastFileSystem
Volume = Work 

This is not meant as a complete working MountList. It only shows the kind of information such a file may contain. 

MountList versus DOSDriver 

On Amiga-like systems, the older term MountList often refers to one larger configuration file containing mount entries. A DOSDriver is often a more modern or more convenient form where each mountable device has its own file. 

For beginners: 
MountList A list of mount definitions 
DOSDriver A single mount definition stored as a separate file 
Mount The command/process that activates such a definition 

So instead of having one big MountList, the system may use individual files in: 
DEVS:DOSDrivers or: Storage:DOSDrivers 

How devices are mounted 

When AROS mounts a device, it reads the mount information and loads the needed driver. 

The process is roughly: 
Mount command or boot process↓
Reads DOSDriver or MountList entry↓
Finds the device driver↓
Loads file system if needed↓
Creates a volume or device name↓
The device becomes usable 

After that, the device may appear as a volume such as: 
Work:
CD0:
USB0: 

depending on the setup. 

Automatic mounting at boot 

Some drivers or devices become active automatically during boot. This can happen if their configuration files are placed in active system locations such as: 

DEVS:DOSDrivers 

During startup, AROS may scan this drawer and mount the devices listed there. 

If a file is stored instead in: 

Storage:DOSDrivers 

it may be available but not mounted automatically. This is useful because not every possible device should always be active. 9. Drivers, libraries, and classes Not every driver is stored only in DEVS:. AROS uses several system drawers. DEVS: Used for device drivers and device configuration. 

Typical examples: 
disk devices
monitor/display definitions
printer device files
DOS drivers
keymaps

Libs: 

Used for shared libraries. A library provides functions that programs or drivers can use. Example idea: LIBS:some.library If a program says a library is missing, it often means a required file is missing from Libs:. 

Classes: 

Used for class-based components, often related to BOOPSI, GUI objects, datatypes, or system components. Some applications need specific classes to display windows, buttons, images, or other objects. C: Used for command-line tools. Some driver packages include commands that must be copied to: C: Prefs: Used for preference programs. Some drivers include a configuration tool that belongs in: Prefs: 

How new drivers are installed 

The exact installation method depends on the driver package. 

There is no single universal method, but the usual process is: 
Read the driver’s documentation.
Copy the driver file to the correct drawer.
Copy related libraries, classes, or commands if needed.
Copy the DOSDriver or mount file if the device must be mounted.
Configure ToolTypes or preference settings if required.
Reboot or manually mount/load the device.
Test whether the device works.

Typical manual installation example 

A simple driver package may contain files like this: 
mydevice.device
MyDevicemydevice.library
mytool 

These might be copied like this: 
mydevice.device    → DEVS:
MyDevice           → DEVS:DOSDrivers
mydevice.library   → LIBS:
mytool             → C: 

After copying, the user may need to mount the DOS driver: Mount MyDevice Or reboot, if the file was placed in DEVS:DOSDrivers.

Installing a DOSDriver 

If a driver package includes a DOSDriver file, it is important where the file is placed. 

To make it available but not auto-start: 
Storage:DOSDrivers To make it mount automatically at boot: DEVS:DOSDrivers 
Some users first test a driver from Storage:DOSDrivers. 

If it works, they move or copy it to DEVS:DOSDrivers. This is safer because a bad mount file in DEVS:DOSDrivers may cause boot problems. 

Installing a monitor or graphics driver 

Graphics or monitor drivers may use: 
DEVS:Monitors 

A monitor file may define or enable certain screen modes. After installing it, the user may need to open: Prefs:ScreenMode Then they can select a new screen mode if the driver works. If the selected screen mode fails, the system may become unreadable, so beginners should test carefully. 

Installing a network driver 

Network drivers may require: 
a device driver
a network stack configuration
IP settings
DHCP setup
sometimes additional tools

The files may go into places such as: DEVS:DEVS:NetworksLibs:Prefs: The exact method depends strongly on the AROS distribution and the network stack used. In a VM, it is often easier to choose a virtual network card known to work with the AROS distribution.

Installing a printer driver 

Printer drivers may involve: 
DEVS:PrintersPrefs: 

After copying the driver, the user may need to open printer preferences and select: 
printer type
output port
paper size
print quality

In a VM, printing through the host system is often easier than direct printer driver setup in AROS. 16. Installing file system drivers A file system driver allows AROS to read or write a specific disk format. It may be placed in a location such as: L: or another system-specific location depending on the AROS setup. A DOSDriver or MountList entry may then refer to that file system. The relationship is: DOSDriver / MountList↓uses a device↓uses a file system↓mounts the volume 

Safe beginner workflow for new drivers 

A safe workflow is: 
Make a backup or VM snapshot first.
Read the included documentation.
Copy optional mount files first to Storage:DOSDrivers.
Test manually with Mount.
If the device works, copy the mount file to DEVS:DOSDrivers.
Reboot and check whether the system still starts correctly.
Keep notes about which files were copied where.

This is especially important for beginners because wrong drivers or wrong mount entries can prevent normal startup. 

Common problems after installing drivers 

Device does not appear Possible causes: 
wrong driver version
driver copied to the wrong drawer
missing library
missing class
wrong unit number
wrong DOSDriver or MountList settings

System hangs or slows during boot Possible causes: 
bad entry in DEVS:DOSDrivers
driver tries to access hardware that is not present
incompatible driver
wrong controller or unit number

Program says a library is missing Possible causes: 
required file not copied to Libs:
wrong version of the library
library name is case-sensitive or expected exactly
Screen mode disappears or becomes unusable Possible causes: wrong monitor driver
unsupported graphics mode
incompatible display setup

Important beginner warning 

Beginners should be careful when copying files directly into system drawers such as: 
DEVS:
Libs:
Classes:
C:
S: 

A wrong file in the wrong place can cause confusing errors. In a VM, it is best to create a snapshot before experimenting with drivers. 

Short summary 

Drivers in AROS are integrated through Amiga-like system drawers and assigns. DEVS: is the main place for device drivers and device-related configuration. A MountList or DOSDriver tells AROS how to mount a device or volume. Files in DEVS:DOSDrivers are usually active or mounted automatically, while files in Storage:DOSDrivers are often kept available but inactive. New drivers are usually installed by copying driver files, libraries, classes, commands, and mount files into the correct drawers, then testing them manually or after reboot.