Der Directorydruck

Bereits nach einer sehr kurzen Bekanntschaft mit meinem ST war mir klar - eins gefällt mir an dieser Kiste überhaupt nicht: Die unumgängliche Unordnung, die sich bereits bei dem Besitz von mehr als zwei Disketten in jeden Dateibestand einschleicht, läßt sich leider nur sehr unzureichend dokumentieren. So ist es, zur Dokumentation einer Diskette, die über mehrere Unterverzeichnisse verfügt, durchaus nicht befriedigend, eine Hardcopy jedes Unterverzeichnisses anlegen zu müssen, um ein wenig Übersicht über das Ganze zu erhalten. Mit der Zeit - und der Erwerbung einer Harddisk - stieg diese Unzufriedenheit ganz gewaltig, weshalb ich mich genötigt sah, ein entsprechendes Utility zu formulieren. Um im Dschungel der mittlerweile ungezählten Accessories gleicher Thematik nicht völlig unterzugehen, hält dieses Utility, eingebaut in unseren Lovely Helper, einige Leckerbissen für Sie bereit:

1. Zusätzlich zum Ausdruck des Hauptverzeichnisses kann optional der Ausdruck aller Unterverzeichnisse geschehen.
2. Die Sortierung erfolgt nach denselben vier Kriterien wie im Betriebssystem, also nach Name, Größe, Datum oder Typ.
3. Der Ausdruck geschieht über unsere Spoolerroutinen. Dadurch werden sämtliche, eventuell im Inhaltsverzeichnis enthaltene Sonderzeichen - etwa Umlaute -auch auf Ihrem Drucker korrekt wiedergegeben.

Die XENIX-Struktur des TOS

Punkt 1 - der Ausdruck aller Unterverzeichnisse - enthält dabei den interessantesten Algorithmus. Zu seinem Verständnis möchte ich etwas weiter ausholen. Stichwort ist die XENIX-Struktur des TOS. Gemeint ist damit die “Art und Weise”, wie unter TOS Dateien verwaltet werden, also Strukturierung von Dateien durch Unterverzeichnisse, die hierarchische Schachtelung derselben etc. Wie Sie vielleicht wissen, ist diese Struktur keine ATARI-spezifische Entwicklung, sondern fand bereits in vielen anderen erfolgreichen Betriebssystemen, wie etwa MS-DOS oder UNIX, Anwendung. Der Ursprung ist dabei ein XENIX genanntes Betriebssystem, wodurch sich die Bezeichnung erklärt. In einem derartigen Betriebssystem kann man sich nun alle Dateien einer Station in einer baumartigen Struktur organisiert denken (Abbildung 21). Die Wurzel des Baumes ist dabei das Hauptverzeichnis der Station und wird mit dem Zeichen ‘\‘ benannt. Anmerkung: Komischerweise stehen Bäume in der Informatik immer auf dem Kopf. Ich schließe mich dieser Konvention an. Wenn Sie die Wurzel suchen: Sie ist oben.

Das Hauptverzeichnis kann nun sowohl Dateien, als auch Unterverzeichnisse, im ST-Jargon auch Ordner genannt, enthalten. Mit den Ordnern verhält es sich genauso. Auch sie dürfen sowohl Dateien, als auch ihrerseits wieder Ordner enthalten. Auf einzelne Elemente des Dateibaumes, egal ob es sich dabei um Ordner oder Dateien handelt, greift man über die zugehörigen Pfadnamen zu. Vergleichen Sie dazu bitte auch Abbildung 21. Dargestellt ist ein Dateibaum mit sämtlichen zugehörigen Pfadnamen. Da diese Pfadnamen bei größeren Baumstrukturen, wie etwa auf einer Hard-Disk, mitunter recht lang werden, führt man, zwecks einfacherer Handhabung, noch den Begriff des aktuellen Ordners ein. Dieser Ordner ist unter sämtlichen Ordnern des Dateibaumes frei wählbar und kann jederzeit geändert werden. Zum Zugriff auf Dateien innerhalb des aktuellen Ordners braucht man nicht mehr den kompletten Pfadnamen anzugeben. Es genügt der einfache Dateiname. Auch Dateien “in der Nähe” des aktuellen Ordners lassen sich einfacher beschreiben als durch ihren kompletten Pfad. Gehen wir z.B. davon aus, daß wir uns im Ordner\TEIL.6\RSC innerhalb der Abbildung 21 befinden. Untenstehende Tabelle enthält dann jeweils zwei Dateinamen, die ein und dieselbe Datei innerhalb der Baumstruktur beschreiben.

