Atarium

10 Jahre TOS-Computer

Seit Über 10 Jahren gibt es nun schon den ATARI ST und sein Betriebssystem TOS. Um so verwundener ist man, wenn sich wieder einmal herausstellt, daß eigentlich 'uralte' Dinge weitgehend unbekannt sind. Gemeint sind in diesem Fall die sogenannten 'logischen' GEMDOS-Vektoren, speziell etv_term (Vektor 257) und etv_critic (Vektor 258).

Der Name 'logischer' Vektor beruht vermutlich auf der Tatsache, daß es sich im Gegensatz zu anderen Sprungvektoren um HighLevel-Einsprünge handelt. Die Vektoren befinden sich zwar traditionell an den Adressen $404 und $408, sollten aber grundsätzlich nur über die BIOS-Funktion Setexc() gesetzt oder abgefragt werden (Vektornummern $101 und $102). Der Grund: unter Multitasking- Systemen hat jeder gleichzeitig laufende Prozeß einen eigenen Satz Vektoren. Beginnen wir mit dem Process-Termination-Vector etv_term. Er wird vom GEMDOS immer dann durchsprungen, wenn ein GEMDOS-Prozeß beendet wird (Ausnahme unter MiNT: bei SIGKILL). Das kann daran liegen, daß explizit eine der Pterm?-Varianten aufgerufen wurde, ist aber möglicherweise auch das Ergebnis eines Absturzes [in einem solchen Fall schreibt nämlich TOS die allseits bekannten Bomben in den Bildspeicher und terminiert das Programm mit Pterm (-32)].

Zum Zeitpunkt des Aufrufs steckt man also mitten innerhalb eines GEMDOS- Aufrufs, und da GEMDOS normalerweise nicht reentrant ist, dürfen hier keine GEMDOS- oder gar AES-Aufrufe mehr gemacht werden . Ebensowenig ist es möglich, den Abbruch des Programms zu verhindern. Dazu müßte man auf saubere Weise "aus dem GEMDOS-Aufruf hinauskommen", und wie das zuverlässig geht, ist nicht dokumentiert.

Crash-Infos

Wozu also kann etv_term nützlich sein? Eine denkbare Anwendung ist die Aus- gabe von Informationen nach einem Absturz (siehe Listing). Dabei macht man sich die Tatsache zunutze, daß TOS die wichtigsten Crash-Informationen in den Speicherbereich ab Adresse $380 schreibt. Wenn man nun diese Informationen etwas aufbereitet, können auch Benutzer ohne installierten Debugger eine hilfreichere Fehlermeldung als "ist abgestürzt" abliefern. Wichtig ist dabei, daß die Funktion eines möglicherweise installierten Debuggers wie TempleMon nicht verhindert wird.

Eine andere Anwendung ist das Entfernen von eigenen Routinen aus verbogenen Systemvektoren. Grundsätzlich gilt zwar die Regel, daß Systemvektoren nur von residenten Programmen verbogen werden sollten, manchmal ist dies aber unumgänglich ...

Zum Beispiel dann, wenn man unter Single-TOS-Versionen den Zeiger auf den Critical Error Handier (etv_critic) modifizieren will. Da unter Single-TOS- Versionen dieser Vektor global für alle Applikationen verwaltet wird, muß man ihn nach Beendigung des Programms wieder auf den alten Wert zurücksetzen. Dafür ist der etv_term-Vektor natürlich das ideale Instrument.

Ein typisches Beispiel für ein Programm, das den Critical Error Handler verstellen will, ist eine TOS-Anwendung, bei der man schon vorher weiß, daß bei DiskZugriffen I/O-Fehlerwie"Diskette schreibgeschützt" auftreten werden. In einem solchen Fall ist es sinnvoll, den Error Handler so zu modifizieren, daß gar nicht erst eine Meldung erscheint, sondern daß der Fehler unmittelbar an GEMDOS weitergereicht wird.

Kommen wir zum abgebildeten Listing: es installiert in etv_term eine eigene Termination-Routine. Im Falle einer Prozeßbeendigung wird zunächst über ein globales Flag sichergestellt, daß es sich nicht um eine "normale" Prozeßbeendigung gehandelt hat. Ist dies nicht der Fall, wird noch über die Read-Only-Systemvariable "actpd" abgesichert, daß es sich auch wirklich um den eigenen Prozeß handelt. Wenn dies der Fall ist, werden die Informationen aus den Crashdump-Variablen perBIOS auf dem Bildschirm ausgegeben und auf einen Tastendruck gewartet. Schließlich und endlich wird die Termination-Routine aus etv_term entfernt und der Prozeß beendet. Ich hoffe, damit etwas Licht ins Dunkel um etv_term und etv_critic gebracht zu haben. Bevor ich mich bis zum nächsten Monat verabschiede, will ich noch erwähnen, daß das im letzten Monat herbeigesehnte MiNT-Net-Modul für den Web-Browser CAB mittlerweile wirklichkeit geworden ist. Mehr dazu in einem der nächsten Hefte.