Environment-Variablen - Kurzes Programm mit Pfiff!
Letzten Monat versprochen und diesen Monat tatsächlich da: Ein kurzes Programm, mit dem man aus dem AUTO-Ordner heraus die AES-Environment-Variablen setzen kann.
Doch bevor wir zu dem Innenleben des Programms kommen, ein wenig Theorie. Es sind tatsächlich nur die Environment-Variablen des Programms, das das AES beim Booten des Rechners aufgerufen hat.
Genau wie bei den Environment-Variablen eines »normalen« GEMDOS-Programms handelt es sich um eine Liste von ASCII-Strings, in denen die verschiedenen Variablennamen und ihre Werte festgehalten sind. Wie immer bei Environment-Strings ist die sogenannte »PATH«-Variable die wichtigste. Sie gibt einfach eine Liste von Verzeichnissen an, in denen nach bestimmten Dateien gesucht werden soll.
Und genau dies tut das AES auch. Wann immer das AES bei »rsrc_load()« oder »shel_find()« eine Datei sucht, wird in verschiedenen Ordnern gesucht. Dabei inspiziert das AES das aktuelle Verzeichnis und alle Ordner, die in der Environment-Variablen »PATH« verzeichnet sind. Ab TOS 1.4 wird noch zusätzlich der Ordner untersucht, in dem das gestartete Programm liegt (dazu wird der sogenannte »shel_read/write-Buffer« benutzt).
Erste Folgerungen: In eigenen Programmen sollte man immer alle Dateien mittels »shel_find()« suchen (zumindest dann, wenn man sie nicht woanders finden kann). Eine Ausnahme stellen natürlich die Resource-Dateien dar, die man mittels »rsrc_load()« lädt (intern benutzt das AES dazu natürlich auch »shel-find()«).
Nun kann man natürlich außer der Pfadvariablen noch frei nach Gutdünken weitere Variablen setzen. Diese Variablen werden dann nicht nur mit der AES-Funktion »shel_envrn()« abgefragt, sondern sie werden auch vom Desktop an alle gestarteten Programme als normale GEMDOS-Environment-Variablen weitergereicht.
Naheliegend ist es beispielsweise, den Standardsuchpfad um einen Ordner zu erweitern, in dem man alle Resource-Dateien sammelt. Damit werden die Verzeichnisse auf der Festplatte deutlich übersichtlicher. Nachteil: leider vergißt man zu oft beim Weitergeben von Programmen den Resource-File.
Jetzt ein Beispiel für das Hinzufügen neuer Environment-Variablen: Turbo-C beispielsweise sucht beim Öffnen seiner Help-Datei nach der Environment-Variablen »TC«. Falls vorhanden, wird die Help-Datei im darin angegebenen Ordner gesucht. Damit ist es nicht notwendig, die Help-Datei im gleichen Ordner wie Turbo-C zu installieren.
Kommen wir nun zur Funktionsweise unseres kleinen Programms. Es basiert auf der glücklichen Tatsache, daß das BIOS zum Starten von AES und Desktop einen Vektor benutzt (»exec_os« bei Adresse $4FE). Das dort installierte Programm wird ganz normal mit einem »Pexec()«-Kommando gestartet und erhält somit auf dem Stack auch den Zeiger auf seine Basepage. Und in eben dieser Basepage steht ja auch der Zeiger auf die Environment-Variablen, den man also nur umzusetzen braucht.
Das Programm gehört in den AUTO-Ordner und liest die Datei »ENV.INF« aus dem Wurzelverzeichnis des Bootlaufwerks ein. Diese Datei sollte einzelne Textzeilen mit den verschiedenen Environment-Variablen enthalten. Hat das Laden der Datei geklappt, wird »exec_os« auf eine Routine umgebogen, die das Standard-Environment durch das neu eingelesene ersetzt und anschließend durch den alten Vektor springt.
Bleiben noch einige Anmerkungen: Das BIOS installiert normalerweise als Standardpfad einfach das Wurzelverzeichnis des Bootlaufwerks. Dazu verwendet es die Systemvariable »_bootdev« und begeht dabei unglücklicherweise einen seit langem bekannten Fehler: es betrachtet die Systemvariable als Byte statt als Wort und greift damit auf die falsche Speicherzelle zu. Resultat: als Standardpfad wird »A:\« eingetragen - ungeachtet, von welchem Laufwerk man gebootet hat. Die meisten Harddisktreiber von Fremdherstellern umschiffen dieses Problem auf die eine oder andere Weise. Mit unserem Programm verschwindet das Problem natürlich von alleine, denn es wird ja ein völlig neues Environment installiert. Aber nicht vergessen: im Standardzugriffspfad sollten alle Laufwerke auftauchen, von denen man zu booten pflegt, sonst finden unter Umständen Accessories ihre Resource-Dateien nicht.
Und dann ist da noch ein anderes Problem: leider setzt das BIOS das Environment auf eine andere Art und Weise, als der ganze Rest der Computerwelt. Normalerweise handelt es sich bei den Environmentstrings um nullterminierte Strings der Form »VARIABLE=WERT«. Das Ende wird demzufolge durch eine doppelte Null angegeben. Anders beim BIOS, das leider hinter der Zeichenkette »PATH=« eine Null einfügt. Das AES kompensiert diesen Fehler auf zweierlei Arten (je nach TOS-Version): Früher (vor TOS 1.4) wurde bei der Initialisierung die betreffende Null durch ein Semikolon ersetzt. Um den Pfad zu bekommen, mußte man an »shel_envrn()« die Variable »PATH =;« übergeben. Bei TOS 1.4 ist es ein wenig anders: hier unterläßt das AES das Ändern des Strings. Es ignoriert »shel_envrn()« bei der Variable »PATH=« einfach das letzte Zeichen, so daß auch hier »PATH=;« zum Ziel kommt. Viel Spaß beim Experimentieren.
Julian Reschke/mb