Die Verwendung der beiden Punkte innerhalb der Pfadnamen bedeutet dabei soviel wie “Gehe einen Ordner im Dateibaum zurück!”. Damit ist es relativ bequem, auch an den äußeren Enden des Dateibaumes Dateien in unmittelbarer Nähe anzusprechen, ohne immer über den ganzen Pfad steigen zu müssen. Für unsere heutige Anwendung benötigen wir nun einen Algorithmus, der in einer “gewissen” Reihenfolge nacheinander jeweils alle Ordnereines Dateibaumes zu aktuellen Ordnern macht, um dann den jeweiligen Ordner auszudrucken. Die Arbeit läßt sich leicht in zwei Teile zerlegen:

1. Der Ausdruck des aktuellen Ordners
2. Der Durchlauf durch sämtliche Ordner des Dateibaumes, mit jeweiligem Aufruf von Punkt 1.

Ausdruck eines Ordners

Beginnen wir mit Punkt 1. Dazu ist es zunächst erforderlich, irgendwie an die Informationen, sprich Dateieinträge, des aktuellen Ordners heranzukommen. TOS stellt für diese Aufgabe die Disk-Transfer-Adress, kurz DTA, zur Verfügung. An diese Adresse schreibt TOS einen 44 Bytes großen Informationsblock, der sämtliche notwendigen Daten über eine Datei enthält. Das Format dieses DTA-Puffer können Sie der Abbildung 20 entnehmen (Innerhalb unserer Dateien, wurde der DTA-Puffer bereits in der Datei HILF.PAS - in der ersten Folge des Lovely Helper - deklariert.). Erster Bestandteil des Puffers ist ein Array aus 22 Bytes. Es enthält einige Organisations-Informationen für das Betriebssystem. Für uns wichtig ist nur das letzte Element dieses Arrays - reserviert[21]. Es enthält ein Bitmuster, das Aufschluß über den Dateityp der betrachteten Datei gibt. Alle sechs möglichen Belegungen dieses Bytes können Sie der Abbildung 20 entnehmen. Die nächsten beiden Informationen beziehen sich auf das Erstell- bzw. Modifikationsdatum der betrachteten Datei. Die beiden Variablen zeit und datum nehmen die entsprechende Information auf.

Da zur Speicherung beider Größen hier aber nur zwei Integer-Werte (2x16 Bit) verwendet werden, wird eine gewisse Interpretation der Größen notwendig. Wie Sie ebenfalls der Abbildung entnehmen können, sind die sechs Größen Tag, Monat, Jahr, Stunde, Minute und Sekunde auf folgende Weise gepackt:

