| . |
AROS
von Bernardo Innocenti (bernie@cosmos.it) - entnommen aus Amiga Life
Übersetzung ins Deutsche von Dirk Neubauer (dirk.neubauer@p4all.de)
Das AmigaOS neu entwickeln
 Mit dem Konkurs von Commodore
1994 schien das Schicksal des Amigas endgültig besiegelt. Die konsequente Schließung des
Entwicklungslabors West Chester führte zum kompletten Stopp jedweder Entwicklung am revolutionärsten Betriebssystem allerzeiten.
Viele Programmierer aus der Amiga-Gemeinde fühlten jedoch den Drang, das AmigaOS vor diesem Aus zu bewahren. Da die Quellen des
AmigaOS ein Geheimnis blieben, blieb nur übrig, die Ärmel hochzukrempeln und das AmigaOS von Grund auf neu zu entwickeln..
Die ersten Bemühungen verfehlten ihr Ziel schon, bevor es richtig losging. Amiga Entwicklern, sogar sehr vielen, fehlte immer
die vernünftige Koordination. Die Mailingliste der ersten Projekte, welche unter dem Namen AOS lief, wurde überschwemmt von
fruchtlosen Diskussionen über technische Details, wie Speicherschutz und symmetrischem Multiprocessing, ohne auch nur eine Zeile
Code zu verfassen.
Amiga Replacement OS
Beinahe drei Jahre nach Commodore's Zusammenbruch war der ursprüngliche Antrieb für dieses Projekt fast verschwunden, wie die
erwähnten Diskussionen. Noch dazu kündigte Escom eine neue Version des AmigaOS im Zusammenhang mit dem Walker an, aber wie
allgemein bekannt, ging Escom in Konkurs, ehe das Projekt beendet werden konnte.
| In diesen Tagen entstand ein neues Projekt, wie einer der vielen Versuche einer AmigaOS-Neuentwicklung. Im Winter
1995 wollte Aaron Digulla einen Ausweg aus dieser festgefahrenen Situation suchen und schickte eine Umfrage mit dem Vorschlag an die
AOS-Mailingliste, die minimalen Anforderungen für ein neues AmigaOS neu zu definieren. So wurde Aaron der Koordinator eines
neuen Projektes, welches sofort von vielen Entwicklern unterstützt wurde.
Anders als seine Vorgänger begann das Amiga Replacement OS, kurz AROS, mit strengen Vorgaben. Das Hauptziel war eine komplette
Implementation des existierenden OS3.1 und der Erhalt einer höchstmöglichen Kompatiblität zu aktuellen Anwendungen. Anders als
das echte AmigaOS wurde AROS mit Hinblick auf eine Portierbarkeit auf andere CPUs und Plattformen entwickelt. Darum wurde
beinahe der ganze Code in C verfasst und die hardwarespezifischen Teile wurden vom übrigen Code getrennt.
Um das Debuggen in den ersten Entwicklungsphasen zu vereinfachen, wurde AROS wie ein einfaches Programm unter Linux geschrieben
und bot so den Entwicklern eine leistungsfähige und flexible Entwicklungsumgebung.
|
|
Tafel 1 - Die AROS Zahlen
|
Die’OS 3.1 libraries enthalten 1234 Funktionen:
- 274 (20.2%) wurden noch nicht geschrieben
- 160 (13.0%) sind in Bearbeitung
- 800 (64.8%) wurden fertiggestellt
Es gibt 56 Funktionen, die nicht den libraries entstammen:
- 14 (25.0%) wurden noch nicht geschrieben
- 35 (62.5%) sind in Bearbeitung
- 7 (12.5%) wurden fertiggestellt
|
|
Open Source Entwicklung
 Die meisten Shareware und PD-Programme für die Amigaplattform werden durch einzelne Programmierer entwickelt, was
