Dieser Artikel ist copyright Amiga Life - Pluricom
. AROS
von Bernardo Innocenti (bernie@cosmos.it) - entnommen aus Amiga Life
Übersetzung ins Deutsche von Dirk Neubauer (dirk.neubauer@p4all.de)


Zurück zum Index Das AmigaOS neu entwickeln
Die Probleme der Textplazierung in Fenstern.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
Aaron Digulla, Gründer und Koordinator von AROS.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
ModuleFunktionenNoch zu tunIn BearbeitungAbgeschlossen
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.

Anfang Juni hatte Intuition noch viele Fehler.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.

Das GadTools Demo, das ASL Dateiauswahlfenster und 
die Intuition Ausgabe.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.

Die aktuelle AROS Homepage enthält viele 
Informationen für Entwickler.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
Die Quellengrößen im CVS Server wachsen konsequent mit dem öffentlichen Vertrieb.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

Homepage:http://www.aros.org
Koordinator:digulla@aros.fh-konstanz.de
Aminet:misc/emu/AROS-docs.tgz
misc/emu/AROS-ibmpc-bin.tgz
misc/emu/AROS-lx86-bin.tgz



Entnommen aus Amiga Life n.105 - (C) Pluricom - Wir danken dem Veröffentlicher.
Weitere Informationen über AmigaLife unter http://www.pluricom.it/amigalife
AmigaLife
.
.


Zurück zur AMiWoRLD Homepage


Copyright AMiWoRLD
Kontakt:
Zu diesem Artikel: bernie@cosmos.it
Allgemeine Info: petty@amiworld.it
[Made On Amiga]