Atarium: How-to Gemini
In letzter Zeit haben uns einige Anfragen im Zusammenhang mit der MultiTOS-Serie von Richard Kurz und der neuen Version des Desktops 'Gemini' erreicht. Viele der Leser wollen wissen, inwiefern das unter 'MultiTOS goes UNIX' erworbene Wissen auf Gemini und Mupfel anwendbar ist.
Die Installation von Gemini und Mupfel ist zum Glück sehr einfach, da das von Stefan Eissing zusammengestellte Release (GMNI2.TOS) ein selbstextrahierendes ZIP-Archiv ist. Man kopiert also nur das Archiv auf das Laufwerk, wo Gemini installiert werden soll, und startet die Datei. Es entsteht eine komplette Ordnerhierarchie innerhalb des Hauptverzeichnisses GEMINI2. In diesem Verzeichnis findet man dann auch GEMINI.APP, das so konfiguriert ist, dass es beim ersten Start alle sinnvollen Voreinstellungen vornimmt.
Die Mupfel ist eine Kommando-Shell, die der in der Serie beschriebenen Korn-Shell in vielerlei Hinsicht ähnelt. Es gibt sie als TOS-Programm (MUPFEL.TTP), aber gleichzeitig ist sie auch fester Bestandteil von Gemini selbst. Wenn ich also im folgenden von der 'Mupfel' spreche, ist sowohl das eigentliche TOS-Programm MUPFEL.TTP als auch die Shell innerhalb von Gemini gemeint.
Wie man aus der MultiTOS-Serie weiß, sind viele Shell-Funktionen nicht fester Teil der Shell, sondern in externen Programmen zu finden. Zu Gemini gibt es eine Sammlung von solchen Dienstprogrammen, die speziell auf die Mupfel in Gemini angepaßt sind und sich sehr leicht zusätzlich installieren lassen. Man besorge sich also die Archive MUPFTL02.TOS und TEXTTL02.TOS (zum Beispiel aus der Maus Münster), kopiere sie in das Hauptverzeichnis von Gemini und starte sie per Doppelklick: die Ordnerstruktur in den Archiven ist so ausgelegt, dass die Programmdateien und die Manuals automatisch in den von Gemini dafür vorgesehenen Verzeichnissen landen. Man beachte allerdings die aktuellen Textdateien mit den Lizenzbestimmungen: die Benutzung der Tools ist zwar frei, dennoch aber nicht ohne rechtliche Regelung.
Machen wir nun einen kleinen Versuch: öffnen Sie die Gemini-Konsole per ALT-M (oder über den entsprechenden Menüpunkt), und geben Sie das Kommando uname ein. Wenn der Rechner als Antwort nicht den Namen des Betriebssystems (etwa: "TOS") ausgibt, sondern mit einer Fehlermeldung reagiert, dann ist bei der Installation etwas schiefgelaufen. Prüfen Sie in diesem Fall nach, ob UNAME.TTP tatsächlich in einem der in der Variablen PATH angegebenen Verzeichnisse liegt (echo $PATH).
Sinn und Zweck eines Desktops wie Gemini ist natürlich, den 'normalen' Desktop des Systems zu ersetzen. Solange man keine Multitasking-Umgebung benutzt, reicht es, GEMINI.APP einfach als Autostart-Applikation anzumelden (das geht ab TOS 1.04).
Neu an Gemini 2 ist allerdings, dass es auch MultiTOS und MaglX unterstützt. Wer also ATARIs eigenen Desktop nicht mag (zum Beispiel, weil er die langen Dateinamen einer Minix-Partition nicht anzeigen kann), kann ihn sich im Nu vom Hals schaffen. Dazu fügt man in der Datei GEM. CBF (liegt normalerweise im Verzeichnis C:\MULTITOS) folgende Zeile ein:
Shell c:\gemini2\gemini.app
(wenn Sie Gemini auf Laufwerk C: installiert haben).
Ähnlich sieht es mit Mag!X aus: in diesem Fall ist in der Datei MAGX.INF folgende Zeile zu modifizieren bzw. neu einzufügen:
#_SHL C:\GEMINI2\GEMINI.APP ; Shell
Nach einem Neustart des Systems sollte nun Gemini als Standard-Desktop erscheinen.
Das Konsolenfenster von Gemini ist übrigens kein Ersatz für Miniwin bzw. VT52: die dort laufende Mupfel ist ein integraler Bestandteil und kann auch nicht durch ein anderes Programm ersetzt werden. Ebensowenig ist es möglich, im Konsolenfenster nebenläufig TOS-Programme ablaufen zu lassen (es sei denn, man schickt sie unter MiNT mit & in den Hintergrund). Für solche Fälle muß man die separate Mupfel (also MUPFEL.TTP in Miniwin bzw. VT52) ablaufen lassen.
Was unterscheidet die Mupfel außerdem von Shells, die von Unix portiert wurden?
Zunächst wird wohl auffallen, dass die Mupfel und sämtliche Dienstprogramme ihre Meldungen in deutscher Sprache ausgeben. Das mag dem einen oder anderen Unix-Freak zunächst zwar etwas komisch vorkommen, ist aber den allermeisten Benutzern in Deutschland erheblich lieber. Gleiches gilt für die Manual-Pages, die ebenfalls komplett in Deutsch abgefaßt sind.
Eine andere wichtige Abweichung ergibt sich durch die Art und Weise, wie unter TOS Laufwerke und Dateien angesprochen werden: auch unter der Mupfel kann man die Tatsache ausnutzen, dass TOS sich für jedes Laufwerk einen eigenen aktuellen Zugriffspfad merkt. Und zum Laufwerkswechsel braucht man nicht den cd-Befehl, sondern kann unmittelbar den Laufwerksnamen (z.B. "a:") eingeben. Unter MiNT bleibt es natürlich jedem unbenommen, nur noch auf Laufwerk U: zu arbeiten.
TOS benutzt als Pfadtrennzeichen den Backslash (), und das bleibt auch in der Mupfel so. Leider benutzen Unix-Shells dieses Zeichen traditionell als Escape-Zeichen, so dass die Mupfel in dieser Hinsicht leider inkompatibel bleiben muß.
Ähnlich wie die Korn-Shell, bietet die Mupfel die Möglichkeit zur Kommandobzw. Dateinamensvervollständigung. Geben Sie in der Kommandozeile beispielsweise ein 'a' ein und drücken einmal TAB, dann wird der Kommandoname so weit es geht vervollständigt. Im allgemeinen gibt es natürlich mehr als ein Kommando, das mit 'a' beginnt. Durch einen zweiten Druck auf TAB kann man sich daher die Liste der möglichen Vervollständigungen anzeigen lassen.
Der gleiche Mechanismus funktioniert auch mit Dateinamen (Wörter, die nicht am Zeilenanfang stehen) und Variablennamen (Wörter, die mit $ beginnen). Eine Mupfel-Spezialität ist allerdings die Vervollständigung von Optionen: probieren Sie einmal:
ls - <TABxTAB>
Die Mupfel zeigt nun alle 'langen' Optionen für das Kommando ls an. Die Optionen werden übrigens speziellen Optionsdateien im Manual-Verzeichnis (OPTION-PATH) entnommen, so dass auch für externe Kommandos die Informationen eingetragen werden können. Selbstverständlich sind in den oben angesprochenen Tool-Sammlungen entsprechende Optionsdateien schon enthalten.
Schließlich sei noch auf ein paar technische Leckerbissen hingewiesen: die Speicherverwaltung der Mupfel gibt, wenn sich die Gelegenheit bietet, auch wieder Speicher an das Betriebssystem zurück. Andere Shells, die temporär viel Speicher anfordern, werden diesen Platz solange blockieren, bis man sie verläßt. Daneben nutzt die Mupfel intern MiNT-'Threads'. So können interne Mupfelkommandos wirklich nebenläufig ausgeführt werden, ohne dass eine neue Shell gestartet werden müßte.
Fazit: die Mupfel versucht, soweit wie möglich an 'the real thing' heranzukommen, ohne dabei allzuviel Vertrautes über Bord werfen zu müssen.
Nun noch ein kleiner Programmiertip: Wer Unix-Tools portieren oder selbst implementieren will, wird mit Sicherheit früher oder später auf folgendes Problem stoßen: oft sollen Tools optional ihren Datenstrom von der Standardeingabe entgegennehmen können (zum Beispiel wc). Dabei ist es aber nicht immer korrekt, wenn die Daten als Text interpretiert werden, was aber nun mal im ANSI-C für stdin der Fall ist.
Die MiNT-C-Library sieht schon seit langer Zeit eine Möglichkeit vor, dies zu umgehen: dazu setzt man die Environment-Variable UNIXMODE so, dass die Konvertierung nicht vorgenommen wird. Leider erfordert dies, dass der Benutzer sein System je nach Situation entsprechend umkonfiguriert, was sicherlich unschön ist.
Viele C-Bibliotheken auf dem PC sehen eine Funktion setmode vor, mit der die Konvertierung nachträglich geändert werden kann. Sauberer ist allerdings der Weg, der in der POSIX-Spezifikation P1003.1 ([!]) gegangen wurde: dort ist die Funktion fdopen definiert, die genauso wie fopen funktioniert, allerdings anstelle eines Dateinamens ein Handle einer bereits geöffneten Datei erwartet.
In der MiNT-C-Library ist diese Funktion schon seit Monaten implementiert, Benutzer der Pure-C-Bibliotheken schauen aber (wie so oft) in die Röhre. Abhilfe schafft die Funktion aus Listing 2, die allerdings nur als Übergangslösung gedacht ist: zunächst wird eine FILE-Struktur besorgt, indem eine Datei geöffnet wird, die man immer und ohne Nebenwirkungen öffnen kann ("CON:"). Anschließend wird das gewünschte Handle ohne Rücksicht auf Verluste in die Struktur eingetragen.
Kurz vor Redaktionsschluß erreichte uns noch die Nachricht, dass ATARI das neue MetaDOS-Release (2.3) freigegeben hat. Neben einigen kleineren Fehlerkorrekturen und erweiterten Auskunftsfunktionen sind nun insbesondere Schnittstellen für multisessionfähige Treiber vorgesehen (ATARI selbst liefert ja solche Treiber nicht). MetaDOS 2.3 darf wie die Vorgängerversion zur nichtkommerziellen Nutzung frei weitergegeben werden und ist in gut sortierten Mailboxen (zum Beispiel Maus Münster 2) zu finden.
Soviel für diesen Monat. Nächstes Mal werden wir aller Wahrscheinlichkeit nach über eine neue MiNT-Version berichten können. Bis dann!
FILE *
fdopen (int handle, char *mode)
{
FILE *f;
f = fopen ("CON:", mode);
if (f) fileno(f)=handle;
return f;
}
fdopen für PureC-stdio
Quellennachweis:
[1] The Institute ofElectrical und Electronics Engineers, Inc. (IEEE): "Information technology - Portable Operating System Interface (POSIX) -Part 1: System Application Program Interface (API) [C Language]", IEEE Std 1003.1-1990, ISO/IEC 9945-1, ISBN 1-55937-061-0
Bezugsquellen für Gemini
GMNI2.TOS, MUPFTL02.TOS und TEXTTL02.TOS sind in den meisten gut sortierten Mailboxen zu finden (zum Beispiel Maus Münster 2). Ähnliches gilt für Ulrich Kühns Manual-Viewer Manview (MANVIEW.ZOO). Daneben findet man die Archive auch auf verschiedenen FTP-Servern, unter anderem ftp.uni-muenster.de (pub/atari/Gemini bzw. pub/atari/Man).
Julian F. Reschke