| . |
AROS
by Bernardo Innocenti (bernie@cosmos.it) - taken from Amiga Life
Translation by Joachim Thomas (thomas.j@amiworld.it)
Rewriting AmigaOS
 In 1994, with the liquidation of Commodore, Amiga's fate seemed irriversibly decided. The consequent West Chester research centre closure implicated also the complete stop of any development on the most revolutionary Operating System ever. Inside the Amiga community a lot of programmers felt the urge to react in some way to save AmigaOS from such a sad end. Since the AmigaOS sources where kept secret, the only way to do was to roll up one's sleeves and restart from the scrap writing a new AmigaOS..
The first attempts in doing this missed the mark before even really starting. Amiga developers, certainly numerous, always totally lacked in coordination. The mailing list of the first projects, among them one called AOS, where only flooded by vain flame-wars about technical details like memory protection and symmetric multi-processing, without writing one line of code.
Amiga Replacement OS
Almost three years after Coomodore's death, the initial excitement about these poject nearly vanished, like the related flame-wars. Moreover Escom announced a new version of AmigaOS to be released with the new Walker model but, as we all know, Escom bankrupted before the project could be completed.
| In those days a new project showed up, like one of the many AmigaOS rewritings tried by then. In the winter of 1995, Aaron Digulla decided to find a way out from this static situation sending an RFC (Request For Comment) to the AOS mailing list, suggesting to fix definitively the minimal requirements for a new AmigaOS. Inthis way Aaron became the coordinator for a new project immediately supported by many developers.
Unlike its predecessors, Amiga Replacement OS, shortly AROS, started with strong premises. Main target was to achieve the complete implementation of the actual OS3.1, keeping as far as possible binary compatibility with existing applications. Unlike real AmigaOS, AROS was designed with a particular care about portability to other CPUs and harware platforms. For this reason almost all the code has been written in plain C and all harware related modules are separated from remaing code.
In order to simplify debugging in the first development steps, AROS has been written to be executed as any normal program under Linux, allowing developers to make use of a powerful and flexible environment.
|
|
Panel 1 - The AROS numbers
|
The’OS 3.1 libraries contain 1234 functions:
- 274 (20.2%) did not yet have written
- 160 (13.0%) are under construction
- 800 (64.8%) have been completed
There are 56 functions not included in the libraries:
- 14 (25.0%) did not yet have written
- 35 (62.5%) are under construction
- 7 (12.5%) have been completed
|
|
Open Source development
 Most shareware or public domain programs for the Amiga platform are created by single programmers, resulting in obvious limits for the general software complexity.