zu offensichtlichen Einschränkungen in der allgemeinen Softwarekomplexität führt.
In der UNIX-Entwicklergemeinde ist es gang und gäbe, die Programmquellen sofort zu veröffentlichen, um anderen zu ermöglichen,
Fehler zu beheben und die Funktionalität zu verbessern. Mit speziellen Werkzeugen ist die Koordination hunderter freier
Entwickler in sehr großen Projekten möglich.
AROS nutzt ein ähnliches Entwicklungssystem. Die Quellen werden auf einem CVS-Server (Concurrent Version System) im Internet
verwaltet. CVS verwaltet die gleichzeitigen Änderungen der Entwickler und speichert alle Angaben über die Autoren und den Zweck
der Änderungen.
Die Entwickler können ihre Quellversion vom Server aus erneuern und ihre eigenen Änderungen für alle anderen Entwickler
uploaden. Diskussionen über neue Eigenschaften sind in der aros-dev Mailingliste möglich, bevor die Arbeit daran anfängt.
Jeder Entwickler kann seine Mithilfe an einem Teil des Betriebssystems anbieten. Die Arbeitszuweisung wird von einem speziellen Job Server
verwaltet, welcher den Status jedes einzelnen Jobs führt.
|
Tabelle 1 - Job Server Status
|
| Module | Funktionen | Noch
zu tun | In
Bearbeitung | Abgeschlossen | |
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 Modi
AROS besitzt ein spezielles build System, welches es erlaubt, von denselben Quellen verschiedene Ausgaben zu erzeugen.
Durch Veränderungen der Konfiguration ist es möglich, AROS für verschiedene CPUs und in verschiedenen Modi zu generieren.
Derzeit gibt es zwei Hauptmodi: native, das unter m68k CPUs die Kompatiblität zu Amigaanwendungen hält, und emul,
womit man AROS auf einem Hostbetriebssystem betreiben kann.
Die derzeit ausgereifteste Konfiguration ist die Emulation auf UNIX-Systemen, der bevorzugten Umgebung der meisten AROS-Entwickler. Unterstützte
UNIX-Systeme sind Linux (i386 und m68k) und FreeBSD i386. Die 68k Linux Version, verwaltet von Kars de Jong,
kann ursprüngliche Amigaanwendungen ohne Rekompilierung laufen lassen.
Das Portieren auf weitere UNIX-Systeme erfordert sehr wenige Änderungen, darunter die Anpassung der exec Routinen, die das
Taskwechseln und die Interruptbehandlung bewerkstelligen. Alle emulierten Modi unter UNIX können bereits Fenster unter XWindow
öffnen, welche Intuition-Bildschirme zeigen. Dies ist dem unter UAE sehr ähnlich, mit dem entscheidenden Unterschied, das
sämtlicher Code wirklich für die Host-CPU kompiliert wurde und nicht durch Software emuliert wird.
Es gibt auch einen ibmpc-native Modus, welcher AROS auf einem Standard-PC wie jedes andere Betriebssystem laufen lässt.
Zur Zeit ist nur das Booten von Diskette möglich und wenn sie denn fertiggestellt sind mit Grafikkartentreibern. Man kann
derzeit nicht Intuition nutzen. Michael Schultz, der Hauptverantwortliche für diesen Modus, arbeitet derzeit an den fehlenden
Treibern.
AROS kann auch auf einem Amiga betrieben werden, wobei eine Anzahl anderer libraries und executables benutzt wird, statt der
Versionen aus den Kickstart und Workbench ROMs. Ein Tool namens arosboot lädt die AROS libraries für den nächsten
Neustart. Wenn alles gut läuft, startet der Rechner sofort neu und es gibt keinen Unterschied in der gewöhnlichen
Systemgeschwindigkeit.
|
Derzeit weisen nur die Module exec.strap, alert.hook, utility.library, keymap.library und commodities.library eine ausreichende
Kompatiblität zu OS 3.1 auf. Alle anderen libraries sind auf einem herkömmlichen Amiga noch nicht nutzbar, da die meisten
Entwickler den Linux Modus nutzen und die fehlenden Eingenschaften des AmigaOS einbauen. Das Testen der ursprünglichen Umgebung
und der Debugprozess kommen später.
 AROS
