Unter einem Hut: MiNT/MultiTOS, MagiX! und Geneva

Mit MagiX! 2.0 und Geneva ist MultiTOS eine ernsthafte Konkurrenz erwachsen. Zwar lassen beide Systeme die in MultiTOS integrierten Funktionen von MiNT vermissen, dafür profitiert der Anwender durch die, verglichen mit MultiTOS, höhere Geschwindigkeit. Doch wie stellen sich MagiX! und Geneva aus der Sicht des Programmierers dar, wenn es um die Aufrufkompatibilität geht?

Wenn ich diese Frage im Rahmen des vorliegenden Artikels für Geneva weniger erschöpfend behandeln kann als für MagiX!, liegt das daran, daß Geneva in den Staaten bereits seit einigen Monaten erhältlich ist, in Deutschland aber offenbar (noch) nicht vertrieben wird. Kurz nach Redaktionsschluß erreichte mich per Zufall ein Exemplar von Geneva 1.01, für einen ausführlichen Test blieb jedoch keine Zeit mehr. Dennoch möchte ich gegen Ende einige Hinweise zu Geneva geben.

Die Kompatibilitätsfrage hat seit dem Erscheinen von MagiX! in der Version 2.0 des öfteren zu Unstimmigkeiten geführt. Auch im Hinblick auf Geneva wird jeder Programmierer prüfen müssen, ob sich seine Anwendungen wirklich streng an den Richtlinien orientieren. Weder MagiX! noch Geneva stellen ungewöhnliche Anforderungen an die Software. Es sind lediglich einige wenige Regeln zu beachten, die nicht speziell eines dieser beiden Systeme betreffen, sondern grundsätzlich beherzigt werden sollten, um korrekt auf Neuerungen des Betriebssystems zu reagieren. Dabei spielt es keine Rolle, ob es sich wie bei MagiX! um ein gänzlich neu programmiertes System handelt oder lediglich um einen Aufsatz wie Geneva oder auch WINX.

Im Visier: GEMDOS und AES

Zunächst muß man sich vor Augen führen, daß sich die Systemerweiterungen, wie sie MultiTOS, MagiX! und Geneva bieten, in erster Linie auf zwei Ebenen befinden. MiNT als fester Bestandteil von MultiTOS stellt eine Reihe neuer GEMDOS-Funktionen bereit. Die Neuerungen im MultiTOS-AES sind in der Datei GEM.SYS untergebracht, die beim Starten von MultiTOS automatisch von MiNT nachgeladen wird. Das AES von MagiX! 2.0 bietet nur eine Untermenge der bei MultiTOS vorhandenen Neuerungen und trägt die Versionsnummer 3.99. Unter Geneva stehen immerhin alle Funktionen des AES 4.0 zur Verfügung, also beispielsweise auch die von MultiTOS unterstützten Submenüs. Neue GEMDOS-Funktionen, wie sie von MiNT bereitgestellt werden, bieten bisher weder Geneva noch MagiX!. Einige MiNT-kompatible Aufrufe sind zumindest für MagiX! bereits in Arbeit und für zukünftige Versionen zu erwarten.

Die Kunst der Programmierung besteht in unserem Fall also darin, flexibel auf die vorhandenen Möglichkeiten des GEMDOS und des AES zu reagieren. Dabei ist der Wunsch naheliegend, möglichst wenige Analysen der Systemumgebung durchführen zu müssen und auch auf die Abfrage von Versionsnummern weitestgehend zu verzichten. Bei umsichtiger Programmierung gelingt es in der Tat, mit minimalem Aufwand maximale Kompatibilität zu allen MiNT/TOS-Versionen sowie MagiX! und Geneva zu erzielen.

GEMDOS ist wählerisch

Besonders einfach läßt sich im Falle des GEMDOS feststellen, ob eine bestimmte Funktion unterstützt wird. Grundsätzlich läßt sich über den Aufruf von Sversion() die GEMDOS-Versionsnummer ermitteln, aus der sich dann Schlüsse über die verfügbaren GEMDOS-Funktionen ziehen lassen. Auch wenn diese Vorgehensweise auf der Hand liegt, ist sie nicht die Methode der Wahl. Wurde durch ein residentes Programm ein altes GEMDOS so erweitert, daß beispielsweise der erst ab TOS 2.0 verfügbare Mxalloc()-Aufruf nachgebildet wurde, führt die Verwendung von Sversion() zum falschen Schluß, Mxalloc() werde nicht unterstützt.

