Saubere Fenster: Softwareprobleme mit Ganzseitenbildschirmen

Als vor über drei Jahren die ersten ST-Entwicklungssysteme Deutschland erreichten, lagen zwar etwa 3000 Seiten Dokumentation dabei, jedoch blieben viele Aspekte des Betriebssystems bis heute schlecht dokumentiert oder wurden gar nicht durchdacht. Man bemerkt es immer wieder, wenn man Software unter »Extrembedingungen« testet.

Was die Software-Abteilung von Atari offenbar zu leisten nicht bereit ist, haben seit einiger Zeit unabhängige Programmentwickler übernommen — man denke beispielsweise an das »XARG«-Verfahren von Dale Schumacher, über das wir vor drei Monaten [1] berichteten und das mittlerweile auch von der Command-Shell »Master V5.4« verstanden wird. Diesen Monat wollen wir wiederum eine Methode vorstellen, die die reibungslose Zusammenarbeit von Programmen erleichtern soll: das »XBRA-Protokoll zur Verwaltung vektorverbiegender Programme«.

Das XBRA-Protokoll

Speicherresidente Utilities, die Systemvektoren »verbiegen«, haben zwei Probleme:

• Sie können den veränderten Vektor gar nicht oder schwer auf den ursprünglichen Wert zurücksetzen, da sich ja unter Umständen zwischenzeitlich ein anderes Programm in den gleichen Vektor eingeklinkt hat.
• Aus dem gleichen Grund können sie nur schwer überprüfen, ob sie bereits installiert sind.

Das hier vorgeschlagene XBRA-Verfahren (extended BRAner) [3] geht auf die Idee des amerikanischen Programmierers Moshe Braner (Autor von »GNOME«) zurück, die wir in einem Punkt etwas erweitert haben.

Jedes vektorverbiegende Programm plaziert direkt vor seiner eigenen Einsprungadresse (also genau vor der Adresse, auf die der Vektor gesetzt wurde) folgende C-Struktur:

typedef struct
{
	char xb_magic[4];
	/* "XBRA" = 0x58425241 */
	char xb_id[4];
	/* Indentifikations code des instal lierten Programms */ 
	long xb_oldvec;
	/* ursprünglicher Wert des Vektors */
} XBRA;

Zunächst überträgt man den geretteten Inhalt des betreffenden Systemvektors in »xb_oldvec«.»xb_id« sollte eine Identifikationsnummer des installierten Programms enthalten, Konvention ist dabei eine vierstellige Zeichenkette (beispielsweise »CACH« für einen Hard-Disk-Cache). Mittels dieser Konstante überprüft man dann in eigenen Programmen, ob die Routinen bereits installiert sind.

»xb_magic« ist die besagte, von uns vorgenommene Erweiterung der Braner-Methode, mit deren Hilfe man erst hunderpro-zentig sicherstellt, daß an der betrachteten Stelle im Speicher eine XBRA-Struktur steht. Mittels der XBRA-Methode installierte Programme stellen mit Leichtigkeit fest, ob sie bereits installiert sind und sind auch wieder einfach aus der Vektorkette zu entfernen. Wir hoffen, daß alle Programmierer in Zukunft beim Schreiben eigener Programme diesen Vorschlag beherzigen.

Wo ist der EST?

Viele Besucher der gerade beendeten Atari-Messe in Düsseldorf haben vermutlich den von uns in der August-Ausgabe [4] getesteten Doppel-Ganzseitenmonitor der Firma Matrix bewundert. Der Haken an dieser imponierenden Hardware: Leider gibt es nur ganz wenig Software, die die erhöhte Auflösung nutzt — ganz zu schweigen von den Programmen, die überhaupt nicht laufen. Es ist sicherlich keine allzu gewagte Behauptung, daß Atari aus genau diesem Grund bis heute den EST nicht vorgestellt hat. Vereinfacht lautet die Problematik: »Gibt es keine geeignete Software, weil es bislang die Hardware nicht gab — oder wurde die Hardware deshalb nicht gebaut, weil sowieso keine geeignete Software zur Verfügung steht?«

Nun ist eine variable Bildschirmauflösung ja kein unbedingt neues Problem: Bereits die drei verschiedenen Auflösungen des ST machen den Software-Entwicklern genug Probleme. Im folgenden ein paar Faustregeln, die das Entwerfen von der Bildauflösung unabhängiger Programme erleichtern.

Am einfachsten hat man es sicherlich, wenn man durchgängig unter GEM programmiert. Aber selbst Programme, die auch unter PC-GEM laufen, wie beispielsweise Adimens oder 1st Word plus, haben ihre Probleme. Ein paar Tücken gibt es allerdings doch:

