Atarium - Neues von MiNT, MetaDOS, Gemini, NVDI und Speedo

In der letzten Ausgabe habe ich etwas überoptimistisch eine neue Version von MiNT in Aussicht gestellt. Leider ist daraus nichts geworden, da Eric Smith offenbar noch immer keinerlei Zeit von der Jaguar-Spieleentwicklung abzwacken kann. Damit dürfte auch klar sein, daß alle Gerüchte um neue TOS- oder MultiTOS-Versionen zur Zeit jeder Grundlage entbehren.

Wie wird MiNT 1.11 aussehen? Im Moment basteln einige Entwickler an Erweiterungen und Fehlerkorrekturen, und es sieht ganz so aus, als würde Eric diese Erweiterungen weitestgehend übernehmen.

Einige wichtige Punkte im Überblick:

MetaDOS 2.4

Was es tatsächlich gibt, ist eine neue Version von MetaDOS (2.40, als METADS24.ZIP in Mailboxen zu finden). Außer einigen Fehlerkorrekturen (beim Programmstart zum Beispiel) hat man die interne Treiberschnittstelle so erweitert, daß DOS-Treiber nun auch einen Teil der MiNT-Funktionen implementieren können. Im einzelnen sind dies: Dclosedir(), Dcntl(), Dopendir(), Dpathconf(), Dreaddir(), Drewinddir(), Dxreaddir(), Fcntl() und Fxattr().

Achtung: diese Erweiterungen werden - von einer Ausnahme abgesehen - von ATARIs mitgeliefertem DOS-Treiber nicht benutzt. Unterstützt wird lediglich Dcntl(), das direkt per Metaioctl() an den entsprechenden BOS-Treiber weitergeleitet wird (siehe [1]). Autoren von Meta-DOS-Treibern haben damit erstmalig die Möglichkeit, lange Dateinamen zu unterstützen. Abbildung 1 zeigt das Verzeichnis einer CD im Rockridge-Format (einer Erweiterung des ISO-Formats) im Gemini-Verzeichnisfenster, geliefert von einem noch experimentellen DOS-Treiber.

Damit gibt es nun das erste System, das gewisse MiNT-Aufrufe unterstützt, ohne daß wirklich MiNT installiert sein muß und ohne daß der MiNT-Cookie vorhanden wäre. Weitere Systeme - beispielsweise das nächste „große“ Release von „MagiC“ (vormals „MagiX!“) - werden zweifellos folgen.

Abbildung 1: eine CD mit Rockridge-Daleisystem

Daher ist es wichtiger denn je, aus Programmen explizite Abfragen auf MiNT und MiNT-Versionsnummern zu entfernen! Das Vorhandensein einer MiNT-Funktion erkennt man daran, daß sie als Rückgabewert nicht EINVFN(-32) liefert!

Doch damit nicht genug: unter MetaDOS sind manche dieser Funktionen auf bestimmte Laufwerke anwendbar, auf andere hingegen nicht [nur weil der Meta-DOS-Treiber für das CD-ROM Dopendir() unterstützt, gilt das natürlich noch lange nicht Für die Festplattenpartitionen]. Daher sollte man bei Verwendung der Verzeichnisfunktionen folgende Faustregel im Kopf behalten: Wenn Dopendir() für das Verzeichnis klappt, dann mit „ausreichend“ großer Wahrscheinlichkeit auch Dreaddir(), Drewinddir(), Dclosedir() und Fxattr(). Anderenfalls muß man Fsfirst()/Fsnext() verwenden. Damit kommt man auf maximal einen „überflüssigen“ Aufruf von Dopendir() pro Verzeichnis, was sicherlich zu tolerieren ist.

Eine neue Funktion wurde bereits oben erwähnt: Dxreaddir(). Ein Kritikpunkt an den bisherigen MiNT-Funktionen war immer, daß man Für die gleiche Funktionalität doppelt so viele Aufrufe [nämlich Dreaddir()/Fxattr() anstelle von Fsnext()] brauchte. Dies hatte natürlich den Grund, daß man in einem Unix-System grundsätzlich zwischen dem Verzeichniseintrag und der Datei selbst unterscheiden muß und die für Fxattr() benötigten Daten im allgemeinen nicht im Verzeichniseintrag stehen (sondern im „Inode“).

Das Aufrufpaar Dreaddir()/Fxattr() kann allerdings aufgrund der übergebenen Parameter nicht schnell sein, da der bei Fxattr() übergebene Pfadname erst wieder neu aufgelöst werden muß. Und auch dann, wenn es diesen Overhead nicht gäbe, wäre ein Aufruf immer schneller als zwei.

Ergebnis dieser Überlegung ist die neue Funktion Dxreaddir() (GEMDOS-Opcode 0x142), die in einem Rutsch den Verzeichniseintrag und die XATTR-Struktur zurückliefert (siehe Kasten). Es spricht sicherlich für das MiNT-Treiber-Interface, daß diese Funktion vollständig vom Kernel behandelt werden kann und sich für die Dateisystemtreiber (XFS) nichts ändert. Wegen MetaDOS gilt auch für diese Funktion: es kann sein, daß sie auf manchen Verzeichnissen verfügbar ist und auf manchen nicht. Dies läßt sich natürlich ebenfalls durch einen einmaligen Testaufruf innerhalb des Verzeichnisses feststellen.

