Grundlagen: Programmieren unter MiNT/MultiTOS, Teil 2

Sehr zur Freude der UNIX-Fans nähert sich die Verwaltung von Dateien unter MiNT immer mehr der Vorgehensweise von UNIX an. Da auch die anderen Betriebssystemaufrufe von MiNT eng an UNIX angelehnt sind, Wird es für Atari-Anwender erheblich einfacher, aus dem riesigen Pool von freier UNIX-Software zu schöpfen.

Als Ken Thompson 1969 in den Bell Labs mit der Entwicklung eines neuen Betriebssystems begann, war die Zeit der Lochkarten und Lochstreifen noch lange nicht vorbei. Der Programmierer mußte seine Arbeit beim Operator abgeben, der fütterte den Rechner damit und nach einigen Stunden (oder auch Tagen) konnte der Programmierer sich die Ergebnisse wieder abholen. Verständlicherweise erweckte dieses Vorgehen den Wunsch nach einem interaktiven Betriebssystem, an dem mehrere Programmierer gleichzeitig im Dialog an einem Problem arbeiten können. Es gab zu dieser Zeit bereits ein Betriebssystem, das diesen Forderungen schon recht nahe kam. Leider hatte dieses MULTICS noch einige Haken, war ein regelrechter Dinosaurier und lief, wegen der enormen Ansprüche an den Speicher und die CPU, nur auf den größten und somit auch teuersten Rechnern. Ken Thompson hatte aber nur eine PDP-7 (ein Kleinrechner von DEC) zur Verfügung und auf diesem entstand die erste Version von UNIX. Dieser Name ist eigentlich eine »Verballhornung« von MULTICS!

Die erste Ausgabe war noch vollständig in Assembler geschrieben, da aber etwa zur gleichen Zeit in den Bell Labs die Programmiersprache C entstand, lag der Gedanke nahe, das System in dieser Hochsprache zu realisieren. Dies geschah im Jahre 1971 auf einer PDP-11. Damit war UNIX endgültig geboren. Eigentlich war dieses System überhaupt nicht für den kommerziellen Markt gedacht, aber da Beil den UNIX-Quellcode kostenlos an Universitäten und Hochschulen abgab, verbreitete es sich sehr schnell auf diversen Rechnern. Eine der großartigsten Neuheiten von UNIX war (und ist) sein Dateisystem. UNIX betrachtet beinahe alle wichtigen Dinge eines »Betriebssystemlebens« als Dateien in einem großen Dateisystem. Wer Zeichen auf dem Bildschirm ausgeben möchte, der schreibt diese einfach in die Datei »dev/console«, den Drucker findet man unter »dev/lp«, das Terminal unter »dev/tty« usw. Auch die einzelnen Speichermedien sind lediglich Unterverzeichnisse im Dateisystem.

Wer einmal das Laufwerk »U:« unter MiNT näher betrachtet, findet genau dieses Konzept. In »U:« sind alle anderen Laufwerke (und mehr) als Ordner enthalten. Damit läßt sich die Datei »DESKTOP.INF« nicht nur unter »C:\DESKTOP.INF«, sondern auch unter »U:\C\DESKTOP.INF« finden. Auf den ersten Blick bringt dieses Vorgehen keine besonderen Vorteile, aber für den Programmierer erleichtert es die Sache enorm. Wenn man eine Operation in allen Laufwerken ausführen will (z.B. Datei suchen), muß man nicht mehr die vorhandenen Laufwerke abfragen und dann jedes einzeln bearbeiten, es genügt das Laufwerk » U:«! Auch bleiben Programme damit unabhängiger von der Hardware. Wer hat nicht schon über ein Programm geflucht, das partout nur auf einem bestimmten Laufwerk funktioniert? Nebenbei bemerkt, Besitzer von großen Festplatten mit vielen Partitionen werden es auch zu schätzen wissen, daß nur noch ein Icon auf dem Desktop herumliegen muß. Für Programme unter MiNT (und MultiTOS) sollte daher die Regel gelten: nicht direkt auf die Laufwerke zugreifen, sondern über »U:«. Dort finden sich aber nicht nur alle anderen Laufwerke wieder, es enthält auch noch einige Ordner (vgl. Bild 1).

