Die XENIX-Struktur von GEMDOS

Einige Zeit war es nicht ganz klar, was für ein Betriebssystem das GEMDOS des ATARI ST eigentlich ist. Kenner des klassischen CP/M erkannten viele System-Funktionen wieder, MS-DOS-Spezialisten glaubten ’ihr’ Betriebssystem an vielen übereinstimmenden Details zu erkennen. Aber ein wesentlicher Teil von GEMDOS (und von MS-DOS7 wird oft überhaupt nicht genau erwähnt oder nur sehr stiefmütterlich behandelt: Die XENIX-Komponente.

Das Betriebssystem XENIX - verwandt mit UNIX - stand Pate bei der Entwicklung der Datei-Funktionen von GEMDOS. Während bei MS-DOS zusätzlich noch das alte CP/M-Dateisystem vorhanden ist, stützt sich GEMDOS ausschließlich auf diese XENIX-Funktionen.

Worin liegt denn das Besondere? Was bringen diese Funktionen? Hier einige Stichworte:

• Einheitliche Datenein- und -ausgabe für alle Schnittstellen und Dateien.
• Datenströme können beliebig „umgeleitet“ werden.
• Benutzerfreundliche Systemaufrufe: Geringer Programmieraufwand, nur wenige Funktionen.

Diese Punkte haben Sie hoffentlich etwas neugierig gemacht! Gehen wir nun etwas tiefer in die Materie. Beginnen wir mit einer kurzen Rückschau auf den schon erwähnten Urahn: Wie sieht bei CP/M das klassische Bild der Datenein- und -ausgabe aus? Für die Datei-Verarbeitungen sind eigene Funktionen (mit dem bekannten File Control Block) vorhanden, für jede Art von Schnittstelle existieren wiederum neue System-Aufrufe. Die Anzahl der Funktionen, die man sich beim Programmieren bereitlegen muß, ist schon beachtlich; bei der moderneren CP/M 3-Version ist sie sogar noch angewachsen.

GEMDOS-Kenner wissen, daß auch ’unser’ Betriebssystem getrennte Funktionen für die serielle und parallele Schnittstelle, für Tastatur, Bildschirm und last not least für das Datei-Handling besitzt. Der wesentliche Punkt ist aber, etwas provozierend formuliert: Diesen ganzen Ballast können Sie vergessen, wenn Sie sich des moderneren XENIX-Konzeptes von GEMDOS bedienen.

Hierbei gibt es nur Kanäle (englisch „Device“). GEMDOS stellt einem Programm beim Start vier solcher Kanäle zur Verfügung:

Kanal 0: logischer Eingabekanal (Standard Input Device)

Kanal 1: logischer Ausgabekanal (Standard Output Device)

Kanal 2: logischer Hilfskanal Standard AUX Device)

Kanal 3: logischer Protokollkanal (Standard List Device)

Die Bezeichnungen deuten bereits an, daß es sich zunächst nicht um real vorhandene Kanäle (Dateien / Schnittstellen) handelt, vielmehr werden gewisse Funktionen beschrieben. Um die Bezeichnung abzukürzen, wird das Wort 'logisch’ weggelassen - sofern keine Mißverständnisse zu befürchten sind.

Die Theorie sieht so aus: Ein Programm liest vom Eingabekanal seine Daten, schreibt seine Ergebnisse auf den Ausgabekanal, Meldungen/Proto-kolle auf den Protokollkanal. Ob allerdings in der Praxis Ergebnisse auf den Hilfskanal, den Ausgabekanal oder den Protokollkanal ausgegeben werden, muß jedes Programm selbst entscheiden. Die Kanalnamen verpflichten zu nichts.

Jedem Kanal ist eine Nummer zugeordnet. Diese Nummer wird als ’Stan-dard-Handle' bezeichnet - im Deutschen sollte man von (logischer) Kanalnummer sprechen. Die Nummern 4 und 5 zählen zwar auch dazu, werden aber beim GEMDOS des ATARI ST nicht benutzt. Bei der Original-Version von Digital Research ist z. B. noch ein Fehlerkanal (zur Ausgabe von Fehlermeldungen) vorhanden.

Neben diesen funktionsbezogenen logischen Kanälen gibt es (Gott sei Dank!) natürlich auch real vorhandene Kanäle: Hierzu zählen eröffnete Dateien und die üblichen Schnittstellen. Eine angemessene deutsche Bezeichnung ist physikalischer Kanal, im Englischen heißt es 'Non-Standard Device’. Diesen Kanälen ordnet GEMDOS die Kanalnummern 6...45 zu - allerdings nicht fest, sondern wie es jeweils paßt, sprich: welche Nummern gerade frei sind.

