Zum 25. Mal: unser Atarium

Ein Fehler im VDI, Neues über Accessories und über die erweiterte Kommandozeile

Volle 25 Monate sind vergangen, seitdem ich mit dieser Kolumne begonnen habe - also sozusagen eine Jubiläumsnummer. In den letzten beiden Jahren gab es zwar wenig neue und vor allem erhältliche Hardware, aber der Software-Support seitens Atari hat sich spürbar verbessert. Dennoch läßt er nach wie vor viel zu wünschen übrig. Hoffen wir, daß der Aufwärtstrend anhält. Trotz runder Nummer gibt es auch diesen Monat den gewohnten Mix mit guten Tips und Neuigkeiten; schließlich soll der Platz zum Nutzen aller ST-Programmierer verwendet werden.

Nach mehreren Rückfragen unsererseits hat Atari-Programmierer Ken Badertscher über das Usenet erneut ein paar Dokumentationslöcher gestopft [1, 2]. Da wäre zunächst das bis heute offene Problem der Übergabe von erweiterten Kommandozeilen. Bekanntlich sind Sie bei der bekannten GEMDOS-Kommandozeile (in der Basepage) auf 125 Zeichen beschränkt. Dies ist besonders bei Linkern oder Archiv-Programmen wie etwa »Zoo« oder »Arc« ein großes Ärgernis. Ferner kann das aufgerufene Programm nicht mit legalen Mitteln feststellen, unter welchem Dateinamen es aufgerufen wurde - eine Sache, die beispielsweise viele Unix-Utilities gerne nutzen.

Abhilfe schaffen verschiedene Methoden, die die Parameter über einen anderen Mechanismus übergeben. Eine davon stammt von der Mark-Williams-Shell. Das Programm »dLibs« von Dale Schumacher verwendet ein weiteres Verfahren. Dieses wurde auch kurzfristig von Atari selbst favorisiert und an dieser Stelle vor geraumer Zeit vorgestellt [3].

Nach längerer Diskussion kristallierte sich jedoch heraus, daß keine der beiden Seiten zu Kompromissen bereit war (siehe auch in [4]). Ken Badertscher hat nun deshalb eine völlig neue Methode vorgeschlagen, die zwar zu keiner der beiden anderen kompatibel ist, dafür aber die meisten Vorteile bietet. Dieses Verfahren ist ab sofort Atari-Standard, und Shell-Autoren wie etwa Hersteller von Compilern tun gut daran, sich schnell an die neuen Gegebenheiten anzupassen. Eine kurze Beschreibung des neuen Verfahrens finden Sie im Textkasten - der vollständige Originaltext von Ken Badertscher ist bei Atari und in verschiedenen Mailboxen erhältlich.

Was bin ich - Accessory oder Programm?

Mittlerweile gibt es viele Programme, die sich durch einfaches Umbenennen sowohl als Programm als auch als Desk-Accessory benutzen lassen. Dazu muß ein Programm während seiner Initialisierung feststellen, wie es gestartet wurde. Fast alle Programmierer machen sich dabei die Tatsache zunutze, daß bei Accessories der Zeiger auf den aufrufenden Prozeß (p_parent in der Basepage) Null ist. Das Problem ist allerdings, daß ein Accessory auf legale Weise seine Basepage gar nicht finden kann.

Denn Accessories bekommen bei der Initialisierung den Basepage-Zeiger eben nicht als Parameter auf dem Stack. Daher gehen Accessories einfach davon aus, daß die Basepage immer 256 Byte vor dem Programmbeginn liegt - eine nicht gerade saubere Lösung. Doch nun hat Atari offiziell dokumentiert, daß beim Start von Accessories das Register a0 den Basepage-Zeiger enthält und beim normalen Programmstart Null ist. Damit ist auch dieses Problem beseitigt.

Fataler Fehler im »v_opnvwk()«

Schließlich möchte ich noch auf einen Fehler im VDI hinweisen, der offenbar nur unter TOS 1.0 und TOS 1.4 auftritt: Prinzipiell ist die Anzahl der virtuellen Workstations, die Sie benutzen können, nur durch den freien Speicher begrenzt. Und mehrere Workstations gleichzeitig zu benutzen, lohnt sich und hilft Ihnen Zeit zu sparen, wenn Sie häufig zwischen bestimmten Ausgabe-Attributen hin- und herschalten. Das VDI verwaltet die Workstations als verkettete Liste, wobei in jedem einzelnen Eintrag die Nummer der Workstation vermerkt ist. Beim Öffnen einer Workstation geht das VDI nun fatalerweise davon aus, daß es innerhalb der Tabelle keine Lücke gibt - und eine solche Lücke entsteht beispielsweise, wenn Sie etwa drei Workstations öffnen und dann die zweite wieder schließen (siehe Beispielprogramm im Listing). In der Folge liefert dann das VDI bei jeder »Open Virtual Workstation« die gleiche Handle-Nummer zurück. Dies führt dazu, daß das VDI effektiv nur für eine Workstation Attribute verwaltet.