Einer Erklärung bedürfen dabei die Werte für das Jahr und die Sekunde. Hier reicht nämlich der darstellende Bereich nicht für die Aufnahme sämtlicher möglicher Zustände aus. Der Bereich für Sekunde kann maximal 32 (25) Zustände annehmen, wodurch es nur möglich ist, jede zweite Sekunde zu zählen. Zu den Jahren ist immer der Offset 1980 hinzuzuaddieren, um die korrekte Jahreszahl zu erhalten. Auf diese Weise kann unsere ST Systemuhr maximal bis zum Jahre 2107 (1980 + 2^{7</sup - 1) Daten korrekt darstellen. Wohl mehr als ausreichend, selbst für den bis jetzt ziemlich zähen und langlebigen ST. Vierter Bestandteil des DTA-Puffers ist der Long_integer groesse. Er enthält die Länge der betrachteten Datei in der Einheit Byte. Letzter Bestandteil, der String name (dta_name = PACKED ARRAY [ 1.. 14] OF char), enthält den Namen der Datei. Er wird, wie im Betriebssystem üblich, mit CHR$(0) abgeschlossen. Die Adresse des DTA-Puffers verrät uns TOS mit dem Betriebssystemaufruf fgetdta (GEMDOS($2f)). Anmerkung: In der Regel liegt die DTA außerhalb des Bereichs der Pascal-Variablen. Deshalb ist p- als Compileroption unverzichtbar, sobald mit fgetdta gearbeitet wird. Bleibt die Frage, mit welchen Befehlen wir Daten in diesen DTA-Puffer bekommen. Dazu stellt TOS das Operationspaar fsfirst (GEMDOS($4e)) und fsnext (GEMDOS($4f)) zur Verfügung. fsfirst erhält als ersten Parameter einen Pfadnamen, im Betriebssystemformat, also cstring. Er darf auch Wildcards (’*’ und ’?’) beinhalten. Als weiterer Parameter wird ein Integer übergeben, der die Art der gesuchten Datei beschreibt. Das Format entspricht dabei dem des 22. Byte des DTA-Puffers (reserviert[21]).}

Zusätzlich können hier jedoch Kombinationen der sechs möglichen Zustände angegeben werden, indem man die entsprechenden Werte “verodert”. So entspricht ein Wert von $17 (folder | disk_label | hidden_sys | hidden | read_only | normal_file) für diesen Parameter, der Suche nach einem beliebigen Ordnereintrag. Berechnet wird von fsfirst ein Bool'scher Parameter, entsprechend dem Erfolg der durchgeführten Suche. War die Suche mit fsfirst erfolgreich, so stehen die genauen Informationen der aufgefundenen Datei automatisch im DTA-Puffer. Mit fsnext kann dann nach weiteren, zutreffenden Einträgen gesucht werden. Wird für fsfirst als Dateiname ’.’ angegeben und als Attribut $11 (normal_file | read_only | folder), so kann mit den nachfolgenden fsnext-Aufrufen ein komplettes Inhaltsverzeichnis erfragt werden. Dabei werden alle Dateien gefunden, die auch in den GEM-Windows angezeigt würden. Im Prinzip also sehr einfach, nämlich:

Umgesetzt in die Praxis benötigen wir nun jedoch noch einen ganzen Satz von Operationen, um eine maßgeschneiderte Ausgabe eines Ordners vorzunehmen (Listing 12, Zeilen 10-276). Die ersten beiden Prozeduren - inter_date und inter_time (Zeilen 10-30) - wandeln einen Integerwert, in einem der zwei Systemzeitformate, in jeweils drei Integerwerte, in normalem Format, um. Die Prozedur ausgabe_dta (Zeilen 32-82) erhält eine Variable dta im Format des DTA-Puffers. Sie druckt eine Zeile mit den entsprechenden Informationen aus. Benutzt werden dazu unsere Spoolerroutinen send_signal und send_string, sowie einige Routinen zuin Formatieren der beteiligten Variablen. Die eigentliche Arbeit aber erledigt Prozedur directory (Zeilen 99-276). Wir wenden uns zunächst ihrem Anweisungsteil (Zeilen 240-276) zu. Im ersten Teil (Zeilen 241-249) wird die DTA-Adresse und der Name des aktuellen Ordners ermittelt. Der Name des Ordners wird daraufhin ausgegeben. In den Zeilen 250-261 wird nun - mit dem Dateinamen - das komplette Ordnerverzeichnis zunächst von der Station gelesen und in einem Puffer (dta_puffer) abgelegt. Grund für dieses Vorgehen ist, daß wir fsfirst keine Sortierkriterien für die gesuchten Dateien mitgeben können. Wir haben also alle Informationen zuerst zu puffern und dann selber zu sortieren, bevor an die Ausgabe gedacht werden kann. Die Sortierung (Zeile 264) erfolgt mit dem bereits früher vorgestellten Quicksort (Zeilen 205-238). Es ist diesmal lediglich unserer Problematik angepaßt worden.