Daher macht es Sinn, auf Sversion() zu verzichten und statt dessen die gewünschte Funktion mit Dummy-Parametern aufzurufen und den GEMDOS-Fehlercode zu überprüfen. Erhält man ein EINVFN (-32L) zurück, ist ein GEMDOS-Aufruf nicht verfügbar, andernfalls wird er unterstützt. Diese Vorgehens weise läßt sich bei jeder TOS-Version an wenden, da das Verhalten des GEMDOS bei der Übergabe ungültiger Funktionsnummern dokumentiert ist. (Dies ist beim BIOS und XBIOS leider nicht der Fall!) Der Vorteil dieses Verfahrens gegenüber der Abfrage von GEMDOS-Versionsnummern oder der cookies von MiNT (MiNT), MagiX! (MagX) und Geneva (Gnva) liegt darin, daß es keine Rolle spielt, welches Betriebssystem vorliegt und welche Systemerweiterung installiert ist. Man erhält in jedem Fall die gewünschte Information und kann gewiß sein, den Programmcode an dieser Stelle zukunftssicher ausgelegt zu haben.

Was Mxalloc() betrifft, sollte man übrigens stets darauf achten, die unter MiNT und MagiX! verfügbaren erweiterten Modi ausschließlich unter eben diesen Systemen aufzurufen. Bei anderen (Single-Tasking)Systemversionen ist andernfalls mit einem Absturz zu rechnen.

Flexibilität ist Trumpf

Anhand der soeben beschriebenen Methode gelingt es auch, solche GEMDOS-Aufrufe zu erfassen, deren Verfügbarkeit nicht über Sversion() ermittelt werden kann, weil sie kein integraler Bestandteil des GEMDOS sind. Hierzu zählen insbesondere alle GEMDOS-Funktionen, die von MiNT bereitgestellt werden. Die Anwesenheit von MiNT ändert nichts an der GEMDOS-Versionsnummer, so daß sich mittels Sversion() keine Informationen darüber gewinnen lassen, ob MiNT-kompatible Funktionen vorhanden sind. Zwar ist es denkbar, sich anhand des MiNT-cookies und der MiNT-Version kundig zu machen, aber ein Probeaufruf der benötigten GEMDOS-Funktionen ist die elegantere Lösung, da sie ohne die Abfrage irgendwelcher Versionsnummern auskommt.

In der Praxis macht sich das beispielsweise dann positiv bemerkbar, wenn ein Programm den Aufruf Dlock() unterstützen soll, mit dem sich Laufwerke ab MiNT 0.96 selektiv für den Zugriff per GEMDOS sperren lassen. Nun wäre es kurzsichtig, die Verwendung von Dlock() davon abhängig zu machen, ob und wenn welches MiNT installiert ist. Dlock() wird in Zukunft nämlich auch von MagiX! unterstützt werden, so daß die Verwendung dieser Funktion nicht auf dem Vorhandensein des MiNT-cookies basieren sollte. Außerdem ist es nicht auszuschließen, daß es einmal ein residentes Programm geben wird, das Dlock() unabhängig von MiNT und MagiX! auf jeder TOS-Version unterstützt. (Das Programm CHK_OFLS von Hansi Richstein übernimmt bereits eine ähnliche Funktion wie Dlock().) Wird die Verfügbarkeit von Dlock() jedoch anhand des GEMDOS-Fehlercodes ermittelt, ist man für alle Eventualitäten gewappnet.

Das AES auf dem Präsentierteller

Bereits vor dem Erscheinen von MagiX! 2.0 zeichnete sich ab, daß die neue MagiX!-Version nicht alle Funktionen bieten wird, wie sie beim AES 4.0 des MultiTOS zur Verfügung stehen. Insbesondere die Unterstützung von Submenüs, wie sie bei MultiTOS existiert, sucht man bei MagiX! im Gegensatz zu Geneva vergeblich. Die wenigsten Programmierer dürften diese Funktionen aber bisher vermißt haben, denn in der Regel ist man ohnehin gezwungen, eigene Menüroutinen zu verwenden, damit ein Programm auch unter Standard-TOS Submenüs bieten kann.