In the UNIX developers community it's practice to publish immediately program's sources, driving others to correct bugs or improving functionality. Using special tools it's possible to coordinate hundreds of freelance developers in very huge projects.
AROS uses a similar development system. Sources are mantained on a CVS server (Concurrent Version System) in the Internet. CVS keeps track of synchronisation in all developer's modifications and stores logs about authors and purposes of all changes.
Developers can update their source versions logging to the server and upload their own changes for all other developers. Discussions about new features are possible trought the aros-dev mailing-list before starting to work on them.
Every developer is free to offer his contribution in working on a part of the operating system. The job assignment is mantained by a special Job Server that keeps track of the progressions in all single jobs.
|
Table 1 - Job Server state
|
| Module | Fun
ctions | To do | In
progress | Completed | |
DevCMD | 129 | 70.54% | 27.13% | 2.33% | |
HIDG | 28 | 39.29% | 60.71% | 0.00% | |
alib_commodities | 7 | 0.00% | 100.00% | 0.00% | |
alib_stdio | 7 | 0.00% | 100.00% | 0.00% | |
arp | 70 | 52.86% | 2.86% | 44.29% | |
asl | 6 | 16.67% | 83.33% | 0.00% | |
battclock | 3 | 0.00% | 0.00% | 100.00% | |
commodities | 29 | 0.00% | 0.00% | 100.00% | |
console | 2 | 50.00% | 0.00% | 50.00% | |
datatypes | 15 | 0.00% | 0.00% | 100.00% | |
diskfont | 5 | 60.00% | 40.00% | 0.00% | |
dos | 154 | 11.69% | 7.14% | 81.17% | |
exec | 118 | 0.85% | 6.78% | 92.37% | |
expansion | 21 | 38.10% | 4.76% | 57.14% | |
gadtools | 19 | 0.00% | 47.37% | 52.63% | |
graphics | 165 | 18.79% | 9.09% | 72.12% | |
icon | 12 | 0.00% | 0.00% | 100.00% | |
iffparse | 40 | 0.00% | 0.00% | 100.00% | |
input | 1 | 0.00% | 0.00% | 100.00% | |
intuition | 124 | 25.81% | 4.84% | 69.35% | |
keymap | 4 | 0.00% | 25.00% | 75.00% | |
layers | 32 | 0.00% | 21.88% | 78.12% | |
locale | 24 | 0.00% | 8.33% | 91.67% | |
lowlevel | 15 | 73.33% | 26.67% | 0.00% | |
mathffp | 12 | 0.00% | 0.00% | 100.00% | |
mathieeedoubbas | 12 | 0.00% | 25.00% | 75.00% | |
mathieeedoubtrans | 17 | 0.00% | 11.76% | 88.24% | |
mathieeesingbas | 12 | 0.00% | 0.00% | 100.00% | |
mathieeesingtrans | 17 | 0.00% | 0.00% | 100.00% | |
mathtrans | 17 | 0.00% | 0.00% | 100.00% | |
misc | 2 | 0.00% | 0.00% | 100.00% | |
timer | 5 | 20.00% | 0.00% | 80.00% | |
utility | 38 | 0.00% | 0.00% | 100.00% |
|
|
AROS flavours
AROS has a special build system, permitting different distributions from the same sources. Modifying the configuration it's possible to generate AROS for various CPUs and in different flavours. By now there are two main flavours: native, that on m68k CPUs keeps binary compatibility for Amiga applications, and emul, allowing to run AROS on a host operating system.
Actually the most advanced configuration is emulation on UNIX systems, the preferred environment for most AROS developers. Supported UNIX systems are Linux (i386 and m68k) and FreeBSD i386. The 68k Linux version, mantained by Kars de Jong, will be able to run native Amiga applications without recompiling them.
The porting to more UNIX systems requires very little changes, including the fittings to exec routines performing task switching and interrupt handling. All emulated flavours on UNIX can already open windows on XWindow showing intuition screens. This is very similar to what happens using UAE, with the important difference that all the code is really compiled for the host CPU and not just emulated by software.
There is also an ibmpc-native flavour, allowing AROS to run on a standard PC like any other operating system. By now it's only possible to boot from floppy and, due to the work still to be done on graphic-card drivers, it's still not possible to use Intuition. Michael Schultz, main author of this flavour, is now working on lacking drivers.
AROS can be alos compiled on Amiga, obtaining a set of libraries and executables to be used instead of the corresponding versions present in the Kickstart and Workbench ROMs. A tool, called arosboot, loads selected AROS libraries to be used after the next reboot. If all performs well, the computer should restart like before and no difference should be seen in the usual system performance.
|
By now the only modules offering enough binary compatibility with OS3.1 are exec.strap, alert.hook, utility.library, keymap.library and commodities.library. All other libraries are still not usable on native Amiga, because the most developers are using the Linux flavour and are aimed in implementing lacking features of AmigaOS, letting the native environment testing and debugging phase as the last job to do.
 AROS has been created to be easily ported to a variety of different environments and existing flavours are only a start. The only real limit in porting AROS to other sistems in native or emulated modes is given by the short number of developers doing the job. Some months ago on the mailing list there was a discussion about the porting to PowerPC.
Przemyslaw Szczygielski is working on an AROS version that will run in the same way on Linux APUS, Linux PPC and MkLinux. Claus Herrmann is working on a native Amiga PowerPC version. This is not the usual new PPC kernel, like Phase 5's and Haage & Partner's own: AROS will be a completely native PowerPC system on which old 68000 applications will not work without software emulation. An emulated flavour, like under UNIX, could be also done, running AROS for PowerPC on an own screen, with the original AmigaOS still running on 68000.
Under construction
In the mid of last year AROS slowed down to an almost complete stop. The project got to a very difficult point. After rewriting the kernel parts of AmigaOS (exec, dos, expansion and utility), it was no more possible to continue without completing the most difficult part of AmigaOS: Intuition. In AmigaOS' design, Intuition, input.device, Graphics and Layers are very interdependent modules. It's not possible to get a working version of one without the other three. In AROS this was complicated by the need to add an Hardware Abstraction Layer for graphics and input.
At the end of 1998, after endless technical discussions, the project restarted very quickly. A task-force built by Nils Henrik Lorentzen, Stefan Berger, Henning Kiel and Bernhard Fastenrath ported in a few months Intuition, Graphics and Layers to a maturity sufficient to go on with the whole project developing GadTools, Asl and Boopsi.
 Johan Alfredsson, after the completion of commodities.library and datatypes.library, is now working on realtime.library and on the missing parts of console.device, allowing soon to open the shell within a CON: window, as on Amiga. As soon as Michael Schultz completes the needed drivers, it will be possible to create FastFileSystem partitions on PC HardDisks and boot the ibmpc-native version. In the meantime Branko Collins offered his help updating and correcting the documentation for AROS and reworking the website look, more accessible for non-developers starting in september.
