Atarium: Ein Haufen Vermischtes
Heute beschäftigen wir uns mit der Speicherplatz-Problematik bei Accessories und dem Nachfolgerprogramm von Bigscreen.
Uns erreichen immer wieder Zuschriften zum Thema Accessories. So möchte ein Leser wissen, wie ein Accessory so geschrieben werden kann, daß es auf dem TT einen Auflösungswechsel übersteht, obwohl es beim Booten Speicherplatz angefordert hat.
Zunächst etwas Grundlegendes: Die Problematik des Auflösungswechsels gibt es natürlich auf allen TOS-Versionen. Bekanntlich werden Accessories nicht als eigene GEM-DOS-Prozesse angesehen, so daß alle Dateikennungen, DTAs und Speicherblöcke immer dem aktiven Hauptprogramm gehören (siehe in [1]). Im Falle einer Beendigung des Hauptprogramms werden alle offenen Dateien geschlossen und sämtlicher Speicher freigegeben.
Accessories werden mittels einer AC_CLOSE-Mitteilung von einer solchen Programmbeendigung benachrichtigt. Der Haken dabei: Die Mitteilung trifft unter Umständen erst nach der Beendigung des Hauptprogramms ein. Die Dateien sind also bereits geschlossen, die Speicherblöcke wieder freigegeben. Das alleine wäre noch gar nicht mal so tragisch: das Accessory muß eben nur damit rechnen, daß dies passieren kann.
Schwieriger wird es schon mit GEMDOS-Ressourcen, die indirekt von anderen Betriebssystemfunktionen angefordert werden. Zu nennen wäre beispielsweise »v_opnvwk« - das VDI reserviert für die virtuelle Workstation einen eigenen Speicherblock. Wenn ein Accessory also eine eigene Workstation öffnet und dann eine AC_CLOSE-Mitteilung eintrifft, ist das Problem da: Der Speicherblock ist längst freigegeben, obwohl er noch in der Workstation-Liste des VDI hängt. Einzige halbwegs praktikable Abhilfe: Workstations wenn überhaupt gleich ganz zu Beginn beim Booten öffnen und dann nicht wieder schließen. Oder als Alternative die Workstation immer nur temporär öffnen und vor jedem AES-Aufruf (wir erinnern uns: Jeder AES-Aufruf kann zu einer AES-Prozeßumschaltung führen) wieder schließen.
Ähnliche Probleme gibt es mit allen Betriebssystemfunktionen, die selbst Speicher anfordern, etwa »vst_load_fonts()« oder »rsrc_load()«. Für GEM-Resource-Dateien ist die Problematik allerdings leicht zu lösen: Die Objektdaten werden einfach direkt im Programm verankert. Besonders einfach ist dies mit einem Resource Construction Set wie »Interface« von Shift, das C-Code erzeugt, den man direkt in seinen Quelltext einbinden kann.
Eine weitere Folge dieser Sachlage: Accessories sollten keinesfalls irgendwelche Vektoren verbiegen, denn bei einem Auflösungswechsel wird der durch das Accessory belegte Speicherplatz freigegeben, ohne daß es etwas davon merkt. Programme dieser Art gehören in den AUTO-Ordner - ganz so, wie es Atari mit »MACCEL3« demonstriert hat. Accssories wie »Chameleon« muß man als Ausnahme ansehen: Chameleon ist ein Utility, dessen einziger Daseinszweck das Laden und Entfernen anderer Accessories ist. Daß es dabei sehr tief in Betriebssystemvorgänge eingreift, kann man verschmerzen - wenn es irgendwann mal nicht mehr funktioniert, benutzt man es eben nicht mehr. Anders bei Accessories, deren Hauptbeschäftigung einen echten Zweck erfüllt. Diese sollten so programmiert sein, daß es weder mit alten noch mit künftigen TOS-Versionen Probleme geben kann.
Mit der GEM-Version 3.0 (nicht mit der TOS-Versionsnummer verwechseln!) im TT- und Mega-STE-TOS hat Atari das Problem deutlich entschärft. Ein Aufruf von »appl_exit()« blockiert nun das Hauptprogramm so lange, bis alle Accessories auf ein Message-Event warten. Damit können sich Accessories sicher sein, daß sie die AC_CLOSE-Mitteilung rechtzeitig erreicht und entsprechend reagieren. Eine zusätzliche Erschwernis ergibt sich durch die Art und Weise, wie ältere GEM-Versionen Accessories laden:
Desktop und Accessories waren der gleiche GEMDOS-Prozeß wie GEM selbst. Damit war es unmöglich, bei einem Auflösungswechsel den durch die Accessories zusätzlich allozierten Speicherplatz wieder freizugeben. Nur der vom Accessory-Programmcode belegte Speicher wurde wieder korrekt freigegeben. Die Folge: geladene Ressource-Dateien, geöffnete Workstations und alle anderen allozierten Speicherblöcke blieben belegt und ließen häßliche Löcher im Speicher zurück.
Ab GEM-Version 3.0 hat Atari auch dieses Problem gelöst. Für Desktop und Accessories wird jetzt ein eigener GEMDOS-Prozeß gestartet, der bei einem Auflösungswechsel ganz normal terminiert wird. Dabei werden natürlich auch alle angeforderten Speicherblöcke freigegeben. Diese beiden Verbesserungen im GEM sind übrigens auch der Grund dafür, warum Atari sich zur Zeit weigert, XCONTROL für ältere TOS-Versionen freizugeben.
Nun zu einem anderen Thema: Der Großbildschirm-Simulator »Bigscreen« hat einen Nachfolger mit dem einfallsreichen Namen »Bigscreen 2« gefunden (Vertrieb: SciLab GmbH). Neben vielen Verbesserungen im Detail (STE- und TT-Hardware werden unterstützt, Auflösungswechsel möglich, Konfiguration per Accessory oder XCONTROL-Modul) gibt es jetzt auch eine über einen Cookie zu erreichende Informationsstruktur, die im folgenden beschrieben werden soll (siehe Abb.):
So ist der VSCR-Cookie aufgebaut
typedef struct
{
LONG cookie; /* muß 'VSCR' sein */
LONG product; /* Analog zur XBRA-Kennung */
WORD version; /* Version des VSCR-Protokolls, zunächst 0x100 */
WORD x, y, w, h; /* Sichtbarer Ausschnitt des Bildschirms */
} INFOVSCR;
Der Cookie heißt »VSCR«, was für Virtual Screen steht. Er zeigt auf eine Info-Struktur, die insbesondere Informationen über den dargestellten Bildschirmausschnitt enthält. Anwendungsprogramme können diese Information beispielsweise dazu benutzen, um Dialogboxen automatisch auf dem tatsächlich sichtbaren Teil des Bildschirms zu zentrieren (alle Programme mit neueren Fly-Dial-Dialogboxen tun dies automatisch). Nun zu den einzelnen Einträgen in der Struktur:
»cookie« muß den Wert $56534352 (VSCR) haben. Sinn der Sache ist, daß ein Großbildschirm-Simulator die Informationsstruktur auf »ungültig« setzen kann, ohne erst den Cookie entfernen zu müssen. Bigscreen 2 beispielsweise kann je nach gewählter Auflösung aktiv oder inaktiv sein und benutzt diesen Mechanismus, um beim Auflösungswechsel die Struktur ein- oder auszuschalten.
In »product« kann ein Großbildschirm-Simulator eine eigene Kennung eintragen. Die vier Bytes sollten genauso wie bei einer XBRA-Kennung aus vier druckbaren Zeichen (ASCII-Code 32 bis 126) bestehen. Bigscreen 2 trägt hier »BIGS« ein.
»version« kennzeichnet die Version des VSCR-Protokolls und soll es erlauben, später einmal die Struktur um neue Felder zu ergänzen. Die momentane Versionsnummer ist 1.0 ($0100).
»x«, »y«, »w« und »h« schließlich geben Position, Breite und Höhe des sichtbaren Ausschnitts an.
Das Protokoll ist absichtlich so ausgelegt, daß es auch von anderen Simulatoren benutzt und bei Bedarf erweitert werden kann. Weitere Fragen zu diesem Thema beantworte ich gerne; Sie erreichen mich entweder im Maus-Net oder über die Redaktion des ST-Magazins.
Quellennachweis:
[1] Julian F. Reschke, »Accessories - Programme zweiter Klasse«, ST-Magazin 3/1991, Seite 58
[2] Atari Corporation, »TT030 TOS Release Notes«, 8.10.1990
Julian F. Reschke uw