Atarium: Schranken durchbrechen

J. Reschke: »Turbo-DOS nicht fehlerfrei«

Applikationen erkennen, ob man sie als Accessory oder als Programm gestartet hat Bevor wir im folgenden einige Ideen vorstellen, die Beschränkungen des ST aufheben und den Programmierern die Arbeit erleichtern sollen, sei noch einmal kurz auf das Programm »Turbo-DOS« eingegangen. Über dieses Programm, das Atari Deutschland zusammen mit Hard-Disks offiziell ausliefert, haben wir in den beiden zurückliegenden Ausgaben berichtet.

Im praktischen Einsatz stellte sich schnell heraus, daß sich Turbo-Dos mit etlichen Programmen nicht verträgt, die sich in die »Rwabs()«-Routine des BIOS einklinken (RAM-Disks, Hard-Disk-Caches und dergleichen). Das liegt wohl daran, daß die DOS-Routinen von Turbo-DOS vor BIOS-Aufrufen zu wenig Register retten. Auch zerschossene Disketten und Festplatten sollen schon aufgetreten sein. Allan Pratt, seines Zeichens Systemprogrammierer bei Atari Amerika, hat auf »USENET« offiziell vor der Verwendung von Turbo-DOS gewarnt (Atari Amerika liefert das Programm auch nicht aus). Wer dennoch nicht auf die Geschwindigkeitssteigerung verzichten will, sollte zumindest beim Wechseln von Disketten nach Diskoperationen mit dem Desktop sehr vorsichtig sein!

Ein häufig in seiner Wichtigkeit unterschätzter Programmteil ist die Initialisierung, die Startup-Routinen bei Compilern im allgemeinen automatisch vornehmen. Bei C-Compilern findet man den Code meist in einer Objektdatei namens »STARTUP«, »APSTART« oder ähnlich. Meistens geben diese Routinen nur den überzähligen Speicherplatz zurück, initialisieren den Stack, durchsuchen die übergebene Kommandozeile und starten das »Hauptprogramm« (in C ist es die Funktion »main()«).

Diese Stelle im Programm kann man allerdings auch anderweitig nutzen. Viele Programmierer behelfen sich bei der Entwicklung von Accessories mit den Fähigkeiten des C-Preprozessors, um ihr Accessory zunächst als Programm auszutesten. Wenig bekannt ist, daß ein Programm problemlos selbst feststellen kann, ob es als Programm oder als Accessory gestartet worden ist. Damit läßt sich ein Programm schon durch bloßes Umbenennen umfunktionieren.

Ein Trick für alle GEM-Versionen

Dazu macht man sich die Tatsache zunutze, daß das AES beim Laden eines Accessorys keinen wirklichen GEM-DOS-Prozeß erzeugt. Es reicht also, in der eigenen Basepage nachzusehen, ob der Zeiger auf den erzeugenden Prozeß ein Nullpointer ist. Je nachdem setzt man eine globale Variable auf TRUE oder FALSE, so daß das Hauptprogramm sich dann passend initialisiert (Vorschlag zur Normung: »app« ist FALSE, falls das Programm als Accessory geladen ist, ansonsten TRUE). Tatsächlich gibt es für Megamax-C bereits eine maßgeschneiderte Startup-Datei (erhältlich bei Application Systems Heidelberg auf der »Megamax C Tooldiskette II«), die genauso arbeitet. Dieser Trick funktioniert auf allen mir bekannten GEM-Versionen (einschließlich 2.0) und darf daher wohl mit gutem Gewissen benutzt werden.

Eine echte Schwäche von GEM-DOS ist, daß sich über die Kommandozeile nur maximal 124 Zeichen übergeben lassen. Verschiedene Seiten haben daher den Versuch unternommen, diese Einschränkung mit Hilfe eines Tricks zu umgehen. Der Vorschlag einer amerikanischen Entwicklergruppe um Dale Schumacher verspricht, sich zum Standard zu entwickeln, zumal Programmierer bei Atari Amerika ihn ganz offiziell unterstützen.

Das im folgenden »xArg«-Methode (»Extended Argument Passing Scheme«) genannte Verfahren geht folgendermaßen vor: Vor dem Start des Programms erweitert es das Environment um eine Variable namens »xArg«. Der Wert dieser Variable ist eine achtstellige Hexadezimalziffer (also beispielsweise »xArg=002345CA«), die die Adresse einer XARG-Struktur angibt (siehe Listing).

< xarg__magic > ist dabei die Zeichenkettenkonstante »xArg« (hexadezimal $78417267), anhand derer ein Programm überprüft, ob die Struktur tatsächlich gültig ist.

< xargc > enthält die Anzahl der übergebenen Argumente, also genau den Wert, den man unter C als »arge« kennt.

< xargv > zeigt auf eine Tabelle von char-Pointern, die auf die übergebenen Parameter zeigen. Da diese Strings im Adreßbereich des aufrufenden Programms liegen, sollte der Startup-Code des aufgerufenen Programms zunächst einmal diese Daten in einen eigenen Puffer kopieren.

< xiovector > wird in der aktuellen Version des »xArg«-Verfahrens nicht benötigt.

< xparent > zeigt auf die Basepage des Programms, das die XARG-Struktur angelegt hat. Der Startupcode eines aufgerufenen Programms sollte also zunächst überprüfen, ob dieser Zeiger mit dem Wert des »Parent«-Zeigers in der eigenen Base-Page übereinstimmt; anderenfalls waren die Informationen in der XARG-Struktur für ein anderes Programm bestimmt. Offensichtlich ist dieses Verfahren nur dann interessant, wenn man entweder besonders lange oder besonders komplizierte Kommandozeilen benutzen will. Sonst reicht die »normale« Methode aus. Der Startup-Code eines Programms muß natürlich zu der Standardmethode kompatibel sein. Das heißt, er darf die XARG-Informationen nur dann auswerten, wenn die Environment-Variable vorhanden ist, tatsächlich eine XARG-Struktur an der entsprechenden Stelle im Speicher steht, und der Basepage-Zeiger korrekt ist.

C-Sourcen sind Public Domain

Komplette C-Sourcecodes zu dieser Methode findet man übrigens in der C-Library »dLibs«, die der Autor freundlicherweise als Public Domain veröffentlicht hat und die man sich aus verschiedenen deutschen Mailboxen »downloaden« kann.

Die Chancen, die dieses Verfahren bietet, sind natürlich in erster Linie für Programmierer von Kommandozeilen-gesteuerten Programmen und Shells interessant. Aber wer weiß — vielleicht kennt die nächste Version des Desktop auch schon »xArg«? (uh)

typedef struct
{ char xarg_magic[4];
  int xargc;
  char **xargv;
  char *xiovector;
  PD *xparent;
} XARG;

Julian F. Reschke
Aus: ST-Magazin 07 / 1988, Seite 70

Links

Copyright-Bestimmungen: siehe Über diese Seite