wurde für die einfache Portierung auf verschiedene Umgebungen entwickelt und die existierenden Modi sind nur ein Beginn. Die einzige
wirkliche Einschränkung beim Portieren von AROS auf andere Systeme in nativen oder emulierten Modi besteht in der kleinen Anzahl
an Entwicklern. Vor einigen Monaten wurde in der Mailingliste über eine Portierung auf PowerPC diskutiert.
Przemyslaw Szczygielski arbeitet an einer AROS-Version für Linux APUS, Linux PPC und MkLinux. Claus Herrmann arbeitet an einer
nativen Amiga PowerPC Version. Dies ist kein gewöhnlicher neuer PPC-Kernel, wie die von Phase 5 und Haage & Partner: AROS wird
ein ausschließliches PowerPC-System, auf welchem alte 68000-Anwendungen nur mit Softwareemulation laufen. Ein emulierter
Modus, wie unter UNIX, könnte ebenso erstellt werden, wo AROS für PowerPC auf einem eigenen Bildschirm läuft, mit dem originalen AmigaOS
im Hintergrund auf einem 68000.
In Bearbeitung
Mitte 1998 sank die Arbeit an AROS bis zu einem Beinahe Aus herab. Das Projekt erreichte einen sehr schwierigen Punkt.
Nachdem die Kernelteile des AmigaOS (exec, dos, expansion und utility) geschrieben waren, war es nicht mehr möglich, ohne den
schwierigsten Teil des AmigaOS weiterzumachen: Intuition. In der Gestaltung des AmigaOS sind Intuition, input.device, Graphics und Layers
voneinander abhängige Module. Man kann von nur einem dieser Module keine lauffähige Version erzeugen. Für AROS wurde das noch
erschwert durch die benötigten hardwareunabhängigen Layer für graphics and input.
Ende 1998, nach endlosen technischen Diskussionen, nahm man das Projekt sehr schnell wieder auf. Unter einem enormen
Arbeitsaufwand portierten Nils Henrik Lorentzen, Stefan Berger, Henning Kiel und Bernhard Fastenrath in wenigen Monaten Intuition, Graphics
und Layers zu einer zufriedenstellenden Lauffähigkeit und man konnte nun zu den nächsten Teilen übergehen: GadTools, Asl und Boopsi.
 Johan Alfredsson arbeitet nun, nach der
Fertigstellung der commodities.library und datatypes.library, an der realtime.library und den fehlenden Teilen des console.device,
damit man bald die Shell in einem CON: Fenster, wie auf dem Amiga, öffnen kann. Sobald Michael Schultz die benötigten Treiber
fertiggestellt hat, wird es möglich sein, auf PC-Festplatten FastFileSystem-Partitionen anzulegen und die ibmpc-native Version
zu booten. In der Zwischenzeit hat Branko Collins seine Hilfe zum Erneuern und Korrigieren der Dokumentation für AROS und zum
Überarbeiten des Aussehens der Webseite angeboten. Die Webseite soll ab September auch für Nicht-Entwickler verfügbar sein.
Während die einzelnen Module nahezu fertiggestellt sind, wird eine Portierung existierender Amiga-Software auf AROS möglich. Um
nicht unnötig menschliche Resourcen zu verbrauchen, wurde entschieden, Systemwerkzeuge, für welche schon PD-Pendants existieren,
nicht in Angriff zu nehmen. In der Tat existiert eine Menge Software aus den letzten Jahren, welche die Pendants aus dem AmigaOS
3.1. ersetzt und verbessert. Die Workbench, beispielsweise, kann durch Scalos oder Directory Opus ersetzt werden.
Jeder richtige Amiga User hat eine ganze Anzahl dieser Programme zusammen mit vielen Patches zur Verbesserung des Aussehens und
der Funktionalität des Systems installiert. Letztere werden in AROS überflüssig, da das Vorhandensein des kompletten Quellcodes
die Änderungen direkt im Betriebssystem zu machen ermöglicht, anstatt Patches zu benutzen.
HIDD
Module, welche im AmigaOS direkten Zugriff auf die Amigahardware haben (graphic.library, gameport.device, keyboard.device, serial.device,
etc.), nutzen in AROS hardwareunabhängige Treiber, die HIDD (Hardware Independent Device Driver). Dies sind in der
Realität boopsi Klassen, welche die typische Vererbung in objektorientierten Systemen nutzen, um die Arbeit beim Erstellen neuer
Treiber zu minimieren. Nach einer gründlichen Gestaltungsphase wurde diese Flexibilität ohne merkliche Verluste in der
Geschwindigkeit erreicht.
 Ein Treiber für eine neue Grafikkarte kann