Größte Schwierigkeit war dabei die Wahl einer zutreffenden Relation zur Anordnung der Dateien. Relation rel (Zeilen 115-203) leistet das Gewünschte. Hier wird zunächst berücksichtigt, welcher Art das Sortierkriterium ist. Zur Verfügung stehen Name, Zeit, Größe und Typ. Daraufhin erfolgt die prompte Auswertung der entsprechenden (Teil-)Relation. Nach diesem Sortiervorgang wird nun nur noch der Puffer, durch mehrfachen Aufruf von ausgabe_dta, ausgegeben.

Ein wenig Rekursion x_directory

Kommen wir nun zu der Prozedur, die ein komplettes Stationsverzeichnis erstellt - x_directory (Zeilen 278-348). Bis auf die Ausgabe der eingeschachtelten Ordner, sowie ein wenig Randinformation - Stationskennung und Stationsbelegungsgrad ermitteln und ausgeben -, hat x_directory nur einen Durchlauf durch den Dateibaum durchzuführen. Dies geschieht in der rekursiven Prozedur dfs, Zeilen 285-311. Benutzt wird hier im Wesentlichen der Betriebssystemaufruf dsetpath (GEMDOS($3b)) im Zusammenwirken mit fsfirst und fsnext. Begonnen wird der Durchlauf im Hauptverzeichnis ‘\‘ (Die Initialisierung dazu erfolgt noch in x_directory selber (Zeilen 315-317)). dfs gibt nun zunächst das komplette Hauptverzeichnis aus und ermittelt dann mit fsfirst und fsnext sämtliche verzeichneten Ordner im aktuellen Verzeichnis. Dabei erfolgt jeweils ein rekursiver Aufruf mit dem entsprechenden Ordnernamen, sowie ein Rücksprung mit dem Pfadnamen ’..’ (Ordner zurück) nach erfolgter Rekursion. Besondere Bedeutung kommt dabei den reservierten Bytes des DTA-Puffers zu. In Ihnen wird nämlich vermerkt, inwieweit mit fsfirst und fsnext ein Ordner bereits durchwandert ist. Durch die rekursiven Aufrufe - und damit andere Belegungen des DTA-Puffers - wird diese Information überschrieben. Beim Durchlauf würde dies bei der Unterlassung von Gegenmaßnahmen dazu führen, daß immer wieder in den ersten Ordner hineingestiegen wird: Eine Endlosschleife, über die sich besonders der Drucker freut. Eine einfache Gegenmaßnahme, die keinerlei Information über die genaue Struktur der reservierten Bytes erfordert, ist die komplette Sicherung des DTA-Puffers in einer Variablen copy (Zeile 303). Nach dem rekursiven Aufruf, kann dann auf sehr einfache Weise - Zuweisung von copy an den DTA-Puffer - der ursprüngliche Zustand wieder hergestellt werden. Für Insider: Das, was wir gerade gemacht haben, ist an sich nichts weiter, als ein Preorder-Durchlauf durch den Dateibaum, mit der Knotenoperation “directory”.

Denkbar sind durchaus auch andere Knotenoperationen: Ersetzen wir etwa directory, sowie Ihre Aufrufe durch die Operation, die im Listing auf der vorigen Seite zu sehen ist, so erhalten wir - wird das Ganze mit dfs in ein separates Programm eingebunden - eine Routine, die in größeren Dateibeständen bestimmte Dateien sucht. Enthält compare beispielsweise den Wert ‘*.PAS‘ so werden sämtliche Pascal-Dateien mit ihrem kompletten Pfadnamen ausgegeben. Zumindestens in UNIX, mittlerweile aber auch auf dem ST, habe ich das immer sehr nützlich gefunden.

Tab. 1: Objekte der Abb. 22

Wieder ein wenig GEM

