Contents

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 below 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. We can use patented algorithms in Europe since European law doesn't allow patents on algorithms. However, code that uses such 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 that 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, besides good intentions on both sides.

1. If it was really important, it probably would be in the original OS. ;-)
2. 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 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, and there have been a couple of innovations implemented in AROS that aren't available in AmigaOS.

Very compatible, it let's you run AROS (on your classic amiga hardware if you like) and let's you run both aros and most classic amiga programs, games, and demos, as long as they are compatible, see compatibility list here.

binaries: We expect that AROS will run existing software on the 68k family Amiga hardware without problems. On other hardware, the existing software can be run through integrated Amiga emulation ("emumiga" or "Janus-UAE"), or the code must be recompiled (see below).

sourcecode: Porting programs from AmigaOS to AROS is currently mostly a matter of a 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. We will 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. See Aros/Developer/Porting_software for more on porting software to AROS.

Well, to be honest this is a misconception. The base development is aimed at implementing the apis used in "atleast" AmigaOS v3.1. However along the way it has been necessary to revise the plans somewhat where amigaos3.1 didnt support the necessary functionality. The end result is a feature set somewhere in between OS3.1 and 3.9 however 3.1 is still used as the _base_ of our goals.

There are other developments which do not fit into this framework since they don't involve either OS's apis - such as hidds and the relevant technologies to implement and support them.

To this end developers are pretty free to improve on the underlying AmigaOS technologies so long as they can still support existing AmigaOS functionality and APIS with very little to no effort.

Currently AROS is available in a quite usable state as native and hosted (under Windows, Linux, FreeBSD and NetBSD) for the i386 architecture (i.e. IBM PC AT compatible clones) and hosted (Linux and NetBSD) for the m68k architecture (e.g. the Amiga, Atari and Macintosh) and hosted on top of ARM Linux distributions. There are ports under way at varying degrees of completeness to SUN SPARC (hosted under Solaris) and Palm compatible handhelds (native).

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 good 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 code.

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 Technologies did?

The fact is that there is quite little 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 labeled "AROS". :-)

Please post a message with details (for example, the error messages you get) on the AROS User mailing list or become a developer and subscribe to the AROS Developer list and post it there, and someone will try to help you.

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 a report.

UAE is an Amiga emulator, and as such has somewhat different goals than 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 Amiga emulation.

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 box.

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.

To make old Amiga programs run on AROS, we have ported UAE to AROS. AROS' 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.

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. Zune is also a handheld MP3-player / multimedia hardware product from Microsoft, but is in no way related to AROS' Zune.