Programmierer-Ecke - »OFLS«-Struktur

Die Atari-Messe ist lange vorüber und zurückgeblieben ist wenig. Während Atari selbst wenig Neues bot, kamen die Innovationen diesmal von den Entwicklern. Wir bringen Ihnen vom Messebummel einen neuen praktischen Standard mit.

Während der Entwicklung des neuen Hochleistungskopierers-»Kobold« (wir berichteten in der Oktober-Ausgabe) wurde der Programmierer Hans-Jürgen Richstein auf ein schwerwiegendes Problem aufmerksam: Sein Programm umgeht das GEMDOS als Ein- und Ausgabe-Ebene für Massenspeicher und schreibt direkt per BIOS auf ein logisches Laufwerk. Da GEMDOS von alledem nichts mitbekommt, muß nach Abschluß dieser Operation ein »Forced Media Change« erzwungen und dem GEMDOS der Wechsel des Laufwerks vorgegaukelt werden [1].

GEMDOS erkennt folglich einen Medienwechsel, lädt alle internen Strukturen neu und (das wird nur allzuleicht vergessen) schließt alle für das Laufwerk geöffneten Dateien. Das bedeutet, daß für Parallelprozesse wie beispielsweise Accessories unter Umständen offen gehaltene Dateien geschlossen werden.

Aufmerksame Leser werden es bemerkt haben: Wir gehen davon aus, daß Accessories über die Taskwechsel hindurch Dateien offenhalten. Das sollten Sie nach Aussagen Ataris niemals tun, denn damit entstehen neue Probleme, beispielsweise die Frage der Zugehörigkeit der DTA und weitere kompliziert zu erläuternde Nebeneffekte. Dennoch: auch in jüngster Zeit tauchen immer wieder Accessories auf, die diese Problematik ignorieren und damit einen Haufen Schwierigkeiten provozieren. Eine solche Applikation ist beispielsweise die brandneue Datenbank »Phoenix«, im Vertrieb von Application Systems Heidelberg, die eine Installation als Accessory zuläßt und sämtliche daraus resultierende Probleme ignoriert.

Damit allein ist aber das Problem noch nicht abschließend geklärt, denn der »Kobold« und mit ihm sehr viele andere Programme tätigen Massenspeicherzugriffe über das BIOS in einem Zug mit AES-Aufrufe. Wie jeder Programmierer weiß, kann bei jedem AES-Aufruf ein Taskwechsel erfolgen! Das bedeutet, daß auch sauber programmierte Accessories ganz legal Dateien übers GEMDOS öffnen dürfen, während das Hauptprogramm gerade die FATs neu ordnet. Was dabei passieren kann, läßt sich ausmalen: auch vollkommen korrekt arbeitende Accessories zerstören unter Umständen Datenbestände, wenn das Hauptprogramm BIOS- und AES-Aufrufe mixt.

Noch komplizierter wird es bei Verwendung eines GDOS, das seinerseits bei jedem VDI-Aufruf auf ein Laufwerk zugreifen kann, beispielsweise um neue Zeichensatz-Daten zu lesen oder Metafiles zu schreiben: Jeder, der längere Zeit auf Ataris in der Entwicklung befindlichen FSMGDOS gearbeitet hat, weiß davon ein Lied zu singen. Und auch für andere GDOS-Versionen ist ein Zugriff auf Massenspeicher, der selbstverständlich auf GEMDOS-Ebene erfolgt, unumgänglich.

Also muß das Hauptprogramm eine Reihe von Regeln beachten:

Es darf keine BIOS-Zugriffe auf Laufwerke tätigen, auf denen noch Dateien geöffnet sind.
Es darf einen MediaChange nur für Laufwerke erzwingen, auf denen keine Dateien offenstehen.
Es darf keine BIOS, GEMDOS-, VDI- oder AES-Aufrufe mischen, ohne vor jedem GEMDOS-, VDI- und AES-Aufruf einen MediaChange zu erzwingen, oder aber
Es muß verhindern, daß andere Prozesse auf dieselben logischen Laufwerke zugreifen, wie es selbst.

Das ist nicht einfach. Atari hat nämlich keinen Weg dokumentiert, mit dem ein Programm an die OS-internen Dateistrukturen herankommen könnte und selbst wenn es einen solchen Weg gäbe, wäre darüber zumindest Punkt 4 schwer zu realisieren. Die einzige akzeptable Lösung: ein TSR-Programm für den AUTO-Ordner, das jede Dateioperation jedes Prozesses protokolliert. Darüber hinaus muß es ganze Laufwerke für einen GEMDOSZugriff sperren können.

Ein solches Programm gibt es mittlerweile. Es heißt »CHECK_OFLS« und darf frei kopiert werden. Es liegt beispielsweise dem »Kobold«-Programmpaket bei und sollte in jeder gut bestückten Mailbox, beispielsweise der Maus Hamburg (040/5381657), erhältlich sein. »CHECK_OFLS« legt einen Cookie, und wenn es nötig sein sollte, auch einen kompletten Cookie-Jar, an [2]. Dieser Cookie hat immer die Kennung »OFLS«. Das folgende Value-Langwort ist ein Zeiger auf die folgende Struktur:

struct ofls_cookie
{
 long product; /* Produktkennung */
 unsigned short version; /* z.B. 0x0100 für V 1.00 */
 signed short drives[32]; /* Infos für 32 Laufwerke */
}

Die Struktur des ofls-cookies