Anhand der AES-Versionsnummer, wie sie nach appl_init() aus dem global-Array ausgelesen werden kann, ist lediglich eine recht grobe Einteilung der AES-Funktionalitäten möglich. Nun sind die neuen und geplanten Erweiterungen in MultiTOS und MagiX! aber sehr vielfältig, und daher war ein neues Verfahren erforderlich, mit dem sich gezielt die Verfügbarkeit einzelner Funktionen erfragen läßt. ATARI zeigte sich hier kooperativ, und so einigten sich Eric Smith (MiNT, MultiTOS) und Andreas Kromke (MagiX!) darauf, ab AES 4.1 den bereits im AES 4.0 eingeführten Aufruf appl_getinfo() kräftig zu erweitern. Die neue Form des appl_getinfo() wird unter MultiTOS bisher nur in den Betaversionen unterstützt, MagiX! bietet diese Funktion seit Version 2.0.

Eigentor?

Mit Hilfe des erweiterten appl_getinfo() läßt sich prinzipiell die Verfügbarkeit neuer AES-Aufrufe feststellen, ohne daß dazu eine Abfrage irgendwelcher Versionsnummern oder eine Unterscheidung zwischen MultiTOS und MagiX! notwendig wäre. Systemabhängig programmiert werden muß lediglich ein einziges Mal, nämlich dann, wenn es darum geht, das Vorhandensein des neuen appl_getinfo() festzustellen.

Funktion 0: Informationen über den normalen AES-Zeichensatz
Wort 1 Fonthöhe
Wort 2 Font-ID
Wort 3 Font-Typ (0=system. 1=FSM)

Funktion 1: dito für den kleinen Zeichensatz

Funktion 2: Farben
Wort 1 VDI-Geratenummer (device id)
Wort 2 Farben fur OBJECTS
Wort 3 Farbicons vorhanden (1) bzw. nicht (0)
Wort 4 neues RSC-Format vorhanden (1) oder nicht (0)

Funktion 3: Sprache
Wort 1:

• 0 - Englisch
• 1 - Deutsch
• 2 - Französisch
• 3 - reserviert
• 4 - Spanisch
• 5 - Italienisch
• 6 - Schwedisch

Funktion 4. allgemeine Information Nr 1
Wort 1 Multitasking präemptiv (1) oder nicht (0)
Wort 2 appl_find konvertiert MiNT und AES-IDs (1) oder nicht (0)
Wort 3 appl_search vorhanden (1) oder nicht (0)
Wort 4 rsrc_rcfix vorhanden (1) oder nicht (0)

Funktion 5. allgemeine Information Nr. 2
Wort 1 objc_xfind vorhanden (1) oder nicht (0)
Wort 2 reserviert, immer 0
Wort 3 menu_click (GEM/3 + MagX!) vorhanden (1) oder nicht (0)
Wort 4 shel_r/wdef (GEM/3 + MagX!) vorhanden (1) oder nicht (0)

Funktion 6: allgemeine Information Nr 3
Wort 1 appl_read(-1) vorhanden (1) oder nicht (0)
Wort 2 shel_get(-1) vorhanden (1) oder nicht (0)
Wort 3 menu_bar(-1) vorhanden (1) oder nicht (0)
Wort 4 menu_bar(MENU_INSTL) (MagX!) vorhanden (1) oder nicht (0)

Funktion 7: reserviert für MagX! und andere Erweiterungen, MultiTOS setzt alle Rückgabewerte immer auf 0

Funktion 8 Maus
Wort 1 graf_mouse-Modi 258-260 vorhanden (1) oder nicht (0)
Wort 2 Mausform vom AES für jede App verwaltet (1) oder nicht (0)

Funktion 9 Menüs
Wort 1 MultiTOS-Submenüs vorhanden (1) oder nicht (0)
Wort 2 MultiTOS-Popups vorhanden (1) oder nicht (0)
Wort 3 MultiTOS-Scrollmenüs vorhanden (1) oder nicht (0)
Wort 4 erweiterte MN_SELECTED-Nachricht vorhanden (1) oder nicht (0)