Wo erscheinen die Daten, wenn sie zum Beispiel auf den Ausgabekanal geschrieben werden? Was ist konkret der Eingabekanal?

Wie diese Kanalzuordnung aussieht, hängt davon ab, was der übergeordnete Prozeß / das übergeordnete Programm hierfür festlegt. Wenn Sie unter GEM ein Programm starten, ist GEM der übergeordnete Prozeß und legt fest, welcher Kanal wohin „geschaltet“ wird. GEM hält sich hierbei an die von GEMDOS festgelegten Ersatzwerte:

Kanalzuordnung unter GEMDOS

Eingabekanal (0) < - > Tastatur /CON:
Ausgabekanal (1) <-> Bildschirm/CON:
Hilfskanal (2) < - > Serielle Schnittstelle/AUX:
Protokollkanal (3j < - > Parallele Schnittstelle/PRN:

Jedes Programm kann diese Zuordnungen ändern - und zwar für die Dauer der eigenen Laufzeit (und die seiner Folgeprozesse). Machen wir in dieser Richtung mal ein Experiment. Wir benötigen dazu das Programm COMMAND.PRG aus dem Entwicklungspaket (oder einen vergleichbaren Befehlsinterpreter) und irgendeine Textdatei mit dem Namen TEXT. DOC. Starten Sie COMMAND unter GEM durch Anklicken. Geben Sie über die Tastatur das Kommando:

Hiermit wird der Inhalt der Textdatei auf den logischen Ausgabekanal geschrieben. Da COMMAND sich ebenfalls an die GEMDOS-Ersatzwerte für die Kanalzuordnung hält, sehen wir den Datei-Inhalt auf dem Bildschirm. Nächstes Kommando:

(Nach dem ’ > ’-Zeichen kein Blank eingeben!) Hiermit wird der Ausgabekanal umgeschaltet auf eine Datei TEXTl.DOC. Auf dem Bildschirm erscheint am Ende nur das Prompt-Zeichen von COMMAND. Ein erneutes TYPE-Kommando ohne den Zusatz > ... zeigt, daß nun wieder normale Verhältnisse herrschen: Ausgabekanal - > Bildschirm.

Falls Sie einen Drucker angeschlossen haben, können Sie Ergebnisse durch den Zusatz >PRN: auch dorthin umleiten.

Ein zweites Experiment: Sie haben sicher irgendein Programm (Name

PROG.PRG), das Daten von der Tastatur liest. Nehmen wir an: genau eine Zeile. Schreiben Sie zunächst eine typische Eingabezeile mit einem Texteditor in eine Datei INPUT.DAT. Nun geben Sie ein:

Statt von der Tastatur holt sich das Programm seine Daten aus der angegebenen Datei. Der Eingabekanal wurde offensichtlich durch <... auf die Datei INPUT.DAT umgeschaltet. Am Ende des Programms ist die alte Zuordnung (Eingabekanal - > Tastatur) wiederhergestellt.

Wie läßt sich nun die Zuordnung logischer Kanal - > physikalischer Kanal von einem Anwender-Programm beeinflussen? Voraussetzung ist, daß Sie eine Programmiersprache verwenden, in der GEMDOS-Aufrufe möglich sind, also etwa C oder Assembler. Die beiden hier wesentlichen GEMDOS-Funktionen sind F_Force ($46) und F_Dup ($45).

Mit F_Force „zwingt“ man einen logischen Kanal auf einen physikalischen, d. h. man verändert im Bild die Schalterstellung:

Parameter für diese Funktion sind deshalb die logische und die physikalische Kanalnummer. Die erste entnehmen wir der Tabelle. Wie bekommen wir aber die zweite? Hier sind zwei Fälle zu unterscheiden:

a) Der betreffende physikalische Kanal ist eine (eröffnete) E)atei. GEM-DOS hat dann nach der Eröffnung die zugehörige physikalische Kanalnummer übergeben.

b) Es handelt sich um eine der Schnittstellen. Beim Start des Programms war diese Schnittstelle irgendeinem logischen Kanal zugeordnet (s. Tabelle). Mit der GEMDOS-Funktion nen F___Dup bekommen Sie unter Angabe dieser logischen Kanalnummer die zugehörige physikalische Kanalnummer.

Die Funktion F__Dup liefert die 'Unbekannte’ x:

Um die gesamte XENIX-Betrachtungs-weise in konkreten Programmen anzuwenden, hier einmal die typischen Situationen und Vorgehensweisen:

