Kaos 1.4.2: Fremder Federschmuck
Kaos-Entwickler Andreas Kromke dokumentiert, mit weichen Schwierigkeiten er bei der Modifikation des Betriebssystems zu kämpfen hatte und mit welchen Tricks er TOS 1.4 auf die Beine hilft.
Meist stoßen Anwender nur per Zufall auf Systemfehler beim Atari-TOS 1.4. Die meisten Programme verhindern Systemabstürze und vermitteln damit das trügerische Gefühl, beim TOS herrscht eitel Sonnenschein. Mitunter kaschieren Kommandoprozessoren jedoch nur notdürftig die eingebauten Schwächen im Betriebssystem.
Die Hauptintentionen bei der Umsetzung des Kaos-Projekts war es deshalb, diese Fehler so weit wie möglich zu eliminieren. Ein großer Schritt in diese Richtung gelang bereits mit der Kaos-Version 1.2 ([1]).
Der Macintosh stand Pate
Das Original-TOS weist jedoch eine Reihe Eigenschaften auf, die streng genommen nicht als Fehler bezeichnet werden dürfen. Erst im Vergleich mit anderen Benutzeroberflächen, wie etwa die des Macintosh von Apple, geben den Blick auf diese Schwächen frei. Die Vorteile der »Macs« dienten nicht nur dem Kaos-Team als Vorbild. Ein besonders evidentes Beispiel dafür ist der »Windowmanager« des »AES« (Application Environment System).
Er kontrolliert im wesentlichen die AES-Funktionen »wind_open()« und »wind_close()« zum Öffnen und Schließen von Fenstern.
Für Fensterbewegungen gibt es den Befehl »wind_set()«. Darüber hinaus verwaltet er Fenster-Buttons, etwa den Vergrößerungsknopf und die Scroll-Elemente. Beim Verschieben oder Neuzeichnen (»Redraw«) von Fenstern z.B. übermittelt er seine Kommandos der zuständigen Anwendung.
Der Unterschied zwischen den Window-Welten wird bereits an der Oberfläche deutlich: Während das Macintosh-System nur die Teile des Fensters neu aufbauen läßt, an denen eine Manipulation vorgenommen wurde, zeichnet der Atari-Windowmanager auch Fenster nach, an denen keine Veränderungen vorgenommen wurden.
Das läßt sich im Desktop leicht nachprüfen: Man öffne dazu zwei Fenster und plaziere sie so, daß keines das andere an irgendeiner Stelle überlagert. Wird nun ein Fenster geschlossen, zeichnet TOS 1.4 auch das andere unveränderte Window neu. Ein gänzlich unnötiger Vorgang.
Ein ähnlicher Effekt tritt auf, wenn ein Fenster ein anderes nur teilweise überdeckt. Wird nun das untere Fenster nach oben geklickt, müßten theoretisch nur jene Pixel nachgezeichnet werden, die zuvor überlagert waren.
TOS 1.4 zeichnet sich allerdings durch ein gewisses Maß an Starrsinn aus: Statt das Neuzeichnen auf diese wenigen Pixel zu beschränken, baut es beide Fenster in vollem Umfang neu auf.
TOS-üblicher Flackereffekt
Ähnlich verhält sich TOS, wenn ein Fenster, das teilweise außerhalb des Bildschirms liegt, nach links oben geschoben wird (hier zeichnet das Originalsystem u.U. sogar den gesamten Bildschirm mit allen Fenstern neu).
Die Gegenüberstellung von ST und Macintosh ergibt: Das Atari-TOS ist ein Umstandskrämer. Im GEM werden deshalb Fensteroperationen von TOS-üblichen Flackereffekten begleitet. Das stört nicht nur das ästhetische Empfinden des Betrachters; das ist allenfalls ein Nebeneffekt. Gravierender zählt der Faktor Zeit. Natürlich erfordert die Bildschirmausgabe mit gebremstem Schaum einen erheblichen Rechenmehraufwand.
Um Kaos vollständig von dieser Betriebssystemklammer zu lösen, wurden für den neuen Windowmanager alle Routinen für das Öffnen, Schließen, Vergrößern, »Toppen« und »Droppen« (Insider bezeichnen damit das nach Oben- und Untenbringen der Fenster) neu geschrieben. Die Originalroutinen wurden dazu entfernt.
Lohn der Anstrengung war bei allen Fensteroperationen ein sauberer und schnellerer Bildschirmaufbau. Der muß den strapazierten Vergleich mit Apples Macintosh nicht scheuen. Selbst beim Vergrößern wird nun nur noch der neu aufgezogene Bereich neugezeichnet.
Das funktioniert so: Beim Verschieben per »Bitbit« wird immer ein möglichst großer Bereich kopiert. Gegebenenfalls müssen nun lediglich die Randbereiche neu aufgebaut werden.
Zusätzliches Sicherheitsventil
Auch das Schließen von Fenstern wirkt unter Kaos völlig unspektakulär und beweist, daß sich der ST vorteilhaft mit fremden Federn schmücken kann: Beim Toppen wird das Anwenderprogramm in vielen Fällen überhaupt nicht aktiv. Vor allem, wenn nur der Fensterrand verdeckt war, der vom AES verwaltet wird.
Leider gibt es bisher kein Benchmarkprogramm, das Werte für komplizierte Fensteroperationen liefert. Schätzungsweise arbeitet Kaos hier zehnmal schneller als das Vorbild TOS.
Ganz problemlos bleibt eine Modifikation der Window-Routinen indes nicht. Wie fast immer bei Betriebssystem-Korrekturen, gab’s erwartungsgemäß mit einigen Programmen Schwierigkeiten, allerdings ausschließlich beim Vergrößern der Fenster.
Um diese Fehler bereits im Vorfeld auszuschalten, bauten wir in Kaos ein zusätzliches Sicherheitsventil ein. Ein kleines Accessory stellt die Verträglichkeit zu TOS her. Im Kompatibilitätsmodus zeichnet auch Kaos das gesamte Fenster neu.
Während »Turbo C« und »Tempus« z.B. unbeeinflußt mit den neuen Routinen kooperierten, erfordert beispielsweise die »Gemini«-Shell V1.1 (in der neuesten Version tritt dasselbe Problem auf) die Kompatibilität zu TOS.
Simple Ursache ist die trickreiche Programmierung des alternativen Desktops. Sie prüft bei jeder Änderung der Fenstergröße, die ein Umsortieren des Inhalts erforderlich macht, nach, ob das Fenster verkleinert oder vergrößert worden ist.
Hartnäckiger Hänger gekillt
Im ersten Fall veranlaßt GEM generell keinen Redraw. Das Nachzeichnen übernimmt »Gemini« eigenständig. Im zweiten Fall geht die Shell von einem GEM-Redraw aus; dabei kommt es zu besagten Problemen mit den neuen Routinen.
Programme, die sich bei verändertem Fensterinhalt durch Umsortieren oder eine andere Positionierung nicht selbst um das Neuzeichnen kümmern, harmonieren dagegen reibungslos mit Kaos. Das gilt auch für das Original-GEM, das überflüssige Redraws unterdrückt.
Bei Analyse und Korrektur der Fensterfunktionen gelang es uns auch, einen besonders hartnäckigen und unangenehmen »Hänger« zu beheben. Er führte bisher sporadisch dazu, daß sich der Atari ins Nirwana abmeldete.
Anwender, die besonders flinke Mausbewegungen ausführen und damit Fenster verschieben oder vergrößern, erleben des öfteren, daß plötzlich nichts mehr geht: Die Tastatur sendet ein Dauerklicken und das System läßt keinerlei Eingaben mehr zu. Obwohl sich die Maus noch bewegen läßt, fallen die Menüs nicht mehr herunter.
Als wir den Fehler aufgespürt hatten, erkannten wir, daß er sich jederzeit reproduzieren läßt. Es genügt dazu nach folgendem Fahrplan zu verfahren. Wir haben das einmal ausgiebig unter TOS 1.4 getestet:
Öffnen Sie im Desktop zwei Fenster und ordnen sie untereinander über die ganze Bildschirmbreite an (s. Abb. 1). Dabei sollten sie sich nicht überlappen. Anschließend aktivieren Sie das obere Fenster und ziehen es mit dem Vergrößerungsknopf auf. Die Maus muß dabei auf die Innenfläche des unteren Fensters geschoben werden.
Schwachstelle ausgebügelt
Führen Sie nun mit der linken Maustaste einen schnellen Doppelklick aus. Mit etwas Übung läßt sich so der Atari gezielt stillegen. Der gleiche Effekt läßt sich auch schon — blitzschnelle Mausbewegungen vorausgesetzt — beim Verschieben von Fenstern und Klicken in die Menüleiste erzielten.
Dieser »Systemhänger« ist übrigens seit der TOS-Version 1.0 wohlbekannt. Im Gegensatz zu den bereits erwähnten Redraw-Problemen hat der Hersteller »Digital Research« im GEM 2.0 diese Schwachstelle ausgebügelt.
Doch wer suchet, der findet: Wir stießen auf eine weitere Unstimmigkeit, die auch uns neu war und überhaupt erst ab TOS 1.4 (d.h. auch im STE und TT) dokumentiert werden kann.
Es handelt sich dabei um die Wiederholung von Scrollbalken- und Scrollpfeilen in Fenstern. Dokumentiert ist diese Funktion folgendermaßen: Das »Rainbow TOS«, behaupten die Atari-Autoren, warte nach dem Betätigen der Maustaste, bis die automatische Wiederholung einsetzt. Eine prinzipiell richtige Einschätzung. Nur das Ergebnis entspricht nicht ganz den Absichten der Entwickler.
Die Verzögerung erfolgt realiter nicht erst nach dem Scroll-Befehl, sondern bereits zuvor. Selbst bei einem kurzem Klick versenkte sich das System zunächst in Meditationsübungen, und akzeptiert zunächst keine weiteren Eingaben. Maßgebend für den Systemstillstand ist die Konfiguration des Doppelklicks im Kontrollfeld.
Auslöser dafür ist ein obskurer Systemteil, der dem Benutzerprogramm nur einen AES-Aufruf zugesteht, bevor die Verzögerung einsetzt. Dieser Aufruf besteht im wesentlichen aus einer Bildschirmsperre (wind_update) zur Vorbereitung weiterer Betriebssystemhandlungen. Das Desktop benötigt für jeden Scrollvorgang mindestens 10 Aufrufe.
Zahl der Aufrufe wurde erhöht
Bei der Entwicklung von Kaos konnte die Zahl der möglichen Aufrufe deutlich erhöht werden. Außerdem tritt keine Verzögerung mehr auf, wenn die Maustaste vorher losgelassen wird. Letzteres hatte man bei Atari noch nicht ins Kalkül gezogen.
Zusätzlich invertiert unsere Betriebssystemmodifikation die Scrollpfeile, solange die Maustaste gedrückt ist. Eine Rückmeldung an den Anwender, die anzeigt, daß die Scroll Wiederholung aktiv ist.
Ein alter Bekannter aus TOS 1.2 läßt sich z.B. mit dem »Resource Construction Set« (RCS2) von Digital Research leicht reproduzieren. Beim Scrollen mit gedrückter Maustaste zuckt der Bildschirm verräterisch, bis er sich vollständig abmeldet, wenn der Scrollbalken die untere Begrenzung erreicht hat.
Verursacher in diesem Fall ist die »Message«-Verarbeitung im AES. Sie bewirkt, daß das System beim Nachrichten-Überlauf (Nachrichten kommen schneller an, als sie verarbeitet werden) hängenbleibt. Außerdem ist eine fehlerhafte »Entprell«-Abfrage auslösendes Moment. Das Anwenderprogramm wird dabei mit Scrollpfeil-Nachrichten (WM_ARROWED) geradezu überschüttet. Diesen Fehler korrigiert Kaos 1.4.2 und beweist damit nicht nur seine Softwareverträglichkeit: Unsere Modifikation hat damit auch unter Beweis gestellt, daß es die negativen Einflüsse des Betriebssystems auf zumindest eine Anwendung begrenzt. Anschließend funktionierte das Resource Construction Set 2 ohne unfreiwillige Abstürze.
Von den ST-Magazin-Lesern erhielten wir zu Kaos ein bemerkenswertes Echo. Das gibt uns auch für die Zukunft Mut, unser Projekt weiterzuverfolgen. Da sich Kaos problemlos mit der Überzahl der Beschleunigerkarten versteht, erhielten wir auch von zahlreichen Herstellern Anfragen. In der nächsten Ausgabe lesen Sie, wie Kaos sogar ein 50-MHz-Board mit dem ST harmonieren läßt, (em)
Literatur:
[1] Andreas Kromke, »Das wahre GEMDOS - Fehlerbeseitigung und Optimierung im TOS 1.2 des Atari ST«. C’T 11/88, S. 194
Andreas Kromke