Funktion 10: shel_write
Wort 1 vorhandene Modi:
Bit 0, 7 höchster zulässiger Wert für sh_wdoex & 0x00ff
Bit 8, 15 Bits von sh_wdoex & 0xff00 die wie in MultiTOS behandelt werden
Wort 2
1 shel_write(0) macht vorherige shel_write- Aufrufe ungültig (d h das Desktop wird Nachfolgeprogramm) (TOS 1.4 & MagX!)
0 startet Programm (MultiTOS)
Wort 3
1: shel_write(1) startet Programm nach Beendigung des laufenden (TOS 1 4 & MagX!)
0: startet Programm sofort (MultiTOS)
Wort 4 ARGV via sh_wiscr unterstützt (1) oder nicht (0)

Funktion 11 Fenster
Wort 1 gesetzte Bits signalisieren unterstützte Funktionen
Bit 0 WF_TOP liefert zweitoberstes Fenster
1: wind_get(WF_NEWDESK)
2: wind_g/set(WF_COLOR)
3: wind_g/set(WF_DCOLOR)
4: wind_get(WF_OWNER)
5: wind_g/set(WF_BEVENT)
6: WF_BOTTOM
7: WF_ICONIFY
8: WF_UNICONIFY
9, 15: reserviert, immer 0
Wort 2 reserviert, 0
Wort 3 vorhandene Fensterbuttons:
Bit 0 Iconifier
1: Backdrop-Button (MagX!)
2: Shift-Click für Backdrop
3: ..Hot Closebox (GEM/3 & MagX!)
4...15: reserviert, 0
Wort 4: wind_update check_and_set vorhanden (1) oder nicht (0)

Funktion 12 Nachrichten
Wort 1 gesetzte Bits signalisieren unterstützte Nachrichten
Bit 0: WM_NEWTOP
1: WM_UNTOPPED
2: WM_ONTOP
3: AP_TERM
4: MultiTOS-Auflösungswechsel
5: CH_EXIT
6: WM_BOTTOM
7: WM_ICONIFY
8: WM_UNICONIFY
9: WM_ALLICONIFY
Wort 2 reserviert, alle 0
Wort 3 WM_ICONIFY liefert Koordinaten (1) oder nicht (0)

Funktion 13 OBJECTS
Wort 1 3D- Objekte über ob_flags vorhanden (1) oder nicht (0)
Wort 2 objc_sysvar vorhanden (1) oder nicht (0)
Wort 3 Speedo- und GDOS-Fonts im TEDINFO erlaubt (1) oder nicht (0)
Wort 4 reserviert für MagX!, wird von MultiTOS auf 0 gesetzt
Bit 0: G_SWBUTTON vorhanden
1: G_POPUP vorhanden
2: WHITEBAK steuert Unterstriche und Buttons

Funktion 14. Formulare (MagX! form_do und form_xdial)
Wort 1 MagX!-Flydials vorhanden (1) oder nicht (0)
Wort 2 MagX!-Tastaturtabellen vorhanden (1) oder nicht (0)
Wort 3 letzte Cursorposition wird zurückgegeben (1) oder nicht (0)
Wort 4 reserviert, 0

Tabelle: appl_getinfo() liefert beim AES 4.1 wichtige Informationen über die erweiterten AES-Funktionen.

Wann ist appl_getinfo() in der ausführlichen Variante ansprechbar? Zunächst einmal dann, wenn das AES die Versionsnummer 4.1 oder neuer trägt. Dies ist momentan lediglich bei den Betaversionen von MultiTOS der Fall. Ist MagiX! installiert, hilft der Weg über die AES-Versionsnummer nicht weiter. Das MagiX!-AES trägt die Bezeichnung AES 3.99. was insofern verständlich ist, als MagiX! nicht alle Funktionen bietet, wie sie unter MultiTOS vorhanden sind, und daher nicht die Versionsnummer 4.0 vergeben werden durfte. Dummerweise findet man das AES 3.99 aber nicht nur unter MagiX! 2.0, sondern auch bei MagiX! 1.x, obwohl hier noch kein appl_getinfo() unterstützt wurde. Hier haben die Programmierer von MagiX! quasi ein Eigentor geschossen, denn zwei grundsätzlich verschiedene AES-Versionen besitzen bei MagiX! identische Versions-Levels. Allerdings sind laut Aussage der MagiX!-Autoren inzwischen nahezu alle MagiX!-Anwender auf die Version 2.0 umgestiegen, so daß es kaum mehr notwendig ist, MagiX! 1.1 in irgendeiner Form zu berücksichtigen. Dennoch kann es nützlich sein, eine Aussage über die MagiX!-Version gewinnen zu können.