While the single modules near completion, it will be possible to port on AROS existing software for Amiga. With the aim to not waste human resources, the AROS team decided, not to start in rewriting system utilities for which are already existent replacements in the public domain. Infatc there are plenty of software that, in the last years, replaced and improved the AmigaOS 3.1 equivalents. Workbench, for instance, could be replaced by Scalos or Directory Opus.
Every real Amiga user installed plenty of these programs together with many
patches improving the system's look and functionality. The latter would be
supefluous in AROS: having the source code of the entire operating system
it would be far easier include this features directly into the system rather
than using patches.
HIDD
Modules that in AmigaOS have direct access to Amiga hardware (graphic.library, gameport.device, keyboard.device, serial.device, etc.) in AROS use hardware independent drivers, called HIDD (Hardware Independent Device Driver). These are, in reality, boopsi classes, making use of the typical inheritance in object oriented systems, aiming to minimize the work implementing new drivers. After an accurate designing phase, this flexibility has been achieved without noticeable performance losses.
 A driver for a new graphic board can be written in a few hours, implementing just the code that initializes the graphic frame buffer and a function allowing to draw single pixels. All other methods of the HIDD driver can be inherited from the generic ''graphic device'' class, which is able to emulate any drawing function calling only the WritePixel method. Obviously, later the driver can be optimized implementing directly other methods, using graphic acceleration. In this way in AROS the graphics.library is reduced to an high level interface accessing the underlying HIDDs.
By now a HIDD is available allowing to use an X11 window as an output device and others getting input from it through the mouse and the keyboard. The IBM-PC flavour has equivalent HIDDs accessing directly PC hardware. Nobody started writing HIDDs for Amiga hardware, but it should be easy.
Visibility Problem
Many of you are surely wondering why such an important project lived in the shadows nearly for three years. The main reason is the doubtfull legal position with Amiga Inc.
It's possible, but not sure, that the distribution of an operating system, functionally the same as AmigaOS, would be an infringement of some patents registered by Commodore, now owned by Gateway 2000. In the eventuality of a legal action by Amiga Inc., the AROS team wouldn't have the economical power to manage his defense.
During the last two years Aaron Digulla and the other developers tried to contact Petro TyschTschenko, Jeff Schindler and Bill McEwen. The personal views of Amiga Inc's staff have always been positive, but by now there hasn't yet been a definitive official answer. Lacking a real legal information about the status of AROS, only the involved developers had access to the sources.
Public Release
 Recently it has been possible to examine the contents of the Commodore Patents filed at the U.S. Patent Office. It seems that some changes must be done to Intuition functions to avoid patent infringements.
After this disclosure, it has been possible to start a discussion about releasing AROS to the public domain. The focal point of the discussion has been the distribution license. Although all developers agreed about a non commercial Open Source License, the discussion was about GPL or BSD Licensing. A lot of alternatives have been proposed, including writing a custom license. The final decision was MPL. MPL is very similar to GPL, but gives the team the possibility to offer the Source code to third party companies in form of other licensing types, allowing companies like Amiga Inc, Phase5 and Haage & Partner to use AROS as a part or as a whole for the development of commercial products, without the need to publish their sources.
Later, Aaron Digulla set a deadline for the first public release of AROS, asking all developers to send him all the work still to be released. The first Aminet upload has been in concomitance with the World Of Amiga. The distribution is divided in 4 archives for sources, documentation, executables for Amiga and executables for Linux.
Conclusions
Although six years passed after Commodore's bankruptcy, in spite of numerous expectations, Amiga and his operating system are still alive and a new version has to be released soon. But the need for a free-software version is still important, allowing OS developments not influenced by economical matters, with many advantages for the end user.
By now AROS is surely the most mature AmigaOS rewriting project, and the day users will directly benefit is very near. The sources uploaded to th CVS server are by now more than 31MB and the 65% of all system functions have already been written. AROS involves nearly 90 developers and, thanks to the sprogressive system's trengthening, work is going on faster and faster.
In the future AROS' succes will depend in large way to Amiga developer's ability to conform their work to an Open Source OS model. Instead of wasting energies working individually at small programs, developers should contribute to the improvement of the whole system. By now there are lot of examples of successful projects to take as a model. It's enough mentioning Linux or FreeBSD to undestand that. also talking about software, union is strength.
Bernardo Innocenti
Riferimenti
|
. |
![[Made On Amiga]](../../images/amiga.gif){kind=small}
