Gerüchteküche MultiTOS
Seit der CeBIT '92 verkaufen selbsterklärte »MultiTOS-Experten« allerhand Aus-den-Fingern-Gesogenes als ewigwährende Wahrheit. Wir wollen hier die Wogen etwas glätten.
Wahr ist, daß MultiTOS sicherlich ein tiefgreifender Einschnitt ist, der die Softwareentwicklung der Zukunft deutlich prägen wird. Und während die deutschen Entwickler das auf der CeBIT vorgestellte »MultiTOS« interessiert durchforschen, bricht bei Presse und Publikum teils berechtigte, teils unbegründete Euphorie aus, die vielfach zu wilden Spekulationen führte.
Zunächst mal: MultiTOS wird noch nicht ausgeliefert und dies ist nicht etwa mit einer Trägheit Ataris zu begründen, sondern hat durchaus ernstzunehmende Gründe. Ein derart einschneidender Konzeptionswechsel bedarf gründlicher Überlegung.
Solches zeugt nämlich nicht etwa von tiefgreifender Konzeptionslosigkeit, sondern allenfalls davon, daß man Konzepte, welche die Zukunft des Atari-Betriebssystems bestimmen werden, sehr genau überdenken muß, um sich nicht heute die Zukunft zu verbauen. Es ist deshalb völlig offen, wann MultiTOS endgültig ausgeliefert werden wird. Atari wird sich, so bleibt zu hoffen, soviel Zeit wie notwendig damit lassen.
Folglich ist es völlig unsinnig, schon jetzt über die Realisation von Details wie etwa die auf der CeBIT angekündigte Memory-Protection zu schreiben. Da MultiTOS nicht offiziell freigegeben und für jedermann erhältlich ist, bleibt vorerst ungeklärt, wie Detailprobleme letztendlich gelöst sein werden - folglich bringt es niemanden voran, in aller Öffentlichkeit Details der Beta-Fassung breitzutreten.
Fest steht, daß das Ataris Multitasking-Betriebssystem sich aus einem für Multitasking überarbeiteten AES und dem Multitasking Kernal »MiNT« des Kanadiers Eric Smith zusammen setzt [1]. MiNT ist seit langer Zeit für jeden erhältlich, seine Spezifikationen, Dokumentationen und sogar sein Source-Code ist in jeder gut sortierten Mailbox zu haben.
MiNT umlagert das GEMDOS und ersetzt bereits jetzt alle wesentlichen GEMDOS Funktionen. Es ist zu erwarten, daß MiNT eines Tages das GEMDOS, seit langem die schwächste Stelle des TOS, gänzlich ersetzen wird.
Schon heute ist die Verwendung des GEMDOS auf die File-Funktionen beschränkt, I/O-Redirection wird dabei von MiNT ebenfalls eigenhändig erledigt. Filesysteme sind unter MiNT jedoch grundsätzlich nachladbar. Schon heute ist das Minix-Filesystem für MiNT erhältlich.
Darüber hinaus ist MiNT jedoch ein vom Atari-MultiTOS völlig unabhängiges System, das unter jedem Atari TOS installiert werden kann. Somit bedeutet die Existenz von MiNT selbstverständlich nicht, daß auch das Atari-MultiTOS benutzt wird und entsprechend erweiterte AES-Funktionen zur Verfügung stehen.
Es war im übrigen immer ein grober Fehler, von der Versionsnummer der einen Betriebssystemschicht auf die einer anderen Schlüsse zu ziehen. Als Beispiel hierfür sei die AES-Funktion »fsel_exinput()« genannt, die Atari erstmals im TOS 1.04 implementierte. Von der TOS-Versionsnummer oder gar der GEMDOS-Version ließ sich jedoch niemals auf die Existenz von »fsel_exinput()« schließen. Doch genau dieser Fehler wird erneut begangen. So veröffentlichten wir in der Juni-Ausgabe des ST-Magazins eine Routine, die das Vorhandensein von MultiTOS anhand des MiNT-cookies zu ermitteln sucht [2]. Fakt ist, daß der MiNT-cookie, wie der Name es nicht deutlicher hätte ausdrücken können, die Präsenz von MiNT bedeutet. Somit stehen beispielsweise erweiterte Directory- und Prozeßfunktionen zur Verfügung. Ob jedoch MultiTOS Anwendung findet, bleibt selbstverständlich ungeklärt. Darüber hinaus ist am Rückgabewert von appl_init() weder abzulesen, ob das Programm im AUTO-Ordner, noch als TOS-Programm, noch als Accessory, noch von MiNT oder noch von MultiTOS gestartet wurde. Er besagt einzig und allein, ob das Programm als GEM-Programm angemeldet werden konnte oder nicht, im zweiten Fall erhält das Programm eine »applid« von -1 als Fehlermeldung.
Im übrigen bleibt zu bemerken, daß gerade das verwendete GFA-Basic auf grund der außerordentlich zurückhaltenden Wartung seitens des Herstellers, eine denkbar schlechte Basis für Systementwicklung unter MultiTOS darstellt. Zumindest aber erfordert es überproportional großen Aufwand vom Programmierer, mit GFA-Basic saubere Applikationen zu entwerfen, muß er doch an diverser Stellen um die bekannten aber nicht beseitigten Fehler herumprogrammieren und in Libraries herumpatchen die ihm zu allem Übel nicht im Sourcecode mitgeliefert werden, ein Syndrom, das allerdings auch manchen C-Programmierer fluchen läßt.
Ebenfalls in der Juni Ausgabe äußerten wir uns eingehend über die »Superschnellen Line-A-Funktionen«, die an dieser Stelle nicht unkommentiert bleiben sollen [3]. Es ist zum einen schon vielfach erwähnt worden daß Line-A-Funktionen in künftigen GEM-Erweiterungen immer auf Kriegsfuß stehen. Atari selbst hat dieses leider erst viel zu spät erkannt und eine entsprechende Warnung veröffentlicht [4].
Das endgültige Aus dürfte nun MiNT bedeuten. Unter MiNT kann nämlich praktisch jederzeit ein Prozeßwechsel stattfinden. In der Praxis nimmt MiNT zwar momentan keinen Taskswitch vor, wenn ein Programm im Supervisormodus arbeitet oder aus diesem heraus OS-calls absetzte. Das muß aber nicht so bleiben. Zwar spricht die Erfahrung anderer, ähnlich funktionierender Systeme dafür, daß ein Taskwechsel dem Usermodus vorenthalten bleibt, davon als Voraussetzung für fehlerfreies Arbeiten eines Programms auszugehen, wäre jedoch ein kapitaler Fehler.
Dies erschwert die Arbeit mit Line-A-Funktionen. Schließlich können nun zwei verschiedene Prozesse den Line-A-Variablenraum gleichzeitig beschreiben. Ein Beispiel:
- Prozeß A erfragt mit »Line A Init« die Basisadresse des Line-A-Variablenraums.
- Prozeß B gelangt durch einen Taskwechsel ans Ruder und erfragt ebenfalls die Adresse des Variablenraums. Da dieser Variablenraum grundsätzlich nicht prozeßrelativ ist, erhält er dieselbe Adresse.
- Prozeß A möchte einen »superschnellen« Text-Blit durchführen, und beginnt, den erfragten Variablenraum mit seinen Parametern (Schreibmodus, Position, Textattribute etc.) zu füllen.
- Prozeß B möchte ebenfalls die »superschnellen Line-A-Funktionen« keinesfalls missen und beginnt ebenfalls damit, den Variablenraum mit seinen Parametern, die sich selbstverständlich von denen des Prozesses A unterscheiden, zu füllen.
- Egal, welcher der beiden Prozesse den nun folgenden Line-A-call absetzt, der benötigte Variablenraum enthält einen nicht eindeutig bestimmten Inhalt. Folglich wird Müll auf den Bildschirm geblittet, wenn auch »superschnell«.
Ein anderes heiß diskutiertes Problem stellen Desktop-Hintergründe dar. Unter GEM konnte jedes Programm jederzeit eigene Desktops installieren, wovon auch reichlich Gebrauch gemacht wurde. Wie auf der CeBIT zu besichtigen war, wechselt MultiTOS beim Aktivieren einer Applikation den Desktop. Dadurch werden vermehrt Redraws ausgeführt und die Wahrscheinlichkeit, daß gerade dann, wenn der Anwender einen bestimmten Desktop benötigt, ein anderer dargestellt wird, wächst mit der Anzahl derjenigen Programme, die eigene Desktops installieren.
Diese Problematik ist nicht neu, man kennt sie sowohl von anderen Systemen als auch seit dem Erscheinen von »MultiGEM« von PAM Software oder "Magix« von Bela auf dem ST. Daraus meinen nun aber einige Meinungsmacher schließen zu müssen, daß eigene installierte Desktops grundsätzlich unschön, wenn nicht gar unsauber seien.
Dazu folgendes: In der Vergangenheit haben viel zu viele Applikationen eigene Desktop-Hintergründe unnötig angemeldet. Der Sinn eines eigenen Desktops beispielsweise bei einem Texteditor oder einem Resource Construction Set ist grundsätzlich anzuzweifeln, zumal die dadurch angebotenen Funktionen in der Regel wenig von Nutzen sind. Wenn beispielsweise ein eigener Desktop nur zum Anwählen einzelner Dateien realisiert wird, stellt sich spontan die Frage, ob eine einfache Fileselector-Box nicht auch genügt hätte. Andererseits gibt es durchaus gute Gründe, eigene Desktops zu installieren, beispielsweise dann, wenn dies eine Vielzahl von Einzelfunktionen übersichtlich darstellt und dem Anwender leicht zugänglich macht. Streamer-Software dürfte über Fileselektoren kaum bedienbar sein.
Es wäre also vorschnell, grundsätzlich eigene Desktops zu verbannen. Es sollten bei der Softwarekonzeption vielmehr von vornherein die Nachteile sorgfältig gegen die Vorteile abgewogen werden. Einige Programme bieten behelfsweise ein Feature, das den installierten Desktop in ein eigenes Fenster legt, was sich jedoch in der Regel als die schlechteste aller Alternativen erweist. Der Platzbedarf solcher Fenster ist, sollen sie übersichtlich bleiben, recht groß, und es ist zu erwarten, daß auf absehbare Zeit gerade der LowEnd-Anwender das Geld für Großbildschirme und entsprechende Grafikkarten nicht investieren mag. Darüber hinaus ist die Bedienung eines solchen Fensters sehr gewöhnungsbedürftig, zumal das Scrollen des Desktops den meisten Anwendern recht fremd erscheinen wird.
Wenn weiterhin auch noch Pull-Down-Menüs in Fenster hineingezwungen werden, die zudem noch auch nach links und rechts gescrollt werden können, entspricht dies nicht gerade der üblichen GEM-Bedienung. Darüber hinaus sticht die Erreichbarkeit der Accessories aus dem Schema.
Wenn also ein eigens installierter Desktop keinem anderen Zweck dient, denn als Ablageplatz für Dokumente zu fungieren, dann sollte der Programmierer erwägen, gänzlich auf den Desktop zu verzichten und die Dokumente beispielsweise in einem »Sammelfenster« oder gleich jedes einzelne Dokument als winziges Fenster zu verwalten. Da, wie ja schließlich auf der CeBIT in aller Öffentlichkeit stündlich demonstriert wurde, unter MultiTOS die Anzahl der verfügbaren Fenster nur durch den freien Speicherplatz begrenzt ist, können solche Lösungen auch einfach realisiert werden; und daß, ohne dem Anwender gleich eine vollkommen fremde Umgebung aufzuzwingen. Wie wir sehen, ist eine durchgängige Oberflächengestaltung der Programme auch über MultiTOS realisierbar.
Laurenz Prüssner/uw
Literatur:
[1] Eric Smith: »Eric Smith über MiNT«, ST-Magazin 5 / Mai 1992, Seite 8, Markt & Technik Verlag
[2] Ulf Dunkel: »Kekse für GFA-Basic«, ST-Magazin 6 /Juni 1992, Seiten 114f., Markt & Technik Verlag.
[3] Stephan Neller : »Atari ST zutiefst verblittert«, ST-Magazin 6 /Juni 1992, Seiten 92 ff., Markt & Technik Verlag. [4] »The TT030 Companion: Developer's Notes For The Atari TT030«, Atari Corp., Sunnyvale 1990.