Was Sie dagegen tun können? Zunächst sollten Sie eine Workstation nur dann wieder schließen, wenn Sie sich sicher sind, daß dabei keine solche Lücke entsteht. Das Beispielprogramm demonstriert, daß das VDI nach dem Entstehen der Lücke immer wieder dieselbe Handle-Nummer benutzt. Bei Verwendung eines anderen Bildschirm-Treibers - beispielsweise einen der Matrix-Bildschirm-Treiber - tritt der Fehler hingegen nicht auf. Aber: Gefahr erkannt, Gefahr gebannt. Wenn Sie selbst ein wenig aufpassen, schlägt der Fehler nicht so leicht zu.

(ba)

Quellennachweis:

[1] Ken Badertscher, »GEMDOS Extended Argument (ARGV) Specification«, aus: Info-Atari 16 Digest 595/89, (2. November 1989)

[2] Ken Badertscher, »Am I a DA?«, aus: Info-Atari 16 Digest 597/89, (2. November 1989)

[3] Julian Reschke, »Schranken durchbrechen.«, ST-Magazin 7/1988

[4] Julian Reschke, »Atari mit neuem Schwung«, ST-Magazin 5/1989

Listing. Dieses Beispiel demonstriert den Fehler im VDI

/* Beispielprogramm zum Workstation-Fehler im VDI */
/* in Turbo-C                                     */
#include <vdi.h>
#include <aes.h>
#include <stdio.h>

void main (void)
{
	int workin[] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2};
	int workout[57], handle[4], i, d, aeshandle;

	appl_init();
	aeshandle = graf_handle (&d, &d, &d, &d);
	for ( i = 0; i < 3; i++)
	{
		handle[i] = aeshandle;
		v_opnvwk (workin, &handle[i], workout);
	}

	v_clsvwk (handle[1]);
	handle[1] = aeshandle;
	v_opnvwk (workin, &handle[1], workout);
	handle[3] = aeshandle;
	v_opnvwk (workin, &handle[3], workout);

	for ( i = 0; i < 4; i++)
	{
		printf („close handle: %d\n“, handle[i]);
		v_clsvwk (handle[i]);
	}
	appl_exit();
}

Die neue Spezifikation

Die Übergabe der erweiterten Kommandozeile erfolgt über das Environment. Die Environmentvariable ARGV zeigt an, daß dieses Verfahren benutzt wird. ARGV kann einen beliebigen Wert haben - allein seine Anwesenheit ist entscheidend. ARGV muß die letzte Environmentvariable sein, damit das aufgerufene Programm im Stande ist, den »vorderen« Teil als sein Environment weiterzubenutzen.

Die erweiterte Kommandozeile schreiben Sie als Folge von nullterminierten Strings hinter ARGV ins Environment. Der erste String, der dem bislang nicht benutzten ARGV[0] entspricht, enthält den Namen des gestarteten Programms, so wie Sie ihn auch an Pexec() übergeben. Die weiteren Strings enthalten die einzelnen Parameter, die auch Leerzeichen enthalten dürfen. Das Ende der Liste kennzeichnen Sie durch eine doppelte Null, so wie bei einem normalen Environment.

Zusätzlich übergeben Sie bei Pexec() den Wert 127 als Längen-Byte, das ist das erste Byte in der Kommandozeile. Dieser Wert wurde wegen der existierenden Längenbeschränkung auf 125 Byte bislang nicht angenommen. Der Längenwert 127 erlaubt es dem aufgerufenen Programm festzustellen, ob die im Environment übergebenen Werte auch tatsächlich gültig sind und nicht etwa von einem Programm stammen, das den ARGV-Standard nicht kannte.

ARGV richtig übergeben

Um mit ARGV einem Programm Parameter zu übergeben, müssen Sie zunächst ein neues Environment für das aufzurufende Programm anlegen. Dazu berechnen Sie beispielsweise die Länge des bereits vorhandenen Environments, addieren die Länge der Kommandozeile und reservieren entsprechend viele bytes. Dann kopieren Sie das bestehende Environment und hängen die neue Variable ARGV und die Kommandozeilen-Parameter nullterminiert an. Eine letzte Null schließt dann das Environment legal ab. Beim Aufruf mittels Pexec() übergeben Sie im Längen-Byte der Kommandozeile den Wert 127.

ARGV richtig abfragen

Zunächst müssen Sie als aufgerufenes Programm überprüfen, ob im Environment die ARGV-Variable vorkommt, und ob das Kommandozeilen-Längenbyte 127 ist. Ist dies der Fall, dann Finden Sie nach der ersten Null nach »ARGV« (denn ARGV kann ja einen Wert haben) die einzelnen Kommandozeilen-Parameter. Nachdem Sie oder der Startup-Code den Argumentzeiger (in C: argv[i]) gesetzt haben, sollten Sie noch den ersten Buchstaben von »ARGV« auf Null setzen. Nun hat das Environment wieder die Standardform.

Fazit

Das ARGV-Verfahren ist leichter zu verwenden als die xArg-Methode von Dale Schumacher, bei der außerdem das Child-Programm Daten direkt aus dem Parent lesen muß. Gegenüber der Mark-Williams-Methode ist die eigentliche Erkennung der erweiterten Kommandozeile vernünftig implementiert. Einen Quelltext als Beispiel zum Starten von Programmen und für den Startup-Code des gestarteten Programms finden Sie in [1].


Julian F. Reschke
Aus: ST-Magazin 01 / 1990, Seite

Links

Copyright-Bestimmungen: siehe Über diese Seite