Auf die AES-Version kommt es an

Der Weg zur MagiX!-Versionsnummer führt über den cookie „MagX“, der von MagiX! installiert wird. Der zugehörige Cookie-Parameter zeigt auf folgende Struktur:

typedef struct {
    long config_status; /* Konfigurationsdaten für MAGXCONF.CPX/ACC */ 
    DOSVARS *dosvars; /* Zeiger auf DOS-Variablen */ 
    AESVARS *aesvars; /* Zeiger auf AES-Variablen */
} MAGX_COOKIE;

Wichtig für unsere Zwecke ist, wie könnte es anders sein, der Zeiger auf die AES-Variablen, die eine weitere Datenstruktur darstellen:

typedef struct {
    long magic;     /* muß $87654321 sein */ 
    void *membot;   /* Ende der AES-Variablen */ 
    void *aes_start; /* Startadresse */ 
    long magic2;    /* ist ,MAGX' */ 
    long date;      /* Erstelldatum ttmm.jjjj */ 
    void (*chgres)(int res, int txt);   /* Auflösung ändern */ 
    long (**shel_vector)(void);         /* residentes Desktop */ 
    char *aes_bootdrv;  /* von hier aus wurde gebootet */ 
    int *vdi_device;    /* vom AES benutzter VDI-Treiber */ 
    void *reservd1; 
    void *reservd2; 
    void *reservd3; 
    int version; 
    int release;
} AESVARS;

Diese Angaben dürfen nur gelesen, nicht aber verändert werden. Die ersten drei Variablen sind auch unter Standard-TOS vorhanden und dort über den System-Header zugänglich. AESVARS ist erst nach dem Start des MagiX!-AES initialisiert, d.h., insbesondere Programme des Autoordners können auf diese Informationen nicht zugreifen. Der Zeiger aesvars ist in diesem Fall ein Null-Pointer.

Eine Anmerkung zu vdi_device: Die VDI-Gerätenummer für das AES läßt sich besser MultiTOS-kompatibel über appl_getinfo() erfragen. vdi_device sollte also nicht zu diesem Zweck verwendet werden.

version enthält die MagiX!-Versionsnummer im hexadezimalen Format. Für MagiX! 2.0 findet man die Angabe $0200.

Ein weiterer Weg

Das erweiterte appl_getinfo() stellt eine ganze Reihe an Informationen bereit. Es sind residente Programme denkbar, die das AES nur in ganz bestimmten Punkten erweitern und für die es praktisch wäre, die Rückgabewerte von appl_getinfo() in dieser Hinsicht zu ergänzen. Solche Programme stellen naturgemäß kein vollständiges Betriebssystem dar, können also nicht über eine AES-Versionsnummer erfaßt werden. Hier ist daher ein neuer, von der AES-Versionsnummer unabhängiger Mechanismus gefragt, damit andere Applikationen sich über die Verfügbarkeit von appl_getinfo() kundig machen können.

Ein für diesen Zweck brauchbares Verfahren wird seit einiger Zeit im Mausnetz diskutiert. Demnach steht das erweiterte appl_getinfo() selbst bei AES-Versionen < 3.99 dann zur Verfügung, wenn gilt:

appl_find("?AGI") == 0

Programme, die ein eigenes appl_getinfo() zur Verfügung stellen, müßten also dafür sorgen, daß ein appl_find() mit dem Parameter ?AGI den Wert 0 bzw. TRUE liefert. Die Autoren von MagiX! und WINX haben bereits signalisiert, dieses Verfahren in Zukunft zu unterstützen. Noch ist allerdings das letzte Wort nicht gesprochen.

Spezialitäten von MagiX! und WINX

MagiX! bietet gegenüber TOS einige Erweiterungen, die es erlauben, daß selbst Programme, die keine Besonderheiten von MultiTOS oder MagiX! nutzen, in den Genuß zusätzlicher Funktionen kommen. Dabei ziele ich insbesondere auf die Bedienung von Hintergrundfenstern sowie auf das Ausblenden von Prozessen ab. Fenster, deren Bedienelemente aktiv sind, obwohl sie im Hintergrund liegen, dürften wohl jedem Anwender ein Begriff sein, da sie nicht nur vom MagiX!-AES, sondern auch von MultiTOS und WINX unterstützt werden.