»U:\PIPE« enthält Dateien, die FIFO (first in, first out) Pipes sind. Achtung, diese Dateien sind temporär! Will sagen, wenn das letzte Programm, das eine Pipe benutzt, die Datei schließt, wird sie gelöscht. Über diese Pipes lassen sich Nachrichten und Daten zwischen Prozessen austauschen. Die Programme »MW« und »TOSWIN« bewachen die Pipe »TOSRUN«. Schreibt man in diese den Namen eines ausführbaren TOS-Programmes, startet MW/TOSWIN es, und die Applikation läuft dann im Fenster.

»U:\PROC« ist ein Abbild des Systems, die Dateien symbolisieren die einzelnen Prozesse. Das Löschen einer dieser »Dateien« beendet auch den zugehörigen Prozeß. Das Löschen von MiNT ist nicht möglich und wer GEM löscht, ist selber schuld! Generell sollte man Prozesse nur im äußersten Notfall auf diese rüde Weise beenden, da manche sehr »sauer« darauf reagieren. Auch ist das Löschen nicht der eigentliche Sinn und Zweck von »U: \PROC«, denn anhand dieser Dateien kann man noch eine Menge interessanter Dinge über die aktuellen Prozesse erfahren (siehe Funktion get_proz() in PS_CONTR.C). Die Namen der »Dateien« setzen sich aus dem Prozeßnamen und der Prozeß-ID zusammen (z.B. »PS_CONTR.006«). Prozesse lassen sich auch umbenennen, allerdings ersetzt das System die Extension immer durch die ID. Die Größe einer »Datei« ist die Speicherplatzmenge, die dem jeweiligen Prozeß zugeteilt ist. Der Zeit- und Datum-Eintrag zeigt ab MiNT 0.95 an, wann der Prozeß gestartet wurde. Den Status eines Prozesses geben seine Attributbits an:

»U:\DEV« enthält die BIOS-Gerätetreiber. Auf diese »Gerätedateien« kann man auch aus Programmen zugreifen. Das Speichern einer ASCII-Textdatei unter »U:\DEV\PRN« bewirkt die Ausgabe auf dem Drucker. Natürlich klappt das nur mit ASCII-Daten, da keinerlei Steuerzeichen interpretiert werden. Folgende Gerätetreiber sind vorhanden:

Ab MiNT 0.95 existiert noch das Verzeichnis »U:\SHM«. In ihm stehen »Dateien«, die Shared-Memory-Bereiche symbolisieren. Über dieses Feature teilen sich mehrere Programme einen Speicherbereich. Damit ist z.B. eine sehr schnelle Kommunikation unter Prozessen möglich. Auch für dieses Bonbon ist der Sinn nicht auf den ersten Blick zu erkennen, es war auf dem Atari ja schon immer möglich, daß Programme gegenseitig auf ihren Speicher zugreifen. Leider (bzw. Gott sei Dank) führt die bisherige Vorgehensweise am Betriebssystem vorbei und spätestens auf einem Multitasking-System mit Memory-Management-Unit (MMU) zu bombigen Problemen.

An den Dateieinträgen in »U:\SHM« lassen sich noch weitere Dinge erkennen: Die Größe der »Datei« zeigt die Größe des geteilten Speicherblocks an. Für Programme, die im MiNT-Modus auf dieses Verzeichnis zugreifen, gelten die üblichen Namenskonventionen (12345678.123) für Dateinamen nicht mehr. Der Dateiname kann aus bis zu 15 Zeichen bestehen; wo (bzw. ob überhaupt) ein Punkt sitzt, ist egal.

Da der UNIX-Macher Ken Thompson wahrscheinlich ein sparsamer Mensch ist, hatte er noch eine weitere hervorragende Idee. Wenn man eine Datei oder ein ganzes Unterverzeichnis an verschiedenen Stellen des Dateisystems benötigt, mußte man sie kopieren und verschwendete teuren Platz auf der Festplatte. Außerdem ist so nie gewährleistet, daß diese Dateien auch immer exakt den gleichen Inhalt haben. Unter UNIX gibt es für dieses Problem die sogenannten »Links«. Ein Link ist ein Verweis auf eine Datei bzw. ein Verzeichnis an einer anderen Stelle des Dateibaums.

