Of course you can. Please go to the AROS-Exec forum and
read the threads and ask everything you want. This FAQ will
be updated with the users' questions, but the forum will be
European law says that it is legal to apply reverse engineering techniques to
gain interoperability. It also says that it is illegal to distribute the
knowledge gained by such techniques. It basically means that you are allowed
to disassemble or resource any software to write something which is compatible
(for example, it would be legal to disassemble Word to write a program which
converts Word documents into ASCII text).
There are of course limitations: you are not allowed to disassemble the
software if the information you would gain by this process can be obtained by
other means. You must also not tell others what you learned. A book like
"Windows inside" is therefore illegal or at least of dubious legality.
Since we avoid disassembling techniques and instead use common available
knowledge (which includes programming manuals) which don't fall under any NDA,
the above doesn't apply directly to AROS. What counts here is the intention of
the law: it is legal to write software which is compatible with some other
software. Therefore we believe that AROS is protected by the law.
Patents and header files are a different issue, though. European law doesn't
allow patents on algorithms, hence algorithms patented elsewhere could be used
freely in Europe. However, code that uses algorithms that are patented in the
USA could not be imported to the USA. Examples of patented algorithms in
AmigaOS include screen dragging and the specific way menus work. Therefore we
avoid implementing these features in exactly the same way. Header files on the
other hand must be compatible but as different as possible from the original.
To avoid any trouble we applied for an official OK from Amiga Inc. They are
quite positive about the effort but they are very uneasy about the legal
implications. We suggest that you take the fact that Amiga Inc did not send us
any cease and desist letters as a positive sign. Unfortunately, no legally
sound agreement has been made yet; both sides just expressed good intentions.
There have been discussions about writing an advanced OS with the features of
the AmigaOS. This has been dropped for a good reason. First, everyone agreed
that the current AmigaOS would have to be enhanced, but no one knew how to do
that or even agreed on what had to be enhanced or what was important. For
example, some wanted memory protection, but they disliked its cost (a major
rewrite of the available software and speed decrease).
In the end, the discussions ended in either flame wars or reiteration of the
arguments. So we decided to start with something we knew how to handle. Then,
when we have the experience to see what is possible or not, we could decide
We also want to be binary compatible with the original AmigaOS on Amiga. The
reason for this is just that a new OS without any programs to run on it has
little chance to survive. Therefore we try to make the shift from the original
OS to our new one as painless as possible (but not to the extent that we can't
improve AROS afterwards). As usual, everything has its price and we try to
decide carefully what that price might be and if we and everyone else would be
willing to pay it.
- If it was really important, it would be in the original OS. :-)
- Why don't you do it yourself and send a patch to us?
The reason for this attitude is that there are plenty of people around who
think that their feature is the most important and that AROS has no future if
that feature is not built in right away. Our position is that AmigaOS, which
AROS aims to implement, can do everything a modern OS should do. We see that
there are areas where AmigaOS could be enhanced, but if we do that, who would
write the rest of the OS? In the end, we would have lots of nice improvements
to the original AmigaOS which would break most of the available software but
be worth nothing, because the rest of the OS would be missing.
Therefore, we decided to block every attempt to implement major new features
in the OS until it is more or less completed. We are getting quite close to
that goal now, though, so there have indeed been a couple of innovations
implemented in AROS that aren't available in AmigaOS.
Very compatible. We expect that AROS will run existing software on the Amiga
without problems. On other hardware, the existing software must be recompiled.
We hope to offer a preprocessor which you can use on your code which will
change any code that might break with AROS and/or warn you about such code.
Porting programs from AmigaOS to AROS is currently mostly a matter of a simple
recompilation, with the occasional tweak here and there. There are of course
programs for which this is not true, but it holds for most modern ones.
Currently AROS is available in a quite usable state as native and hosted
(under Linux, and FreeBSD) for the i386 architecture (i.e. IBM PC AT
compatible clones). There are ports under way at varying degrees of
completeness to SUN SPARC (hosted under Solaris) and Palm compatible
There is currently an effort under way to port AROS to PowerPC, initially
hosted under Linux.
We use Linux and X11 to speed up development. For example, if you implement
a new function to open a window you can simply write that single function and
don't have to write hundreds of other functions in layers.library,
graphics.library, a slew of device drivers and the rest that that function
might need to use.
The goal for AROS is of course to be independent of Linux and X11 (but it
would still be able to run on them if people really wanted to), and that is
slowly becoming a reality with the native versions of AROS. We still need to
use Linux for development though, since some development tools haven't been
ported to AROS yet.
One of the major new features in AROS compared to AmigaOS is the HIDD
(Hardware Independent Device Drivers) system, which will allow us to port AROS
to different hardware quite easily. Basically, the core OS libraries do not
hit the hardware directly but instead go through the HIDDs, which are coded
using an object oriented system that makes it easy to replace HIDDs and reuse
We hear all the day from a lot of people that AROS won't make it. Most of them
either don't know what we are doing or they think the Amiga is already dead.
After we explained what we do to the former, most agree that it is possible.
The latter make more problems. Well, is Amiga dead right now? Those who are
still using their Amigas will probably tell you that it isn't. Did your A500
or A4000 blow up when Commodore went bankrupt? Did it blow up when Amiga
The fact is that there is not much new software developed for the Amiga
(although Aminet still chugs along quite nicely) and that hardware is also
developed at a lower speed (but the most amazing gadgets seem appear right
now). The Amiga community (which is still alive) seems to be sitting and
waiting. And if someone releases a product which is a bit like the Amiga back
in 1984, then that machine will boom again. And who knows, maybe you will get
a CD along with the machine labelled "AROS". :-)
Please post a message with details (for example, the error messages you
get) on the Help forum at AROS-Exec or become a developer and
subscribe to the AROS Developer list and post it there, and someone will
try to help you.
Several hundred Amiga experts (and people who considered themselves such)
tried for three years to find a way to implement memory protection (MP) for
AmigaOS. They did not meet with success. This indicates that it's quite
unlikely that the normal AmigaOS will never have MP like Unix or Windows NT.
But all is not lost. There are plans to integrate a variant of MP into AROS
which will allows protection of at least new programs which know about it.
Some efforts in this area look really promising. Also, it's not really a
problem if your machine crashes. Rather, the problem might be that:
- You have no good idea why it crashed. Basically, you end up having to poke
with a 100ft pole into a swamp with a thick fog.
- You lose your work.
Rebooting the machine is really no issue.
What we could try to construct is a system which will at least alert if
something dubious is happening and which can tell you in great detail what was
happening when the machine crashed and which will allow you to save your work
and then crash. It should also need a means to check what has been saved so
you can be sure that you don't continue with corrupted data.
The same thing goes for SVM (swappable virtual memory), RT (resource tracking)
and SMP (symmetric multiprocessing). We are currently planning how to
implement them, making sure that adding these features will be painless.
However, they do not have the highest priority right now. Very basic RT has
been added, though.
Sure, no problem. In fact, we want as many beta testers as possible, so
everyone is welcome! We don't keep a list of beta testers though, so all
you have to do is to download AROS, test whatever you want and send us
UAE is an Amiga emulator, and as such its goal is somewhat different from that
of AROS. UAE wants to be binary compatible even for games and hardware hitting
code, while AROS wants to have native applications. Therefore AROS is much
faster than UAE, but you can run more software under UAE.
We are in loose contact with the author of UAE and there is a good chance that
code for UAE will appear in AROS and vice versa. For example, the UAE
developers are interested in the source for the OS because UAE could run some
applications much faster if some or all OS functions could be replaced with
native code. On the other hand, AROS could benefit from having an integrated
Since most programs won't be available on AROS from the start, Fabio Alemagna
has ported UAE to AROS so you can run old programs at least in an emulation
Also available in Contrib is E-UAE, which is UAE improved by some features
Haage & Partner used parts of AROS in AmigaOS 3.5 and 3.9, for example the
Colorwheel and Gradientslider gadgets and the SetENV command. This means that
in a way, AROS has become part of the official AmigaOS. This does not imply
that there is any formal relation between AROS and Haage & Partner. AROS is an
open source project, and anyone can use our code in their own projects
provided they follow the license.
The relationship between AROS and MorphOS is basically the same as between
AROS and Haage & Partner. MorphOS uses parts of AROS to speed up their
development effort; under the terms of our license. As with Haage & Partner,
this is good for both the teams, since the MorphOS team gets a boost to their
development from AROS and AROS gets good improvements to our source code from
the MorphOS team. There is no formal relation between AROS and MorphOS; this
is simply how open source development works.
Most development for AROS is done using ANSI C by cross-compiling the
sources under a different OS, e.g. Linux or FreeBSD. Fabio Alemagna has
completed an initial port of GCC to i386 native. However, it is not
currently on the ISO or integrated into the build system.
The languages that are available natively are Python, Regina, Lua,
Hollywood and False:
- Python is a scripting language which has become quite popular, because of
its nice design and features (object-oriented programming, module system,
many useful modules included, clean syntax, ...). A separate project has
been started for the AROS port and can be found at
- Regina is a portable ANSI-compliant REXX interpreter. The goal for the AROS
port is to be compatible with the ARexx interpreter for the classic
- Lua is a powerful, fast, light-weight, embeddable scripting language. The
AROS port has been extended by two modules: siamiga and zulu. The first one
has some simple graphics commands, the latter is an interface to Zune.
- Hollywood is a commercial programming language for multimedia applications
including games. The CD-ROM contains a version for i386-aros.
- False can be classified as an exotic language, so it will most likely not
be used for serious development, although it can be lots of fun. :-)
To make old Amiga programs run on AROS, we have ported UAE to AROS. AROS's
version of UAE will probably be a bit faster than other versions UAE since
AROS needs less resources than other operating systems (which means UAE will
get more CPU time), and we'll try to patch the Kickstart ROM in UAE to call
AROS functions which will give another small improvement. Of course, this only
applies to the native flavors of AROS and not the hosted flavors.
But why don't we simply implement a virtual m68k CPU to run software directly
on AROS? Well, the problem here is that m68k software expects the data to be
in big-endian format while AROS also runs on little-endian CPUs. The problem
here is that the little-endian routines in the AROS core would have to work
with the big-endian data in the emulation. Automatic conversion seems to be
impossible (just an example: there is a field in a structure in the AmigaOS
which sometimes contains one ULONG and sometimes two WORDs) because we cannot
tell how a couple of bytes in RAM are encoded.
There might be, if someone creates a native Amiga port of AROS and does all
the other work needed to create a Kickstart ROM. Currently, no one has applied
for the job.
In case you read on this site about Zune, it's simply an open-source
reimplementation of MUI, which is a powerful (as in user- and
developer-friendly) object-oriented shareware GUI toolkit and de-facto
standard on AmigaOS. Zune is the preferred GUI toolkit to develop
native AROS applications. As for the name itself, it means nothing,
but sounds good.
This memory division is mostly a relic from Amiga past, when graphical memory
was application memory before you added some other, called FAST RAM, a memory
where applications were located, while the graphics, sounds and some system
structures were still in graphic memory.
In AROS-hosted, there isn't such kind of memory as Other (FAST), but only GFX,
when on Native AROS, GFX can have a maximum of 16MB, although it wouldn't
reflect the state of the graphic adapter memory... It has no relation to the
amount of memory on your graphics card.
The long-winded answer
Graphics memory in i386-native signifies the lower 16MB of memory in the
system. That lower 16MB is the area where ISA cards can do DMA. Allocating
memory with MEMF_DMA or MEMF_CHIP will end up there, the rest in the other
Use C:Avail HUMAN command for memory info.
This command remembers icon placement of all windows (or of a single window).
If you are root and AROS crashes at launch, do "xhost +" before
"sudo && ./aros -m 20". You must also give it some memory with -m option as
shown. The space between "-m" and the value is important. Also don't forget
about BackingStore option in section Device of your xorg.conf.
You can get a list of them by running an ./aros -h command.
Here are some:
floppy=<disabled/nomount> Sets the trackdisk device options
disabled - completely disable trackdisk.device
nomount - initialise trackdisk.device but do not
create DOS devices
ATA=32bit - Enables 32-bit I/O in the hard disk driver (safe)
forcedma - Forces DMA to be active in the hard disk driver
(should be safe, but might not be)
gfx=<hidd name> - Use the named HIDD as the gfx driver
lib=<name> - Load and initiate the named library/HIDD
And some older ones, if you're using older build (from r28786):
nofdc - Disables the floppy driver completely.
noclick - Disables the floppy disk change detection
Please note that the options are case-sensitive.
Q: I`ve compiled AROS with gcc4 but found that compiled AROS-hosted segfaults
with -m > 20 and if I compile AROS-native it does not start (black screen)
A: Add -fno-strict-aliasing to scripts/aros-gcc.in and try to recompile.
- Create a sub-directory S and add a file with name 'Package-Startup' with
the DOS script for that package that you want to run every boot.
- Create a variable in the envarc:sys/packages file which contains the path
to the S sub-directory of your package.
Example directory layout:
The variable in envarc:sys/packages could have the name 'myapp' (the name is
an example); the content would then be 'sys:extras/myappdir'
The Package-Startup script would then be called by the startup-sequence.