Das Ausblenden von Prozessen dagegen ist eine Funktionalität, die bisher lediglich unter MagiX! genutzt werden kann. Auf Wunsch sorgt MagiX! dafür, daß alle Fenster einer bestimmten Anwendung vom Bildschirm entfernt werden, obwohl diese Anwendung weiterhin im Hintergrund aktiv ist, also beispielsweise Berechnungen durchführen kann. Das Ausblenden hat einen ähnlichen Effekt wie die von anderen Rechnerplattformen bekannte Iconifizierung, wie sie auch für zukünftige MultiTOS-Versionen geplant ist.

Der Vorteil des Ausblendens von Prozessen bei MagiX! gegenüber einer Iconifizierung wie unter MultiTOS ist der, daß das Ausblenden ohne Mithilfe der jeweiligen Applikation vonstatten gehen kann. Die Iconifizierung hingegen erfordert eine Reaktion durch die Anwendung, ist also nur bei Programmen möglich, die darauf vorbereitet sind. Einige wenige Programme verhindern allerdings das Ausblenden ihrer Fenster dadurch, daß Fenster nur innerhalb des sichtbaren Bereichs zu liegen kommen können. Dies lag vielleicht nicht einmal in der Absicht der Programmierer. Dieselben Programme erlauben es in der Regel auch nicht, daß ihre Fenster unter WINX links aus dem Bildschirm herausgeschoben werden können.

Ausgetrickst

Woher dieses Verhalten rührt, läßt sich leicht nachvollziehen, wenn man sich den Trick vor Augen führt, den MagiX! zum Ausblenden von Fenstern einsetzt. Wird eine Anwendung ausgeblendet, verschickt MagiX! eine WM_MOVED-Nachricht für alle Fenster dieses Programms. Die neuen Fensterkoordinaten liegen dabei außerhalb des sichtbaren Bildschirms, was dazu führt, daß das Fenster nicht mehr zu sehen ist, sobald es an die von MagiX! vorgegebene Position verschoben wurde. Manche Anwendungen akzeptieren neue Fensterkoordinaten aber nur dann, wenn das Fenster innerhalb des sichtbaren Bildschirms plaziert wird. Andere Koordinaten werden schlichtweg ignoriert. In solchen Fällen führt das Ausblenden unter MagiX! zu keinem Ergebnis. Ähnlich sieht es unter WINX aus. Wird ein Fenster links aus dem Bildschirm herausgeschoben, liegen die Startkoordinaten dieses Fensters ebenfalls außerhalb des sichtbaren Bildschirms, sie sind sogar negativ.

Es gibt in der Regel jedoch keinen Grund dafür, die Koordinaten, wie sie von WM_MOVED vorgegeben werden, einer näheren Überprüfung zu unterziehen. Daher sollte man irgendwelche Abfragen dieser Art unterlassen, sofern sie nicht zwingend notwendig sind. Es ist lediglich verstärkt darauf zu achten, daß alle Grafikausgaben korrekt geclippt werden, denn sonst sind die Effekte gerade dann unvorhersehbar, wenn negative Koordinaten übergeben werden. Insbesondere das VDI des Falcon antwortet mit durchschlagenden Abstürzen, wenn beim Zeichnen von Fenstern unter Nutzung des Blitters ungültige Koordinaten übergeben werden.

Fast ein Kinderspiel

Wenn es auch beim AES nicht ganz so einfach ist wie beim GEMDOS, eine höchstmögliche Kompatibilität zu erreichen, ist der Aufwand dennoch kaum der Rede wert. Wer sich also neuer GEMDOS- oder AES-Funktionen bedient, ist gehalten, seine Anwendungen flexibel zu gestalten, was die verschiedenen Systemumgebungen angeht. Anhand des GEMDOS-Fehlercodes sowie des erweiterten appl_getinfo() sollte es keine große Hürde darstellen, eigene Programme in dieser Hinsicht sicher zu gestalten. Der Lohn für den Programmierer besteht im Wegfallen zukünftiger Anpassungen, der Anwender erfreut sich daran, daß MultiTOS, MagiX!, Geneva und WINX optimal unterstützt werden.