Mit der Funktion flink() lassen sich Hard-Links auf einem Laufwerk setzen. Unter aktuellen MiNT-Versionen wird im Directory ein Eintrag angelegt, der auf die Originaldatei verweist. Ohne MiNT gibt es daher praktisch keine Möglichkeit, einen Hard-Link von der Originaldatei zu unterscheiden. Egal welche Datei gelöscht wird, das Original oder der Hard-Link, die Daten sind futsch. Wie unter älteren UNIX-Versionen funktioniert das aber wirklich nur auf einem physikalischen Laufwerk, es kann kein Link von einem Laufwerk zum anderen gelegt werden. Aber keine Panik, MiNT stellt auch globale Links zur Verfügung. Diese symbolischen Links (auch ein UNIX-Werk, aber aus der Berkeley-Richtung) können in den aktuellen MiNT-Versionen nur das Laufwerk U: zum Ziel haben. Mit der Anweisung »sln c:\mint\bin u:\bin« in MINT.CNF steht der Ordner »c:\mint\bin« ab sofort auch als »u:\bin« zur Verfügung. Löscht man diesen Soft-Link, ist das nicht weiter tragisch, da wirklich nur der Link verschwindet.

Im Gegensatz zu TOS und MS-DOS kennt UNIX keine FAT. Dateisysteme unter Standard-UNIX verwenden hingegen eine i-node Liste, in der alle Dateien verzeichnet sind. Jede Datei hat genau einen »i-node«. Damit ist auch klar, daß nur soviele Dateien Platz haben, wie i-nodes in der Liste vorhanden sind. Ist ein i-node belegt, enthält es alle Attribute, die einer Datei fest zugeordnet sind. In den Verzeichnissen des Dateisystems stehen nun praktisch nur noch die Dateinamen und die Nummer des dazugehörigen i-nodes. Neben den Attributen enthält der i-node auch noch 13 Einträge mit Verweisen auf Blöcke mit dem Dateiinhalt. Da unter UNIX die einzelnen Blöcke meistens 512 oder 1024 Bytes groß sind, wäre die maximale Dateigröße auf 13 * Blockgröße beschränkt. Mager, nicht? Damit nun die Dateien munter wachsen können, zeigen nur die ersten zehn Einträge direkt auf Blöcke mit Datei-Inhalten, der elfte Eintrag zeigt auf einen Block, in dem wiederum bis zu 128 Verweise stehen. Reichen 10+128 Blöcke noch nicht aus, dann steht im zwölften Eintrag der Verweis auf einen Block, der 128 indirekte Verweise auf Blöcke mit jeweils wieder 128 direkten Verweisen enthält. Schon verwirrt? Na dann nehmen wir uns den 13. Eintrag vor: Dort steht ein Verweis auf einen Block, der 128 indirekte Verweise auf Blöcke enthält, die 128 indirekte Verweise auf Blöcke enthalten, die wiederum 128 direkte Verweise auf Blöcke mit dem Datei-Inhalt enthalten. Ist Ihnen schwindelig? Alles in allem kommen wir damit auf eine maximale Dateigröße von 10+128+128x128+128x128x128 Blöcken à 512 bzw.1024 Bytes, das macht circa ein bis zwei Gigabyte (vgl. Bild 2). Was zum Teufel hat dieses verwirrende Konstrukt nun mit MiNT zu tun? Nun ja, MiNT versucht eben dieses i-node-Konzept nachzubilden bzw. es auf das FAT-System aufzupfropfen. Wer ein Verzeichnis mit der MiNT-Funktion Dopendir() im MiNT-Modus öffnet und die Einträge mit Dreaddir() liest, der erhält in den ersten 4 Bytes des Puffers die i-node-Nummer der Datei mitgeteilt. Wahrscheinlich wird sich MiNT und damit MultiTOS im Laufe der Zeit immer weiter von der FAT in Richtung i-node entwickeln. (ah)