1. Sie schreiben ein Programm, in dem Daten ein- und ausgegeben werden. Programmieren Sie stets so, daß logische Kanäle benutzt werden: Für das Schreiben und Lesen von Daten über solche Kanäle sind primär die GEMDOS-Funktionen F_Read ($3F) und F_Write ($40) zuständig. Welcher physikalische Kanal später zur Laufzeit aktiv sein wird, ist bei der Programmierung unwesentlich.

Eine wirkliche Erleichterung: Nicht mehr als zwei Funktionen kommen zur Anwendung! Als Parameter sind bereitzustellen: Anzahl der Bytes, Adresse des Datenpuffers und die logische Kanalnummer. Das war’s.

2. Ein vielleicht schon vorhandenes Programm soll auf andere Ein- und Ausgabekanäle „umgestrickt“ werden. Sie haben zwei Möglichkeiten:

a) Programm am Anfang durch einige Statements ergänzen, die die Kanalumschaltung realisieren. Die eigentliche Verarbeitung bleibt ungeändert. Zuständig sind F_Force und F_Dup.

b) Sie lassen das Programm, wie es ist. Sie schreiben ein neues (relativ kurzes) Programm, das die Kanalumschaltung organisiert und dann das eigentliche Verarbeitungsprogramm startet (mit GEMDOS-Funktion P_Exec ($4B)). Hintergrund: Das übergeordnete Programm reicht immer die (geänderte) Kanalzuordnung an das Folgeprogramm weiter. Wird das erste Programm beendet, so stellen sich die normalen Verhältnisse wieder ein. Vorteil: Ein solches reines Umschaltprogramm können Sie für viele weitere Anwendungen benutzen.

Wenn Dateien ins Spiel kommen, benötigt man zusätzlich Aufrufe für das Eröffnen (F_Open, F_Create) und evtl. Schließen (F_Close) dieser Dateien. In den Beispielen können Sie leicht erkennen, welche Parameter F_Open und F_Create benötigen, F_Close erwartet nur die physikalische Kanalnummer.

Alle in den Programmen geschalteten Kanalzuordnungen werden beim Programm-Ende von GEMDOS automatisch zurückgenommen, eventuell beteiligte Dateien werden geschlossen. Sie können das natürlich auch per Programm machen. Hierauf kommen wir noch einmal beim letzten Programmbeispiel zu sprechen.

Haben Sie mitgezählt? Insgesamt sind höchstens sieben GEMDOS-Funktionen nötig. Damit lassen sich alle Datenein- und -ausgaben über Schnittstellen und Dateien realisieren.

Bevor nun endlich einige Beispiel-Programme kommen, hier noch eine Kehrseite der ganzen Angelegenheit:

Stellen Sie sich vor, Sie haben alle Ausgaben auf eine Datei „umgeleitet“. Zwischendurch tritt irgendwo ein Fehler auf, es soll eine Fehlermeldung auf den Bildschirm (diesmal wirklich!) ausgegeben werden. Natürlich landet diese Meldung ebenfalls in der Datei -was fatal sein könnte.

Schade, daß der Fehlerkanal ausgelassen wurde! Lösung des Problems: Sie gehen nicht den (gedanklichen) Umweg über einen logischen Kanal, sondern geben die Meldung sofort auf einen physikalischen Kanal aus. Auch das geht: Sie eröffnen im Programm (mit F__Open) die „Datei“ CON:

GEMDOS übergibt (im Register DO) als Kanalnummer eine negative (!) Zahl - im Beispiel -1, d. h. im Register steht $FFFF. Unter Angabe dieser Nummer gibt man die Fehlermeldung mit F Write aus.

Fazit: Die physikalischen Kanäle CON:, PRN:, AUX: lassen sich mit F_open eröffnen, GEMDOS teilt eine negative Kanalnummer zu. Schreiben und Lesen geht ansonsten wieder mit F_write und F__Read. Schließen mit F_Close ist nicht erforderlich.

Da diese Kanäle die Daten letztlich Zeichen für Zeichen übertragen, werden sie „Character Devices“ genannt. Die folgende Tabelle zeigt die beim ATARI ST möglichen negativen Kanalnummern.

Liste der Character Devices

Kanalnummer: -1 <-----> Device: CON

-2 <-----> AUX

-3 <-----> PRN

Beispiele:

Alle Beispiele sind in Assembler programmiert. Sie zeigen die einfache Anwendung der XENIX-Funktionen sehr deutlich. Übersetzt wurde mit dem Digital Research Assembler.

Programm 1 und 2 veranschaulichen den Unterschied zwischen logischem Kanal (umschaltbar) und den Character Device (nicht umschaltbar).