Der vorausgegangene Absatz hätte eigentlich das Schlußwort darstellen sollen. Nachdem mir aber nach Redaktionsschluß der amerikanische Multitasking-Aufsatz Geneva vom Software-Haus Gribnif in die Hände gefallen ist, möchte ich mit ein paar Eindrücken zu diesem Produkt schließen. Insbesondere im Internet war Geneva schon des öfteren Gesprächsthema. Falls dieses System demnächst auch in Deutschland vertrieben werden sollte, wird sicher in einer der nächsten Ausgaben der ST-Computer mehr darüber zu lesen sein. Interessant sein als MultiTOS-Alternative dürfte Geneva speziell für Besitzer des Falcon030.

Im Gegensatz zu MagiX! läuft Geneva nämlich bereits jetzt schon auf dem Falcon!

Geneva - erste Eindrücke

Wie schon MultiTOS, ersetzt Geneva gewisse Bereiche des Betriebssystems und ergänzt andere um neue Funktionen. Es handelt sich also nicht um ein von Grund auf neu programmiertes, eigenständiges Betriebssystem, wie es MagiX! darstellt. Geneva besteht in erster Linie aus einem erweiterten AES, das alle Funktionen des MultiTOS-AES 4.0 besitzt und daher auch dessen Versionsnummer tragen darf. Das oben erwähnte erweiterte appl_getinfo(), eigentlich ein Bestandteil des AES 4.1, ist nicht vorhanden. Wie schon bei MagiX!, sind auch unter Geneva keine MiNT-spezifischen Erweiterungen vorhanden, und MiNT selber kann unter Geneva nicht gestartet werden. Dies soll sich jedoch in zukünftigen Versionen ändern.

Geneva unterstützt kooperatives Multitasking (wie auch Microsoft Windows), im Gegensatz zum präemptiven Multitasking (z.B. OS/2, Unix), wie man es auf dem ATARI bei MultiTOS und MagiX! findet [1], [2], [3], Beim kooperativen Multitasking wird vorausgesetzt, daß eine Applikation nicht benötigte Rechenzeit freiwillig an das System abgibt, damit auch andere Programme zum Zuge kommen. Insbesondere bei rechenintensiven Anwendungen oder auch bei TOS-Programmen ist eine Blockierung des Rechners nicht ganz auszuschließen. Beim anspruchsvolleren präemptiven Multitasking dagegen kann man sichergehen, daß jeder Prozeß gemäß einem Zeitscheibenverfahren genügend Rechenzeit zugeteilt bekommt.

Als Desktop für Geneva lassen die aktuellen Versionen von Neodesk oder Gemini verwenden. Dummerweise liefert Geneva aber falsche Zeichensatzinformationen an GEM-Applikationen, so daß beispielsweise Gemini mit zu großen Fonts arbeitet. Das Standard-Desktop steht übrigens nicht zur Verfügung, man kennt dies bereits von MagiX!. Sollte der Speicherplatz knapp werden, kann man ganz auf ein Desktop verzichten und den in Geneva integrierten Taskmanager zum Starten von Applikationen verwenden.

TOS-Anwendungen laufen unter Geneva in Fenstern, die automatisch beim Programmstart geöffnet werden. Aus diesen Fenstern heraus lassen sich die Bildschirmausgaben in das GEM-Clipboard kopieren und so in andere Programme übernehmen. Negativ aufgefallen ist in diesem Zusammenhang, daß die Bildschirmausgaben von TOS-Programmen selbst auf einem TT in monochromer Auflösung unangenehm langsam verlaufen.

Ein Feature, das mir unter Geneva besonders ins Auge gefallen ist, sind die sogenannten „Tear down menus“. Dabei handelt es sich um Teile der Menüleiste, die mit der Maus „abgerissen“ und in einem eigenen Fenster irgendwo auf dem Desktop plaziert werden können.

Dort sind sie jederzeit zusätzlich zur „richtigen“ Menüleiste zugänglich. Die meisten Programme kommen mit dieser neuen Menüvariante zurecht. Als Programmierer hat man lediglich darauf zu achten, daß Manipulationen im Status der Menüeinträge nur über die AES-Aufrufe menu_ienable() sowie menu_icheck() erfolgen sollten, nicht aber durch eine direkte Manipulation der entsprechenden Status-Flags. Andernfalls werden Änderungen lediglich im eigentlichen Menü, nicht aber in seinem Tear-down-Gegenstück wirksam.