Nach diesem Ausflug in die Welt der Betriebssysteme, ist nun noch das Bindeglied zwischen den bis jetzt vorgestellten Operationen und unserem Lovely Helper zu formulieren. Benutzt wird der Dialog DIRECT. Abbildung 22. Tabelle 1.

Der einzige Text dieses Dialoges - TDIRECT - dient dabei dazu, daß aktuelle Sortierkriterium anzuzeigen. Die vier darunter befindlichen Feldtasten dienen der Selektion dieses Kriteriums. Die Taste BNORMAL ermöglicht den Ausdruck eines normalen (nicht rekursiven) Hauptverzeichnisses. Entsprechend leitet BREKURSI die rekursive Variante ein. BABBDIRE letztendlich dient dem Abbruch des DIRECT-Dialoges. Anmerkung: Beachten Sie bitte auch, daß für das heutige Resource - - DIRECT.RSC - wieder die beiden Dialoge PARAMETE und SYNCHRO benötigt werden, damit die Druckerparameter eingestellt werden können. Die Dialogverwaltung (do_direct, Zeilen 350-391) ist, wie schon der Dialog, sehr schlicht. In der REPEAT-Schleife, die die Dialogausführung einschließt (Zeilen 360-377), wird vor do_dialog der Text TDIRECT initialisiert.

Nach do_dialog wird zwischen den vier Feldtasten, zur Wahl des Sortierkriteriums, und den restlichen drei Feldtasten unterschieden. Bei Wahl einer der vier Tasten für die Sortierkriterien, wird nur der entsprechende Parameter (default sort) umgesetzt und der Dialog wiederholt. Bei Wahl einer anderen Taste wird die Schleife verlassen; es erfolgt eine abschließende Auswertung. In dieser Auswertung ist zunächst, wie schon in der letzten Folge, zu prüfen, ob der Drucker nicht vielleicht bereits für unseren Spooler arbeitet (spoolstatus = unused). Ist diese Bedingung erfüllt - wir stören den Spooler nicht -, so ist nur noch zwischen einem rekursiven Inhaltsverzeichnis (BREKURSI) und einem einfachen Hauptverzeichnis (BNORMAL) zu unterscheiden und in die entsprechende Prozedur zu verzweigen.

Das Accessory DIRECT

Die Accessory-Verwaltung von DIRECT.ACC (Listing 13) hält nun nichts Aufregendes mehr für uns bereit. Die Möglichkeit mehrere Menüleisten von einem Accessoire aus zu belegen, hatten wir bereits beim letzten Mal kennengelernt. Ach ja: Die Definition von bundesland in den Zeilen 19-21. Ein kleiner Pfusch! Da die Parameterverwaltung auch das Bundesland für unser ZEIT.ACC zu verwalten hat, ist diese Deklaration in Listing 13 aufzunehmen, um die Datei SPOOLER1.PAS unverändert einbinden zu können. So! Für heute bin ich damit wieder einmal am Ende (meiner Ausführungen). Als letztes möchte ich Ihnen noch Abbildung 23 präsentieren: Das Resultat unserer heutigen Bemühungen, angewendet auf eine meiner Datendisketten zum Lovely Helper.

Vorausschau

Beim nächsten Mal wird Sie ein naturwissenschaftlicher Taschenrechner erwarten, der es schon ein bißchen in sich hat. Er verfügt über:

• Punkt-vor-Strich-Rechnung
• Klammerung (die zulässigen Klammerebenen können Sie selbst bestimmen)
• Die wichtigsten naturwissenschaftlichen Funktionen (sin, cos, tan, ln, ... ) und ihre Umkehrungen
• Die trigonometrischen Funktionen können in allen, geläufigen Einheiten (DEG, RAD und GRAD) durchgeführt werden

Mal wieder was ganz und gar Theoretisches und nicht wie heute aus dem Sumpf der Betriebssystemprogrammierung, ln der Hoffnung, daß Ihnen diese Wechselkost gut bekommt, verbleibe ich bis dahin.