Im Programm 1 wird über F_Write eine Zeichenkette auf den logischen Ausgabekanal geschrieben. Speichern Sie das ablauffähige Programm unter dem Namen STANDEV.PRG. Starten Sie es (am besten unter COMMAND) zunächst wie üblich mit STANDEV|Return|, im zweiten Versuch mit STANDEV >PRN:|Return .

Wenn Sie einen Drucker angeschlossen haben, sehen Sie den Text nun hier.

Im Programm 2 wird die „Datei“ CON: eröffnet und über die zugehörige (negative) Kanalnummer eine Testzeile ausgegeben. Hat dieses Programm den Namen CHARDEV. PRG, so werden Sie mit CHARDEV-Return oder CHARDEV >PRN:!Return; das gleiche Resultat erhalten. Character Devices stellen physikalische Kanäle dar und lassen sich nicht umschalten!

Wenden wir uns nun Beispielen zu, bei denen Daten „umgeleitet“ werden sollen, d. h. die Kanalzuordnung ist zu ändern.

Programm 3 tut zunächst nichts anderes, als das eingelesene Zeichen wieder auszugeben. Gelesen wird mit F_Read vom logischen Eingabekanal 0, geschrieben mit F__Write auf Ausgabekanal 1. Liegt die Standard-Kanalzuordnung von GEMDOS vor, so erscheint jedes eingetippte Zeichen doppelt: Einmal als Echo bei der Eingabe, zum anderen wegen F_Write.

Als Endezeichen für die Tastatureingabe wurde Ctrl-Z gewählt. Dieses Zeichen kann also nicht als Datenzeichen genutzt werden! F_Read übergibt die Anzahl der tatsächlich gelesenen Zeichen im Register DO. Wenn im Beispiel diese Zahl ungleich 1 ist - ein Zeichen sollte ja gelesen werden -, muß F_Read beim Datei-Ende angekommen sein. Das ist allerdings in der Praxis nur möglich, wenn die Zeichen wirklich aus einer „echten“ Datei kommen. Sie sehen, daß die Endebearbeitung beim Eingabekanal leider nicht ganz einheitlich ist. Manche Leute sprechen hier auch von ’Bugs’ im Betriebssystem.

Im Leicht abgeänderten Programm 4 wird der Ausgabekanal auf die Datei ERGEBNIS.DAT gelegt. Zunächst wird dazu die Datei über F___Create geöffnet. Danach wird die Funktion F__force angewendet, um die logische Kanalnummer 1 auf den Kanal der Datei ERGEBNIS.DAT zu schalten.

Im Programm 5 sind die zusätzlich notwendigen Zeilen enthalten, um auch noch den Kanal 0 (Eingabekanal) auf eine (existierende) Datei EINGABE.DAT zu schalten. In diesem Fall wird der schon erwähnte Test auf Datei-Ende bei F-Read wichtig!

Bei den beiden letzten Beispielen geht es darum, den logischen Ein- und Ausgabekanal jeweils auf eine Datei umzuschalten. Bei Programm 6 geht es „nur“ darum, den logischen Ausgabekanal auf den Drucker zu legen. Hier kommt zum ersten Mal F_Dup ins Spiel. Da der Drucker zunächst dem Protokollkanal zugeordnet ist, läßt man sich von GEMDOS unter Angabe von Kanal 3 die entsprechende physikalische Kanalnummer übergeben.

Mit dieser Nummer kann nun F_Force angewendet werden.

Wie man im laufenden Programm die ursprüngliche Kanalzuordnung wiederherstellt, demonstriert Programm 7. Nehmen wir an, nach einigen Ausgaben, die auf den Drucker gehen, soll nun der Ausgabekanal wieder zum Bildschirm geschaltet werden. Ein F_Force scheint hier angebracht - aber mit welchen Kanalnummern? Sowohl 3 als auch 1 zeigen zur Zeit auf den Drucker! Der Bildschirm ist nirgendwo mehr „angeklemmt“!

Man muß sich daher (mit F_Dup) vor der Umschaltung der Ausgabe eine physikalische Kanalnummer für CON: (Bildschirm) verschaffen. Mit dieser Nummer kann dann später mittels F_Force zum Bildschirm zurückgeschaltet werden.

Im Beispiel 7 wird nach der Rückschaltung ein Text auf den Bildschirm ausgegeben.

Letzte Bemerkung: Bei den Beispielen wird davon ausgegangen, daß vor dem Start die Standard-Kanalzuordnung von GEMDOS vorliegt (vgl. Tabelle)!

(H. Kersten)