Alles in allem machte Geneva auf mich keinen schlechten Eindruck, es hat allerdings noch einige Macken. Verglichen mit MultiTOS und MagiX! dürfte das größte Manko das fehlende präemptive Multitasking sein. Die Geschwindigkeit des Geneva-AES ist nach meinem Empfinden nur wenig größer als die des MultiTOS-AES und deutlich langsamer als bei MagiX! 2.0. Immerhin bietet Geneva im Gegensatz zu MagiX! eine Implementierung des vollständigen AES 4.0, wie man es auch bei MultiTOS findet. Anhänger von MultiTOS werden, wie schon bei MagiX!, auch bei Geneva den MiNT-Unterbau vermissen. Wer nicht auf das AES 4.0 mit seinem 3D-Look Wert legt, wird aus Geschwindigkeitsgründen wohl eher von MagiX! als von Geneva profitieren. Geneva hat MagiX! im wesentlichen die neuere AES-Version, einen besseren Taskmanager und die höchst interessanten „Tear down menus“ voraus.

Gravierende Kompatibilitätsprobleme unter Geneva gab es keine, auch nicht bei residenten Programmen wie LETEMFLY, SPEEDO und NVDI. Der Umstand jedoch, daß Geneva falsche Informationen über die Größe der verfügbaren Zeichensätze liefert, schränkt die Brauchbarkeit einiger Programme unter diesem System stark ein. Auch beim Redraw gab es manchmal kleinere Fehler, die inzwischen aber bereits behoben sein könnten. (Die mir vorliegende Version 1.01 stammte vom September ’93.) Um die Kompatibilität zu unsauber programmierten Anwendungen zu steigern, lassen sich gewisse Funktionen für jedes Programm individuell konfigurieren

Für Besitzer eines Falcon kommt MagiX! bisher nicht in Frage, so daß Geneva auf dem Falcon die einzige Alternative zu MultiTOS ist. Hier gilt es abzuwägen, ob die Vorteile von Geneva gegenüber MultiTOS so groß sind, daß man dafür auf MiNT und präemptives Multitasking verzichten möchte. Diese Frage ist wohl nur in einem ausführlichen Test zu klären. Die wichtigste Forderung an Geneva lautet aber ganz klar: Präemptives Multitasking! Sollte dies einmal Realität werden, könnte Geneva durchaus ein interessantes Produkt auch für den europäischen Markt darstellen.

Bedanken möchte ich mich bei Nolan Campiz vom RAAC (Ramstein Area ATARI Club), der mir Geneva für diesen Überblick zur Verfügung gestellt hat.

US

Literatur:

[1] Erik Dick, „MagiX! und Ease“, ST Computer 1/94

[2] Richard Kurz, „MultiTOS für Einsteiger“, ST Computer ab 8/93

[3] Uwe Seimet, „Ein Mehr an Multitasking“, c't 12/93

Präemptiv versus kooperativ

Bei der Diskussion über die Leistungsmerkmale von Multitasking-Systemen nehmen diese beiden Begriffe einen wichtigen Stellenwert ein.

Weniger anspruchsvolle Multitasking-Umgebungen arbeiten nach dem kooperativen System Hier sind die Anwendungen dafür verantwortlich, nicht benötigte Rechenzeit an die im Hintergrund laufenden Programme abzugeben. Wird ein Programm gestartet, das sich nicht an diesen Grundsatz halt, fuhrt dies zu einer Blockierung der Hintergrundanwendungen Kooperatives Multitasking findet man bei Geneva. MultiGEM. beim System 7 auf dem Apple Macintosh und auf PCs unter Microsoft Windows Auch das Konzept der Accessories fällt unter die Rubrik des kooperativen Multitaskings. wenn auch nur mit Einschränkungen Die professionellere Variante stellt das präemptive Multitasking dar Hier verwaltet das Betriebssystem als oberste Instanz die gesamte Prozessorzeit. Jeder Prozeß bekommt nach einem Zeitscheibenverfahren eine gewisse Zeit zugeteilt, bevor er vom System automatisch zugunsten der anderen Prozesse unterbrochen wird. Blockierungen, wie sie beim kooperativen Multitasking auftreten können, sind ausgeschlossen Die Zuteilung der Rechenzeit also die Verteilung der Zeitscheiben, laßt sich in der Regel vom Anwender in gewissen Grenzen konfigurieren. Präemptiv arbeiten MultiTOS und MagiX! sowie auf anderen Plattformen OS/2 und Unix.

Uwe Seimet

---

---