Das erste Langwort in der Struktur ist das Identifikationskürzel desjenigen Programms, das die Struktur angelegt hat. Bei »CHECK_OFLS« ist dies »OFLS«, jedoch kann auch ein anderes Programm eine solche Struktur anlegen. Wichtig ist dabei, daß der Cookie immer und jederzeit die Kennung »OFLS« haben muß, während die Produktkennung in der Struktur variabel ist. Im folgenden 16-Bit-Wert ist die Versionsnummer des Programms abgelegt, das die Struktur angelegt hat. Wichtig ist hierbei, daß High-Revision-Nummern eine Protokollstufe anzeigen und nur die Low-Revision für die eventuelle Erkennung einer bestimmten Programmversion genutzt werden dürfen. So darf beispielsweise jeder Programmierer ein ähnliches Programm schreiben, das dann z. B. als Versionsnummer 0x0179 (Version 1.79) ablegt. Es darf aber keine Versionsnummer 0x02xx anlegen, da diese eventuelle Erweiterungen vorsieht (Anregungen sind jederzeit willkommen).

Die anschließenden 32 words kennzeichnen den Status der angeschlossenen Laufwerke (A, B, Q ...). Ist der Wert positiv, zeigt er die Anzahl der für das betreffende Laufwerk geöffneten Dateien. Ist er Null, dann ist keine Datei auf dem betreffenden Laufwerk geöffnet. Ist der Wert negativ, so hat ein Prozeß das entsprechende Laufwerk gesperrt. GEMDOS-Aufrufe auf dieses Laufwerk liefern dann die Fehlermeldung -36 (Access Denied) zurück, ein Zugriff wird von »CHECK-OFLS« unterbunden.

In der Praxis läuft die Kommunikation so ab: Ein Programm, das nur über GEMDOS ausgeben will, braucht sich um nichts zu kümmern. Sollte ein Laufwerk gesperrt sein, liefert ein GEMDOS-Zugriff den Fehler -36 zurück, auf den dann dementsprechend reagiert werden muß (Fehlermeldung an den Anwender).

Will ein Programm über BIOS ausgeben oder einlesen, stellt es zunächst einmal fest, ob der OFLS-Cookie vorhanden ist. Wenn ja, prüft es nach, ob die Anzahl der geöffneten Dateien auf dem betreffenden Laufwerk Null ist. Enthält die Struktur einen positiven oder negativen Wert, darf kein BIOS-Aufruf stattfinden. Ist der Wert 0 gesetzt, schreibt das Programm einen negativen Wert (beispielsweise -1) hinein. Somit wird das GEMDOS gesperrt und andere Prozesse, die ebenfalls die »OFLS «-Struktur erkennen, sind ebenfalls gewarnt.

Nun kann bedenkenlos das BIOS benutzt werden. Zum Abschluß schreibt das Programm wieder den Wert 0 in die Struktur und führt einen Forced-Media-Change durch. Nun ist das GEMDOS wieder »freigeschaltet«.

Auf der Atari-Messe zeigte sich nicht nur ein enormer Bedarf an einer solchen Normung, sondern auch eine hohe Akzeptanz bei den Entwicklern. So hat »CCD« die aktuelle Version des Disk-Editors »Diskus« schon darauf umgestellt, der »Kobold« unterstützt das Protokoll von Haus aus, »Crypton« wird derzeit überarbeitet, »Protar« stellt wahrscheinlich die aktuelle Streamersoftware demnächst um und bei »Hard & Soft« waren Überlegungen zu vernehmen, nach denen Wechselplattenlaufwerke in Zukunft am Auswurf der Medien gehindert werden können, wenn darauf noch Dateien geöffnet sind. Und damit ist das mögliche Anwendungsspektrum noch lange nicht abzusehen. Wir bitten jeden Programmierer, der an die Übernahme dieses Verfahrens denkt, sich bei uns zu melden. Wir werden die Entwicklung in den nächsten Wochen und Monaten verfolgen.

Wieder ein wind_update()-Bug

Einen neuen Bug im Desktop des TOS 2.05/3.05 haben wir in der letzten Woche aufgespürt. Der Desktop führt offenbar zum Schließen aller offenen Fenster einen wind_new()-Aufruf durch und leitet diesen nicht mit wind_update (BEG_UPDATE) ein. Deshalb an dieser Stelle an alle Programmierer nochmals der Hinweis:

wind_new() darf nie ohne vorheriges wind_update (BEG_UPDATE) aufgerufen werden. Andernfalls kann irreparabler Schaden entstehen, das System unter Umständen sogar stehenbleiben. Nach dem wind-new()-call darf keine wind_update (END_UPDATE)-Klammerung stattfinden, denn wind_new() löscht alle wind_update()-Stati.

Unser Listing, das als Accessory installiert werden muß, demonstriert den Bug, indem es bei Erhalt einer jeden AES-Mitteilung eine Alertbox ausgibt. So etwas geschieht auch bei jedem Start eines Programms. Hierbei ruft der Desktop jedoch wind_new() auf und zerstört damit den Bildaufbau.

Laurenz Prüßner/uw

Literatur:
[1] L. Prüßner, »ReineVerständigungsfrage«, ST-Magazin 3/90, Seiten 73ff., Markt& Technik Verlag.
[2] J. Reschke, »Vorhang auf für die Keksdose«, ST-Magazin 3/90, Seiten 62f., Markt & Technik Verlag..

Wupdee demonstriert den wind_update-Fehler: Listing

Aus: ST-Magazin 11 / 1991, Seite 74

Links