in wenigen Stunden geschrieben werden. Man muss nur den Code zum Initialisieren des Framepuffers und eine Funktion zum Zeichnen
einzelner Pixel implementieren. Alle anderen Methoden der HIDD Treiber können von der allgemeinen ''graphic device'' Klasse
vererbt werden, welche jede Zeichenfunktion durch die Methode WritePixel emulieren kann. Später kann der Treiber durch direkte
Implementation der Funktionen optimiert und beschleunigt werden. In dieser Weise ist die AROS graphics.library auf eine
höhere Schnittstelle für die Zugriffe der untergeordneten HIDDs reduziert.
Zur Zeit gibt es ein HIDD für ein X11 Fenster als Ausgabegerät und andere für Eingaben durch Maus und Tastatur. Der IBM-PC Modus
hat ähnliche HIDDs für den direkten Zugriff auf die PC Hardware. Niemand hat bisher HIDDs für die Amigahardware geschrieben, es
sollte jedoch einfach sein.
Bekanntheitsprobleme
Viele von euch werden jetzt denken, wieso ein solch wichtiges Projekt schon seit über drei Jahren ein Schattendasein fristet.
Der Hauptgrund ist die zweifelhafte rechtliche Position von Amiga Inc.
Es ist möglich, aber nicht sicher, das ein Vertrieb eines Betriebssystems, welches funktionell dem AmigaOS gleicht, ein Verstoß
gegen einige Patente von Commodore, nun Gateway 2000, bedeutet. Falls Amiga Inc. rechtliche Schritte einleiten sollte, hat das AROS
Team nicht die wirtschaftliche Kraft, sich dagegen zu verteidigen.
Während der letzten zwei Jahre versuchten Aaron Digulla und andere Entwickler Petro Tyschtschenko, Jeff Schindler und Bill McEwen
zu kontaktieren. Die persönlichen Ansichten der Leute von Amiga Inc waren immer positiv, aber bisher gab es keine definitive
offizielle Antwort. Aufgrund der fehlenden rechtlichen Information über den Status von AROS besitzen nur die betreffenden
Entwickler einen Zugriff auf die Quellen.
Veröffentlichung
 Kürzlich war es möglich, die Inhalte der Commodore Patente im U.S. Patentbüro zu sichten. Es scheint, dass einige
Änderungen an Intuitionfunktionen nötig sind, um Patentverletzungen zu vermeiden.
Nach dieser Entdeckung war es möglich, eine Diskussion über die Veröffentlichung von AROS als Public Domain zu beginnen. Der
entscheidende Punkt dieser Diskussion bestand in der Vertriebslizenz. Obwohl alle Entwickler mit einer nichtkommerziellen Open Source
Lizenz einverstanden waren, musste noch über eine GPL oder BSD Lizensierung beraten werden. Eine Anzahl Alternativen wurden
aufgezeigt, so z.B. auch eine speziell neu verfasste Lizenz. Die endgültige Entscheidung lag bei MPL. MPL ist GPL sehr ähnlich,
gibt aber dem Team die Möglichkeit, den Quellcode Drittfirmen in Form anderer Lizenzformen anzubieten, was Firmen, wie Amiga Inc, Phase5
und Haage & Partner gestatten würde, AROS als Teil bzw. als Ganzes für die Entwicklung eines kommerziellen Produkts zu
verwenden, ohne die Quellen veröffentlichen zu müssen.
Später setzte Aaron Digulla einen festen Termin für die erste Veröffentlichung von AROS, und fragte bei allen Entwicklern
bezüglich der noch zu veröffentlichenden Sachen an. Das erste Aminet Upload gab es während der World Of Amiga. Die
Veröffentlichung ist in 4 Archive unterteilt; Quellen, Dokumentation, binäre Amigadateien und binäre Linuxdateien.
Schlussbetrachtung
Obwohl seit dem Aus von Commodore sechs Jahre vergangen sind, ist trotz aller Erwartungen der Amiga und sein Betriebssystem noch
am Leben und eine neue Version wird bald veröffentlicht. Aber auch eine frei vertreibbare Version wird hinsichtlich der vielen Vorteilen für
den Endverbraucher noch benötigt, damit die Entwicklung des Betriebssystems nicht allein von ökonomischen Gesichtspunkten geprägt wird.
Tatsächlich ist AROS das ausgereifteste AmigaOS-Ersatzprojekt und der Tag, an dem Nutzer davon profitieren werden, ist sehr nahe. Die Quellen auf
dem CVS-Server haben eine Größe von mehr als 31MB erreicht und 65% aller Systemfunktionen sind bereits fertiggestellt. An AROS
arbeiten fast 90 Entwickler und dank steigender Systemunterstützung geht die Arbeit schneller und schneller voran.
Der zukünftige Erfolg von AROS wird zum größten Teil davon abhängen, inwieweit die Amigaentwickler ihre Arbeit an ein Open Source OS
Modell anpassen können. Anstatt Energien auf die individuelle Arbeit an kleinen Programmen zu verschwenden, sollten die
Entwickler ihren Teil zur Verbesserung des Gesamtsystems beitragen. Es können wahrlich jede Menge an Beispielen für derartige
Modelle angeführt werden. Hierzu sollte es genügen, Linux oder FreeBSD anzuführen. Auch bezüglich der Softwareentwicklung,
Einheit macht stark.
Bernardo Innocenti
Referenzen
|
. |
![[Made On Amiga]](../../images/amiga.gif){kind=small}
