Atarium: Neues von der MiNT-Front

Kurz vor der CeBIT erreichten uns neue Versionen von MiNT und den Bibliotheken. Außerdem stellen wir einige der weniger bekannten (da relativ neuen) Funktionen vor.

MiNT selbst trägt jetzt die Versionsnummer 1.04. Der Sprung in der Versionsnummer deutet übrigens nicht auf besonders radikale Veränderungen, sondern nur auf eine Änderung der Zählweise hin. Weitere geringfügige Fehlerbeseitigungen und Optimierungen: Auf Maschinen ohne PMMU wird in der Speicherverwaltung wieder eine erheblich kleinere Seitengröße benutzt. Und schließlich kann man nun durch Umbenennen der Programmdatei (in »MINTNP.PRG«) den Speicherschutz ausschalten. Wie schon beim letzten Sourcecode-Release darf auch diese Fassung ausschließlich als Quelltext weitergegeben werden. Damit soll erreicht werden, daß diese Betaversion nur von erfahrenen Programmierern zu Testzwecken eingesetzt wird. Wer lediglich an dem ausführbaren Kernel interessiert ist, wird in der mitgelieferten README-Datei dazu aufgefordert, ein vollständiges MultiTOS-Release zu kaufen - hoffen wir, daß das auch bald möglich sein wird.

Neu ist das Patchlevel 30 der MiNT-Libraries. Neben etlichen Detailverbesserungen und Fehlerkorrekturen wurden auch die TOS-Bindings in Hinsicht auf »Falcon« und MiNT aktualisiert. Besonders interessant ist dabei die Datei »falcon.h«, da hier Ataris besonders schlecht gewählte Namen für die neuen XBIOS-Videofunktionen nicht übernommen wurden (vgl. auch [1]).

Ein Thema, bei dem offensichtlich nach wie vor erheblicher Erklärungsbedarf besteht, ist die Handhabung fremder Dateisysteme und langer Dateinamen. Bereits im letzten Jahr haben wir ausführlich über die neuen Verzeichnisfunktionen berichtet ([2,3]). Diesen Monat gehen wir noch einmal ausführlich auf die Auskunftsfunktion »Dpathconf()« ein. Unsere Tabelle zeigt eine Übersicht über die von »Dpathconf()« für die verschiedenen Dateisysteme zurückgelieferten Daten. »files« gibt an, wieviele Dateien gleichzeitig geöffnet sein dürfen (von dem prozeß-internen Limit abgesehen).

Für TOS-Dateisysteme sind dies 60 Dateien, im Wurzelverzeichnis von »U: \ « gibt es gar keine echten Dateien, und woanders gibt es keinerlei interne Beschränkungen. Die nächste Spalte gibt an, wieviele »links« (siehe [2] und [3]) pro Datei existieren können. Man sieht, daß dies zur Zeit nur vom Minix-Dateisystem unterstützt wird.

»path_max« zeigt, wie lang komplette Dateinamen (inkL Pfad) auf dem Dateisystem werden können. Im Moment wird überall »128« angegeben, was natürlich nicht so bleiben muß. »Moderne« Programme können hier flexibel die benötigten Größen für interne Puffer erfragen. »name_max« steht für die maximale Länge eines Dateinamens. Bei TOS-Dateisystemen ist das 12 (acht plus drei Zeichen und der Punkt), bei anderen Verzeichnissen ist es anders (vermutlich hat Eric Smith hier aus »erzieherischen« Gründen soviele verschiedene Formate gewählt). Unter »atomic« ist angegeben, wieviele Bytes »in einem Rutsch« geschrieben werden können. In »u:\dev« - also bei den zeichenorientierten Geräten - ist dies logischerweise 1.

