GEM-Anwendungen »sauber« programmiert: Standards erleichtern dem Programmierer das Leben

Zum Beginn noch etwas Nachbetrachtung zur Düsseldorfer Atari-Messe im September: Die Großbildschirme der Firma Matrix — auf der Messe auf vielen Ständen namhafter Softwarehäuser wie DMC, Heimsoeth oder Technobox zu finden — scheinen endlich einen Trend hin zu sauber programmierten GEM-Anwendungen eingeleitet zu haben: Wohin man blickte, sah man Compiler, CAD- und DTP-Anwendungen im Großformat. Sogar der »Aladin« wurde mit einem entsprechenden Bildschirmtreiber gesichtet. Und selbst Atari USA hat offenbar mittlerweile den Geist der Zeit erkannt: Allan Pratt, seines Zeichens GEMDOS-Programmierer, weist auf dem Unix-Rechnernetz USENET vorsichtig darauf hin, daß auch seitens Atari früher oder später mal STs mit größerer Grafikauflösung erhältlich sind.

Gerade Programmierer von Sprachen müssen hier sehr aufpassen: Es geht einfach nicht an, daß ein Basic-Interpreter beim Befehl »CLS« einfach nur 32000 Bytes beginnend am Bildschirmspeicheranfang löscht — was sollen denn die Programmierer tun, wenn schon die »eingebauten« Befehle der Programmiersprache nicht richtig funktionieren? Gleiches gilt für Bibliotheken anderer Hochsprachen!

Eine andere gute Messenachricht: Das holländische Softwarehaus ABC legt jetzt die Systemsoftware zu GEM 2.0 allen verkauften Programmen umsonst bei — vielleicht auch ein Weg, mehr Anwender und auch Programmierer für das »neue« GEM zu gewinnen. Voraussetzung wäre allerdings, daß ABC die AES-Funktionen aus TOS 1.4 seiner eigenen GEM-Implementation hinzufügt, sonst funktionieren alle GEM-Programme nicht, die die neue FSEL_EXINPUT-Funktion nutzen.

Überhaupt kristallisiert sich immer mehr heraus, daß die deutschen Programmierer sehr wohl für sinnvolle Standards zu haben sind — Hauptsache, sie werden formuliert und dann auch unterstützt. Ein Beispiel: Es ist allerhöchste Zeit, ein einheitliches Kommunikationsprotokoll für die Message-Pipeline zu formulieren (praktisch wäre es zum Beispiel, die Namen der geladenen Accessories und Programme abzufragen). Auch mit der Benutzung des Scrap-Directory tun sich die Softwareentwickler nach wie vor schwer, obwohl gerade dieser AES-Teil von Beginn an gut dokumentiert war. Gerade solche Programme, die »CUT&PASTE«-Funktionen anbieten, sollten hierbei Vorbild werden.

Das XBRA-Verfahren zur Koordination vektorverbiegender Programme (siehe ST-Magazin 10/88) ist ein anderes Beispiel für einen sinnvollen Standard, der bereits jetzt auf überraschend große Resonanz gestoßen ist. Sogar schon von PC-Programmierern wurde signalisiert, daß unter Umständen diese Methode auch auf MS-DOS heimisch wird.

Was natürlich fehlt, ist eine aktuelle Liste der bereits verwendeten (siehe Bild) und die geordnete Verteilung neuer Pro-gramm-IDs! Ergänzungen und Anfragen sind an die Redaktion zu richten. Wir werden in regelmäßigen Abständen eine neue Liste veröffentlichen.

Auch ein anderes, schon lange drückendes Problem sollte sich mit dem XBRA-Verfahren leicht lösen lassen: Immer neue Programme hängen sich in den BIOS- und XBIOS-Trap-Vektor, weil sich manche Programmierprobleme einfach anders nicht lösen lassen. Das Ganze hat nur einen schweren Nachteil: Ausgerechnet der TRAP-Dispatcher ist bereits bei »einfachen« Funktionen wie der BIOS-Zeichen-ausgabe der Flaschenhals, der die Geschwindigkeit drückt. Je mehr Programme sich also in diesen Vektor hängen, desto größer der Geschwindigkeitsverlust. Hier würde ein Standardprotokoll helfen, das bei Erstinstallation eine Vektortabelle im RAM anlegt und diese anschließend anderen Programmen zur Verfügung stellt. Wir bitten um Ihre Ideen! (uh)

Berichtigung: Bigscreen (Ausg. 11/88) ist natürlich nicht in C, sondern in Assembler geschrieben.

Unentbehrlich für Programmierer: Unsere XBRA-Liste bringt »Vektorbieger« unter einen Hut