MultiTOS für Einsteiger Teil 2
Im letzten Teil unseres Kurses haben wir die MINT.CNF-Datei zerpflückt, diesmal werden wir zunächst über das unbekannte Wesen GEM.CNF herfallen, die Steuerdatei für das MultiAES.
Doch zunächst vorweg eine Kleinigkeit in eigener Sache: MultiTOS befindet sich zum Nutzen der Anwender momentan in einer rasanten Entwicklung. Eingetragene Entwickler erhalten neue Versionen am laufenden Band, und natürlich werden die Fähigkeiten dieser Beta-Ausgaben früher oder später ihren Weg in die Öffentlichkeit finden. Da wir Schreiberlinge leider mit einer Vorlaufzeit von ein bis zwei Monaten leben müssen (die Zeitung will ja schließlich gedruckt werden), kann es sein, daß unsere „Äußerungen" bezüglich MultiTOS bei Erscheinen des Artikels schon wieder leicht „angegraut" sind. Selbstmurmelnd wird in so einem Falle bei nächster Gelegenheit ein entsprechendes „Update" nachgereicht!
Nun zur GEM.CNF-Datei: Wurde Ihre Version von MultiTOS vom mitgelieferten Install-Programm auf die Festplatte gebracht, finden Sie diese Datei in Ihrem Ordner MULTITOS. Alternativ kann GEM.CNF auch im Root-Verzeichnis des Boot-Laufwerkes liegen. MultiTOS sucht beim Hochfahren des Systems zuerst im Root-Verzeichnis und dann im Ordner MULTITOS. Sollte sich GEM.CNF an beiden Stellen finden, kommt nur die zuerst gefundene (C:\GEM.CNF) zur Anwendung, gleiches gilt übrigens auch für MINT.CNF.
Eine "jungfräuliche" GEM.CNF sieht folgendermaßen aus:
# gem.cnf
# Last Modified on 6/14/1993 17:08
#===============================
setenv PATH=.,C:\BIN,C:\MULTITOS
setenv ACCPATH=C:\
setenv ACCEXT=ACC.ACX
setenv GEMEXT=PRG,APP,GTP
setenv TOSEXT=TOS,TTP
setenv SHSHOW=C:\MULTITOS\VIEWER.APP
setenv SHPRINT=C:\MULTITOS\LPR.APP
setenv TOSRUN=C:\MULTITOS\MINIWIN.APP
Kommentare in GEM.CNF werden mit dem Zeichen „#" eingeleitet, der Rest der Zeile wird dann von MultiTOS ignoriert.
Als einziger Befehl wird hier setenv verwendet. Er steht für „set environment", mit ihm können systemweit abfragbare (Environment-) Variablen gesetzt werden. Unter den bisherigen TOS-Versionen wurden diese (milde ausgedrückt) stark vernachlässigt bzw. gar nicht benutzt. MultiTOS hingegen macht regen Gebrauch davon, es kann mit diesen Variablen in Grenzen konfiguriert werden. Folgende Variablen werden verwendet:
PATH: eine Reihe von Pfaden (getrennt durch Kommata), in denen MultiTOS nach ausführbaren Programmen und Resourcen sucht. Besonders, wer mit einem befehlsorientierten Kommando-Interpreter arbeiten möchte, sollte hier für korrekte Einträge sorgen, damit die externen Programme auch gefunden werden.
ACCPATH: die Pfade, in denen MultiTOS beim Hochfahren nach Accessories sucht. Allerdings wird in den momentanen Versionen wie gewohnt zuerst im Root-Verzeichnis des Boot-Laufwerks gesucht, und nur, wenn dort kein Accessory gefunden wird, verwendet MultiTOS die Angaben in dieser Variablen.
ACCEXT: die Extentions der aktiven/ inaktiven Accessories. Von den aktuellen MultiTOS-Versionen wird dieser Wert allerdings vollständig ignoriert. Der Vollständigkeit halber sollte er aber trotzdem richtig gesetzt sein.
GEMEXT: die Extentions von GEM-Programmen. Wie bei ACCEXT dient diese Variable im Moment auch nur der Kosmetik.
TOSEXT: die Extentions von TOS-Programmen. Eigentlich könnte man erwarten, daß Programme mit den hier genannten Extensions von MultiTOS im Fenster gestartet werden; durch diese Erwartung wird von MultiTOS enttäuscht - auch dieser Wert wird ignoriert.
SHSHOW: der komplette Pfad zu einem Programm, das vom Multi-Desktop zum Anzeigen von Dateien verwendet wird. Immer nach der Anwahl von „Anzeigen" in der bekannten Dialogbox „Anzeigen, Drucken, Abbrechen" startet dieses Programm. Das mitgelieferte Programm VIEWER.APP zeichnet sich leider durch besondere Unfähigkeit aus, auf dem PD/Shareware-Markt findet sich reichlich besserer Ersatz.
SHPRINT: der komplette Pfad zu einem Programm, das vom Multi-Desktop zum Ausdrucken von Dateien (analog SHSHOW) verwendet wird. Im Gegensatz zum VIEWER arbeitet das beigelegte Tool LPR.APP durchaus brauchbar.
TOSRUN: wieder einmal der komplette Pfad zu einem Programm, mit dessen Hilfe MultiTOS TOS-Programme im Fenster starten kann. MINIWIN.APP funktioniert recht gut, bietet aber nicht ganz die Fähigkeiten von TOSWIN, einem PD-Programm ebenfalls aus der Feder von Eric E. Smith.
Das waren die Variablen der Minimalkonfiguration; wer sich mit Hilfe eines Dateimonitors GEM.SYS näher ansieht, findet weitere Zugaben. Insbesondere den folgenden beiden kann man sicherlich eine große Zukunft Vorhersagen, da sie einen modularen Aufbau des Desktops ermöglichen.
DESKFMT: der komplette Pfad zu einem Programm, das vom Multi-Desktop anstelle der eingebauten Formatierroutinen verwendet werden soll. Damit kann man die recht „trägen“ Funktionen einfach durch ein anderes Programm ersetzen, vorausgesetzt dieses versteht die Argumente, die MultiTOS in der Kommandozeile übergibt.
DESKCOPY: der komplette Pfad zu einem Programm, das vom Multi-Desktop anstelle der eingebauten Kopier- und Löschroutinen verwendet werden soll. Auch diesem Programm wird die vom Anwender getätigte Auswahl als Reihe von Argumenten in der Kommandozeile übergeben.
Mit an Sicherheit grenzender Wahrscheinlichkeit wird es bald eine wahre Flut von Programmen geben, die sich in diese beiden Variablen eintragen lassen. Ein Ihnen sicher bekanntes „kleines grünes Männchen“ zählt zu den aussichtsreichsten Aspiranten auf diesen Job.
Abgesehen von der Möglichkeit, das Environment zu bestimmen, erlaubt MultiTOS auch noch einige andere Befehle in der GEM.CNF:
run <Pfadname eines Programmes>
startet das gewünschte Programm. Damit können zum Bleistift beliebig viele GEM-Programme gleich beim Hochfahren des Systems gestartet werden. Eine Einschränkung ist hierbei allerdings zu beachten: den Programmen kann man mit run keine weiteren Argumente/Parameter übergeben. Gerüchten zufolge soll es Multitasking-Freaks geben, die hier immer die Zeile run c:\multitos\lines.app eintragen.
shell <Pfadname eines alternativen Desktops>
Einer der vielen Vorzüge von MultiTOS ist, daß das eingebaute Desktop vollständig durch ein anderes ersetzt werden kann. Haben Sie unter den alten TOS-Versionen GEMINI/EASE/NEODESK/o.ä. verwendet, belegte das Original-Desktop trotzdem Speicher. Unter MultiTOS geschieht dies nicht mehr, da nur noch das via „shell“ angegebene Programm überhaupt geladen wird. Allerdings sollten Sie zum gegenwärtigen Zeitpunkt noch etwas vorsichtig bei der Verwendung von alternativen Desktops sein, da einige noch nicht ganz mit MultiTOS zurechtkommen. Natürlich muß das hier eingetragene Programm nicht unbedingt ein Desktop-Ersatz sein, es können beliebige GEM-Programme als Shell Verwendung finden. Ganz eingefleischte Tastatur-Freaks können sogar via TOSWIN einen Kommando-Interpreter starten.
In gut informierten Kreisen kursieren auch noch einige Befehle, die mit AE_ beginnen. Diese Befehle sollten Sie allerdings meiden, da es sich hierbei um überwiegend kaum getestete Beta-Features von MultiTOS handelt, die bei Verwendung mitunter zu katastrophalen Ergebnissen führen können. Auch ist ihr „Weiterleben" von ATARI nicht garantiert.
Damit sollten alle „Klarheiten“ bezüglich der grundlegenden Installation von MultiTOS beseitigt sein; kommen wir zu den Feinheiten.
Memory Protection
Verwenden Sie MultiTOS auf einem Rechner mit 68030/40-CPU, können Sie, wie schon im letzten Teil erwähnt, in den „Genuß“ des Speicherschutzes kommen. MultiTOS achtet dann darauf, daß Programme nur auf die ihnen zugewiesenen Teile des Speichers zugreifen. Speziell ältere Programme haben damit so ihre Probleme. Werden sie beim Wühlen in fremdem Speicher erwischt, meldet MultiTOS einen „Memory Violation Error“ und beendet den Übeltäter. Bei manchen Programmen bzw. Anwendungen läßt es sich nun aber nicht vermeiden, daß auf fremden Speicher zugegriffen wird. Damit in so einem Falle nicht immer die komplette Memory Protection abgeschaltet werden muß, wurden unter MultiTOS die Programm-Flags für den Speicherschutz erweitert. Durch diese Erweiterung kann einem Programm einer von vier Status zugeordnet werden:
1. Private
Nur der Prozeß selbst und das Betriebssystem können auf den Speicher des Programmes zugreifen, das gilt für Lesen und Schreiben. Solche Programme sind also hervorragend vor äußeren Einflüssen abgeschirmt.
2. Global
Der Speicher eines solchen Programmes ist überhaupt nicht geschützt, alles und jeder kann sowohl lesend als auch schreibend darauf zugreifen. Natürlich können „wildgewordene“ Applikationen ein Programm mit diesem Status auch leicht beschädigen. daher sollte dieses Flag nur dann gesetzt sein, wenn es unbedingt sein muß.
3. Super
Im Supervisor-Mode kann auf diesen Speicher ungestraft zugegriffen werden, das gilt auch hier wieder für Lesen und Schreiben. Super bietet ein wenig mehr Schutz als Global, da man davon ausgehen kann, daß Programme die im Super-Modus laufen, eher wissen, was sie in dem Speicher anderer Programme treiben und nicht zufällig darin „herumschreiben“.
4. Readable
Hier dürfen alle anderen lesend auf den Speicher des Programmes zugreifen. Schreiben ist weiterhin strikt verboten! Speziell ältere Programme, die mit dem AV-Protokoll Parameter übergeben, können durch das Flag Readable zur ordnungsgemäßen Mitarbeit unter Multi-TOS mit Speicherschutz überredet werden.
Für Programmierer: Die Flags der Memory Protection verbergen sich in dem vorletzten Nibble von PRGFLAGS.
0x00 Private
0x10 Global
0x20 Super
0x30 Readable
Leider liefert ATARI zum Einstellen dieser Flags nur CHPROT.APP mit. Dieses Machwerk der Programmierkunst schaltet ein Programm immer in den Global-Modus und unterläuft damit die Memory Protection vollständig. Im PD /Shareware-Bereich existieren allerdings bereits Programme/CPX- Module, die einen erheblich komfortableren und sinnvolleren Zugriff auf diese Flags ermöglichen.
Ein Problem bei der Beseitigung von Kompatibilitätsproblemen (was für ein Wort) mit älteren Programmen ist die Tatsache. daß wir nicht den Zugreifer finden müssen (den meldet uns ja MultiTOS), sondern das Programm, auf dessen Speicher vom Übeltäter zugegriffen wird. Ist nach einigem Probieren das verantwortliche Programm entdeckt, sollte dessen Schutzstatus schrittweise gelockert werden (Readable, Super, Global), bis das Zusammenspiel ohne Fehlermeldung klappt. Sollten alle Bemühungen, ein „Altprogramm“ unter Memory Protection zum Laufen zu bringen, scheitern, bleibt nur die Abschaltung des Speicherschutzes als letzter Ausweg übrig.
Ach ja, „bevor ich vergess’ Ihnen zu erzählen“: Programme, die im Auto-Ordner vor MiNT gestartet werden und resident im Speicher verbleiben, erhalten vom System automatisch den Status Global, hier hat also eine Einstellung der Flags keinerlei Effekt, diese Programme sind sozusagen Freiwild.
Auch noch zum Themenkreis Kompatibilität gehört:
Das Pseudolaufwerk U:
Wer vor MultiTOS noch keine Erfahrungen mit MiNT gesammelt hat, den wird zunächst das Auftauchen eines neuen Laufwerkes auf dem Desktop verblüffen. Bedingt durch die Ähnlichkeit zu UNIX, versucht MiNT, alle Dateisysteme unter einem Laufwerk zusammenzufassen. Wer das Inhaltsverzeichnis von U: einmal öffnet, findet dort alle seine Partitionen und Diskettenlaufwerke in Form eines Ordners wieder. Existiert z.B. die Datei „C:\MULTITOS\VIEWER.APP“, findet sie sich auch als „U:\C\MULTITOS\VIEWER.APP‘. Davon abgesehen, dient U: im Moment auch als einzig mögliches Ziel für Links; Sie erinnern sich an den Befehl sin in MINT.CNF? Damit immer noch nicht genug, es existieren in U: weitere vier Verzeichnisse:
U:\DEV enthält die Gerätetreiber des BIOS. Diese Pseudodateien sind eigentlich für den Einsteiger uninteressant, sie werden von Programmen zur Kommunikation mit dem System und angeschlossenen Geräten benutzt.
U:\PIPE enthält diverse Pipes. Über diese Pseudodateien tauschen Programme Nachrichten und Daten aus. Die Lebensdauer dieser Dateien ist sehr begrenzt. Eine solche Pipe-Datei wird entfernt, wenn der letzte Nutzer die Pipe schließt.
U:\PROC, hier finden sich alle gestarteten Programme wieder. Der Dateinamen setzt sich aus dem Programmnamen und der Prozeß-ID zusammen (z.B. „XCONTROL.007“). Die Größe eines Eintrags gibt dessen Speicherverbrauch wieder. Der Zeit&Datum-Eintrag zeigt an, wann das betreffende Programm gestartet wurde. Wer sich vor Abstürzen nicht fürchtet, kann ein Programm auch dadurch beenden, daß er dessen Eintrag einfach auf den Mülleimer des Desktops zieht. Etwas sicherer ist folgende Methode zum Beenden von Programmen: Man wählt den entsprechenden Eintrag im Desk-Menü an und hält gleichzeitig die Control-Taste gedrückt: schon wird das Programm in die ewigen Jagdgründe befördert, sprich: beendet.
U:\SHM, Einträge in diesem Verzeichnis repräsentieren Shared-Memory-Blöcke. Über diese können sich mehrere Programme einen Speicherbereich teilen, ohne in Konflikt mit der Memory Protection zu kommen, natürlich müssen die Programme dazu entsprechend an MiNT/Multi-TOS angepaßt sein.
Einer der wichtigsten Ratschläge, die man einem Einsteiger in Sachen Umgang mit U: geben kann, ist folgender:
NIIIIIIEEEE auf die Idee kommen, sich über das Desktop-Menü „Datei/zeige Info“ die Belegung von U: anzuschauen! Abhängig von der Anzahl der angeschlossenen Diskettenlaufwerke, der eingelegten Disketten und der vorhandenen Festplatten bzw. Partitionen verfällt der Rechner sonst in hektische Aktivität, die ihn minutenlang (oder länger) blockiert, aufgelockert von der Aufforderung, doch bitte die Diskette B in das Laufwerk A einzulegen und umgekehrt.
Ferner sollte man ältere Programme, die sehr tief in die Verwaltung eines Laufwerkes einsteigen (z.B. Disketten-/Dateimonitore), tunlichst von U: fernhalten, da dieses Laufwerk ja physikalisch gar nicht existiert. Im besten Falle versagen die „Altwaren“ einfach den Dienst, im „worst case“ aber kann Datenverlust nicht ganz ausgeschlossen werden. Zur Erinnerung: über U: kann ein Programm alle anderen Laufwerke erreichen, ohne einen expliziten Laufwerkswechsel zu vollziehen! Man sieht, alle guten Dinge haben auch hier wieder einmal „weniger gute“ Seiten.
Aber nun ist genug „geunkt“, beim nächsten Mal werden wir uns mit den (ungeahnten) Fähigkeiten von MINIWIN auseinandersetzen.
Richard Kurz