Programmiererecke - Nachschlag mit Trick
Kaum scheinen die Geheimnisse der »wind_update()«-Funktion gelüftet, zeigt sich: Ataris neuer TT-Desktop behandelt diese Funktion falsch.
Und so äußert sich die Macke: Wenn ein Accessory sehr bald nach dem eigenen Start die »wind_update(BEG_UPDATE);« - Routine aufruft, beenden normalerweise alle konventionellen Desktops erst einmal ihren eigenen Bildaufbau. Sie zeichnen die Menüleiste sowie den Bildhintergrund und die Laufwerks-Icons, sofern Sie damit bereits begonnen haben, wenn das Accessory seine Schreibbereitschaft anmeldet. Sobald der Bildaufbau des Desktops beendet ist, arbeitet das Accessory wie gewohnt weiter.
Der neue Desktop im TT aber stammt im Gegensatz zu allen vorherigen Versionen nicht von Digital Research, sondern ist eine komplette Eigenentwicklung von Atari. Prompt kümmert er sich einfach nicht um die »wind_update()«-Behandlung: Nachdem ein Accessory sein Interesse zum Schreiben auf den Bildschirm per »wind_update()« angemeldet hat, teilt GEM dem Accessory sofort das Recht zum Schreiben auf den Bildschirm zu. Der Bildhintergrund ist zu diesem Zeitpunkt noch weiß, was sicher nicht allzu schön, aber gerade noch akzeptabel ist, zumal keine Dokumentation den Zustand des Bildhintergrunds garantiert.
Der Bildaufbau des Desktops wird nun aber nicht unterbrochen, wie dies eigentlich sein sollte und wie es bei den sauber programmierten DRI-Desktops auch geschieht. Statt dessen zeichnet der Desktop seine Menüleiste, obwohl das Accessory »alleiniges Schreibrecht« auf den Bildschirm haben sollte!
Und es kommt noch dicker: Sobald das Accessory seine Arbeit auf dem Bildschirm per »wind_update (END_UPDATE);« für beendet erklärt, zeichnet der Desktop seinen Bildschirm zwar weiter, ist aber nicht mehr in der Lage, Drop-Down-Menüs herunterklappen zu lassen.
Dieser Fehler tritt erstaunlicherweise nur dann auf, wenn nach der »wind_update()«-Ankündigung tatsächlich auf den Bildschirm geschrieben wird. Wenn Sie lediglich, wie in der Ausgabe November 90 empfohlen, Speicher anfordern und keine AES-Routinen zum Schreiben auf den Bildschirm benutzen, arbeitet das System korrekt. Unser Beispiellisting demonstriert den Fehler bzw. das korrekte Arbeiten auf älteren TOS-Versionen.
Alle Probleme hätte Atari durch die ordnungsgemäße Benutzung der »wind_update()«-Funktion vor und nach dem Bildaufbau des Desktops verhindert. Wir haben daraufhin eine Fehlerbeschreibung an Atari gesandt. Es bleibt also zu hoffen, daß Atari diesen Fehler beseitigt, bevor der fehlerhafte TT-Desktop sich wie eine Seuche verbreitet.
Aber erfahrungsgemäß hilft man sich am besten selbst: Wir haben uns einen Trick einfallen lassen, um die ordnungsgemäße Bildausgabe dennoch zu ermöglichen. In der Regel hilft es, vor der ersten Bildschirmausgabe, aber nach der Speicherreservierung eine kurze Zeit zu warten und dabei einige Prozeßumschaltungen zu erzwingen, beispielsweise durch
for (i = 0; i < 10; i + +)
evnt_timer (15, 0);
Das ist »Erste Hilfe«, und von sauberer Programmierung kann nun wirklich keine Rede mehr sein! So bleibt derzeit auf Leonard Tramiel zu hoffen, der als Entwicklungskoordinator für solche Patzer verantwortlich ist.
In den derzeit ausgelieferten TTs befindet sich das Betriebssystem noch in EPROMs, also in lösch-wiederbeschreibbaren Speicherbausteinen. Dies ist ein deutliches Zeichen dafür, daß am TT-TOS noch immer auf Hochtouren gearbeitet wird und daß Atari in absehbarer Zeit ein neues TT-TOS veröffentlichen wird.
Da unsere November-Programmiererecke ein erstaunlich großes Echo unter den Entwicklern gefunden hat, möchten wir sie an dieser Stelle etwas ergänzen:
Programmierer von Accessories zeigen oftmals eine frappante Angst vor dem Aufruf der GEM-Fileselector-Box und benutzen stattdessen recht abenteuerliche Eigenkreationen. Der Grund: Ein vergessener »wind_update()«-Aufruf zeigt sich hier besonders schnell. Ohne vorangegangene Ankündigung einer Bildschirmmanipulation überschreibt der Desktop gnadenlos eine frisch gezeichnete Dateiauswahl-Box. Sehr deutlich zeigt sich dieser Fehler z. B. bei den etwas älteren Versionen von »UUCODE«, einem Accessory, das Binärdateien in ASCII-Codes und zurück übersetzt.
Leserfrage: Nach welchen Kriterien verteilt GEM die »Schreibrechte«; werden beispielsweise Hauptapplikationen den Accessories vorgezogen, wenn mehrere Programme ihre Bereitschaft zum Schreiben auf den Bildschirm ankündigen?
Die Antwort ist einfach: GEM verfährt wortwörtlich nach dem Prinzip »wer zuerst kommt, malt zuerst«. Die Schreibrechte werden in der Reihenfolge vergeben, in der die Programme ihre Schreibbereitschaft ankündigten.
Weitere Frage: Was geschieht, wenn mehrere Accessories nach unserem Verfahren zur sicheren »Malloc()«-Reservierung vorgehen? Einige Leser wollten wissen, ob die Autostart-Applikation, die das sichere Reservieren von Speicherplatz ja unmöglich macht, schon nach dem Abschluß der Reservierungen des ersten Accessories gestartet wird, so daß die restlichen Accessories keine Gelegenheit mehr zur »sauberen« Speicherreservierung hätten?
Seien Sie beruhigt: Nach dem von uns vorgeschlagenen Verfahren gelangen alle sechs Accessories mit Sicherheit an ihren residenten Speicher.
Letzte Frage: Inwiefern ist eine Verschachtelung mehrerer »wind-update()«-Befehle erlaubt und wie wird sie korrekt bearbeitet? Da die GEM-Dokumentation keine Aussagen dazu machte, stellten wir selbst Versuche an.
So zeigte sich, daß GEM verschachtelte »wind_update()«-Aufrufe durchaus ordentlich bearbeiten kann. Verständlich, wenn man bedenkt, daß GEM-eigene Routinen wie z. B. »form_alert()« intern die »win_update()«-Funktion benutzen, ohne daß der Programmierer davon etwas bemerkt. Ließe GEM keine Verschachtelungen zu, würde ein form_alert()-Aufruf nach einem wind_update (BEG_UPDATE); einen Fehler produzieren. Aber so ist's eben nicht!
Auf einen weit verbreiteten Irrtum bezüglich des Task-Wechsels im GEM (der Umschaltung zwischen den parallel laufenden Prozessen) machte uns ein Entwickler aus München aufmerksam: Viele Programmierer meinen nämlich, GEM könne einen Task-Wechsel nur bei Aufrufen der Ereignisbibliothek (»event-Library«) ausführen. Doch weit gefehlt! Zwar führt der Aufruf
evnt_timer( 1, 0);
zu einem unfreiwilligen Task-Wechsel, nach dem Aufruf bearbeitet GEM erst einmal einen anderen Prozeß, aber es kann selbsttätig einen Task-Wechsel durchführen. Möglicherweise bei jedem AES-Aufruf, ohne daß der Programmierer vorhersieht, wann er genau auftritt.
Flag-Setter
Ebenfalls stellten wir in der Ausgabe 11/90 die erst kürzlich dokumentierten Bits im Programm-Header vor [2]. Diese Bits manipulieren Sie beispielsweise in der neuen Gemini-Version 1.2 durch »chmod«. Für die GEM-Komfort gewohnten Leser des ST-Magazins haben wir ein eigenständiges Programm, den »Flag-Setter«, entwickelt. Da das Programm mit insgesamt 13 KByte Länge den Rahmen dieses Artikels sprengen würde, bieten wir Ihnen das Programm auf unserer Leserservicediskette an.
Der »Flag-Setter« arbeitet als Programm sowie als Accessory. Nun fordert Sie das Programm zur Auswahl eines Programms auf, dessen Header-Bits in »ph_res_2« zu ändern sind.
Nach der Dateiauswahl erwartet Sie ein einfach gehaltenes Hauptmenü, in dem Sie alle Veränderungen sowohl per Maus als auch mit der Tastatur erledigen. Mit einem Klick auf den Menüpunkt »Write« oder die Tastenkombination < Alternate > - < W > schreiben Sie die neue Konfiguration im ausgewählten Programm.
(uw)
Literatur:
[l] L. Prüßner: »GEM-Verkehrsplanung: Aktion .oberer Bildschirm«, ST-Magazin 11/90, Seiten 68ff., Markt & Technik
[2] J. F. Reschke: »Medley im TT-RAM«, ST-Magazin 11/90, Seiten 66f., Markt & Technik
Unser C-Programm demonstriert den »wind_update()«-Fehler im neuen Desktop
Laurenz Prüssner