Besonders wichtig ist die Spalte »trunc«, die Informationen darüber enthält, auf welche Art und Weise zu lange Dateinamen abgeschnitten werden. Mögliche sind dabei »auto« (überstehende Zeichen werden abgeschnitten), »no« (zu lange Dateinamen werden mit Fehlermeldung zurückgewiesen) und »8+3« (Dateinamen werden nach DOS-Konventionen verstümmelt). Schließlich kann man unter »case« erfahren, ob und auf welche Weise Dateinamen mit gemischter Groß/Kleinschreibung unterstützt werden. Dabei gibt es nicht nur die Möglichkeiten »no« (TOS-Dateisystem) und »yes« (Minix-Dateisystem), sondern auch »pres« (für preserved): auf solchen Dateisystemen werden zwar die Namen mit gemischter Groß- und Kleinschreibung gespeichert, diese Unterschiede beim Zugriff auf Dateien aber nicht beachtet (es kann also beispielsweise nicht gleichzeitig »Makefile« und »makefile« geben).

Damit ist auch klar, daß Programme nicht mehr fahrlässig groß- und kleingeschriebene Dateinamen vermischen sollten. Folgende Faustregeln sollte man immer beachten: Dateinamen und -pfade immer genauso weiterverwenden, wie sie vom Betriebssystem geliefert worden sind (es sei denn, man hat sich mit »Dpathconf()« darüber informiert, daß es in dem betreffenden Verzeichnis wirklich keine Rolle spielt). Dateinamen grundsätzlich klein schreiben (auf Dateisystemen mit gemischter Groß- und Kleinschreibung sind großgeschriebene Dateinamen eher die Ausnahme!). In diesem Zusammenhang ebenso wichtig: Die GEMDOS-Funktion »Dgetpath()« hat den bekannten Designfehler, daß GEMDOS nicht wissen kann, wie lang der übergebene Puffer tatsächlich ist. Auch wenn man dort einen »großen« String übergibt (viele Programmierer halten 64 Zeichen für genug, was sich unter Umständen als schrecklicher Fehler erweisen kann), kann man nie sicher sein, daß der Platz auch wirklich reicht. Die neue MiNT-Funktion »Dgetcwd()« (Opcode 316) funktioniert genauso, nur wird als zusätzlicher WORD-Parameter die Länge des Puffers übergeben. Bei extrem langen Pfadnamen bleibt der Speicher hinter dem Puffer (stattdessen erhält man eine Fehlermeldung). Konservative Programmierer halten längere Dateinamen oft für unnötig oder für zu kompliziert. Von den offensichtlichen Vorteilen wie aussagekräftigere Dateinamen und POSIX-Standard abgesehen, gibt es eine ganze Reihe weiterer Gründe, die für die Anpassung an die neuen Verhältnisse sprechen: In einer Zeit, in der der freie Datenaustausch eine immer größere Rolle spielt, wird ein Computersystem, das in dieser Hinsicht unflexibel ist, seinen Benutzern in Zukunft nur wenig Freude machen. Was, wenn »OS/2«- und »Windows-NT«-Benutzer in wenigen Jahren damit beginnen, die neuen Dateisysteme (natürlich mit langen Dateinamen) nicht nur auf Festplatten, sondern auch auf Disketten einzusetzen? Auch die CD-ROM-Dateisysteme beginnen die 8+3-Hürden zu überwinden (Stichwort: Rockridge-Erweiterungen des ISO-Datei-Systems). Warum sollte man auf dem Atari daran nicht teilhaben? Was, wenn der Atari in einem Netzwerk mit »UNIX«-, »OS/2«- oder »Mac«-Systemen arbeiten soll? Will man dann wirklich mit verstümmelten Dateinamen arbeiten? Ich denke nein. Für die meisten Anwendungsprogramme sind die Änderungen eher unbedeutend. (uw)

Quellennachweis:
[1] Alexander Herzlinger: „Das Videosystem des Falcon 030«, ST-Magazin 1/1993, Seite 18
[2] Julian F. Reschke, »Acht plus drei ist zu wenig«, ST-Magazin 7/1992, Seite 70
[3] Julian F. Reschke, »Atarium-08.92.doc«, ST-Magazin 8/1992, Seite 50

Übersicht über Dateisystembeschränkungen