• beim Öffnen eigener Fenster sollte man auch — soweit sinnvoll — den gesamten zur Verfügung stehenden Platz auf dem Bildschirm nutzen. Wer sich nicht darauf einstellt, daß das Fenster plötzlich 1000 x 1000 Punkte groß wird, sollte wenigstens sicherstellen, daß dieser Fall nicht auftritt (nach der »WM_SIZED«-Mitteilung die Bildschirmgröße überprüfen). Programme, bei denen man stets mehrere Fenster nutzt, sollten auch Fensterpositionen und -großen speichern.
• möchte man Objekte am unteren Bildschirmrand positionieren, dann sollte man als Koordinaten immer negative Offsets von der Bildschirmhöhe verwenden, andernfalls ergeht es einem wie bei »1st Word plus«, das seine Iconleiste bei einer Ganzseitendarstellung in der Bildschirmmitte plaziert.
• ein weit verbreitetes Problem sind Dialogboxen, die zwar sauber zentriert werden (mit »form_center()«), dann allerdings nur unvollständig auf dem Bildschirm erscheinen, weil man beim »objc_draw()« -Befehl einen zu kleinen Bildausschnitt als Begrenzungsrechteck angegeben hat.
• wer mit »COPY RASTER FORM« arbeitet, sollte immer an den Unterschied zwischen dem »Standardformat« und dem »gerätespezifischen Format« denken. Bei mit dem Kitachi-Grafikchip arbeitenden Farbgrafik karten (Omega, Matrix) ist der Bildschirm nämlich ganz anders organisiert, als gewohnt. Man denke daran, daß bei Raster-Operationen auf dem Bildschirm in der MFDB-Struktur ein Nullpointer als Bildanfangsadresse übergeben werden sollte. Das VD1 trägt dann selbständig alle Werte korrekt ein.

Offset	Name	Typ	Belegung
-$002	BYTES_LIN	Word	Bytes pro Bildschirmzeile
-$004	V_REZ_VT	Word	vertikale Auflösung in Pixeln
-$00C	V_REZ_HZ	Word	horizontale Auflösung in Pixeln
-$028	V_REZ_WR	Word	Bytes pro Character-Zeile
-$02A	V_CEL_MY	Word	maximale Cursorzeile
-$02C	V_CEL_MX	Word	maximale Cursorspalte
-$02E	V_CEL__HT	Word	Zeichenhöhe des Systemzeichensatzes
-$2B4	DEV_TAB	Words	die 45 Werte, die man bei ’v_opnvwk()’ erhält
-$30E	INQ_TAB	Words	die 45 Werte, die man bei ’vq_extnd()’ erhält

Tabelle. Eine Auswahl der nützlichsten Adressen im negativen Line-A-Bereich

Vorbild: schnelle GEM-Programme

• die WORKSTATION-Parameter berücksichtigen: Bei »v_opnvwk()« erhält man nicht nur die Auflösung, sondern auch Pixelgröße und Anzahl der Farben zurück! — wer mittels »wind_set()« einen eigenen Desktop-Menübaum setzt, sollte auch daran denken, ihn an die tatsächliche Bildschirmauflösung anzupassen!

Auch wer glaubt, an GEM vorbei programmieren zu müssen, kann sich selbst mit allen Informationen über den verwendeten Bildschirm versorgen. Seit einiger Zeit sind nämlich die berüchtigten »negativen« Line-A-Variablen offiziell dokumentiert [3,5]. Vor der Manipulation dieser Adressen warnen wir allerdings — man sollte sie wirklich als »READ ONLY« betrachten! Eine Auswahl der in diesem Zusammenhang interessanten Adressen sehen Sie in der Tabelle. Sowohl TOS-Anwendungen (beispielsweise »microEmacs 2.19«) als auch grafische Anwendungen mit eigenen Ausgabetreibern (»Calamus«) greifen auf diese Adressen zu, um sich dem verwendeten Bildschirm anzupassen. Wer es nicht tut, muß mit Resultaten wie bei »Tempus« oder »Signum« rechnen (wer davon ausgeht, daß eine Bildschirmzeile immer maximal 80 Zeichen breit ist, braucht sich nicht zu wundern…).

Dennoch sei nochmals darauf hingewiesen, daß es in den allermeisten Fällen völlig überflüssig ist, den sauberen Weg über das VDI zu verschmähen. Viele Programme demonstrieren immer wieder, daß man bei geschickter Programmierung auch unter GEM schnelle Programme schreibt, man denke zum Beispiel an den Editor von Turbo-C, DEM-Draw oder Campus-CAD.

Wir sparen 5000 Mark

Soweit die graue Theorie — doch was nützt das alles ohne eine Gelegenheit zum Testen? Selbst die Tatsache, daß ein Programm in der PC-Version auf den abenteuerlichsten Grafikkarten läuft, garantiert nicht, daß es sich auch auf dem ST richtig verhält — das liegt an geringfügigen Unterschieden in den GEM-Implementationen (diese schmerzliche Erfahrung mußten die Adimens-Programmierer mit ihrer ansonsten vorbildlichen programmierten GEM-Oberfläche machen...)

Nicht jeder kann sich eine Grafikkarte samt Ganzseitenmonitor leisten — als Ausweg bietet sich, wie so oft, die Emulation an:

In der nächsten Ausgabe finden Sie ein Programm zur Emulation einer (fast) beliebigen Auflösung auf Ihrem Monitor, mit dem Sie Ihre Software austesten können! Besonders professionelle Programmierer werden ihre helle Freude daran haben.

Und zum Abschluß noch eine brandheiße Meldung aus Raunheim: Die »Freigabe« der neuen TOS-Version wird pünktlich zur Atari-Messe erwartet! Hoffentlich müssen wir nicht allzu lange auf die ersten ROMs warten.

(uh)

Quellennachweis:

[1] Julian Reschke: »Schranken durchbrechen«, ST-Magazin 7/1988

[2] Axel Pretzsch: »Programmieren in guter Atmosphäre«, ST-Magazin 5/1988

[3] Jankowski/Rabich/Reschke: »Das Atari ST Profibuch«, 5. Auflage, Sybex Düsseldorf 1988, ISBN 3-88745-501-0

[4] Wolfgang Fastenrath: »Über-Sicht«, ST-Magazin 8/1988

[5] Mark Jansen: »S.A.L.A.D. — Still another Line A document«, Atari Corporation 1987

Julian F. Reschke

---

---