Gemini

Neues gibt es auch von Gemini 2 zu berichten (siehe [2]): Es ist nun in der Version 1.999 verfügbar (GMNI1999.TOS in gutsortierten Mailboxen). Die Änderungen beschränken sich größtenteils auf Fehlerbehebungen und kleine Erweiterungen in der Mupfel. Das Archiv enthält nun Manual-Pages zu allen internen Mupfel-Kommandos sowie eine vorläuFige Manual-Page zur Mupfel selbst.

Neues von Speedo und NVDI

Schließlich und endlich gibt es auch zum Thema GDOS Neuigkeiten: Weder Compo noch die NVDI-Autoren Sven & Wilfried Behne wollten sich mit dem aktuellen Stand von SpeedoGDOS zufriedengeben. Letzten Monat kündigten beide Hersteller neue Produkte an, die zu Redaktionsschluß aber noch nicht in endgültigen Versionen vorlagen (Abbildung 2 zeigt Bildschirmausgaben einer NVDI-Testversion). Beide nehmen sich der bekannten Kritikpunkte an SpeedoGDOS an: (1) Es könnte schneller sein; (2) die „Grundversorgung“ mit Speedo-Schriften ist zwar gesichert, aber aufgrund des Schriftenmonopols von Bitstream ist es schwer, an günstige „einfache“ Schriften oder ausgefallene Designer-Schriften zu kommen.

Zwei andere Schriftformate bieten sich an: einerseits PostScript-Schriften, die jahrelang auf dem Mac dominierend waren und auf Windows, OS/2 und Macintosh per „Adobe Type Manager“ benutzt werden konnten. Andererseits gibt es das gemeinsam von Apple und Microsoft unterstützte „TrueType“-Format, das heute unter Windows und auf dem Mac am weitesten verbreitet ist und von Windows 3.x bzw. System 7.x direkt unterstützt wird. Tatsache ist auf jeden Fall, daß es bei beiden Formaten eine riesige Auswahl an Schriften gibt.

Abbildung 2: NVDI 3 macht's möglich: Speedo und TrueType-Schriften einträchtig vereint.

Bei Speedo 5 (Compo) handelt es sich um eine Weiterentwicklung von ATARIs SpeedoGDOS, die nicht nur zusätzlich TrueType- und PostScript-Schriften benutzen kann, sondern vermutlich auch schneller sein wird. Beim ohnehin schnellen NVDI hingegen wurden für Version 3.0 Schriftskalierer für Speedo- und True-Type-Schriften eingebaut. Die NVDI-Autoren argumentieren, daß jeder zusätzliche Skalierer Speicherplatz belegt und ohnehin mehr Schriften im True-Type-Fonnat erhältlich sind. Da beide Firmen die „Fontengines“ der Firma Bitstream verwenden, darf man gespannt sein, inwiefern sich die Ergebnisse in Hinsicht auf Qualität und Geschwindigkeit unterscheiden. Es bleibt also interessant!

Quellennachweis:

[1] Julian F. Reschke: „Audioprogrammierung per Dcntl(), ST-Computer 7-8/94, Seite 77

[2] Julian F. Reschke: „How to Gemini“, ST-Computer 4/94, Seite 78

Definition der GEMDOS-Funktion Dxreaddir()

LONG Dxreaddir (WORD In, LONG dirh, char *buf, XATTR *xattr, LONG *xr);

Dxreaddir() liefert die nächste Datei aus dem per Directory-Handle „dirh“ angegebenen Verzeichnis zurück [das Directory-Handle muß mit Dopendir() ermittelt worden sein]. Der Dateiname und der optionale vier Bytes große Dateiindex werden in dem durch „buf“ spezifizierten Puffer abgelegt. Der Dateiindex wird weggelassen, wenn bei Dopendir() der Kompatibilitätsmodus angegeben worden war. Wenn zwei Dateinamen den gleichen Index haben, stehen sie für dieselbe Datei.

„len“ ist die Länge des in „buf“ angegebenen Puffers. Er sollte groß genug für Dateiindex (falls nötig), Dateinamen und abschließendes Null-Byte sein. Zusätzlich werden die erweiterten Dateiattribute [siehe Fxattr()] in den durch „xattr“ spezifizierten Speicher geschrieben. Dabei werden symbolische Links nicht aufgelöst. Achtung: Dieser Teil des Aufrufs kann fehlschlagen, obwohl der Dateiname lesbar war. In diesem Fall wird ein getrennter Returncode in dem LONG abgelegt, auf das „xr“ zeigt.

Aufeinanderfolgende Aufrufe von Dxreaddir() oder Dreaddir() liefern alle Einträge aus dem Verzeichnis zurück, es sei denn, es wurde zwischendurch Drewinddir() aufgerufen.

Im Erfolgsfall wird 0 zurückgeliefert. In diesem Fall enthält der LONG-Wert, auf den „xr“ zeigt, den Status der XATTR-Abfrage. Anderenfalls können auch ERANGE (Puffer zu kurz) oder ENMFIL (keine weiteren Dateien) auftreten.


Julian F. Reschke
Aus: ST-Computer 09 / 1994, Seite 78
Links
Copyright-Bestimmungen: siehe Über diese Seite