Mehr Software-Qualität, bitte!

Ja, haben wir denn nicht bereits einen guten Qualitätsstand erreicht? Leider nicht. Zweifellos gibt es auf dem Markt einige sehr gut konzipierte Programme, jedoch auch viele schwarze Schafe. Grund für dieses Bedienungsdurcheinander ist sicherlich zum einen, daß Programmierrichtlinien nie so recht publik wurden, und zum anderen, daß sich viele Programmierer(-innen) nicht darum kümmern.

Die ATARI ST-Reihe gibt es nun seit 1985. der TT kündigt sich an. Zeit also, um die Software Qualität der ST-Software zu steigern.

Das Betriebssystem TOS wurde von vornherein mit GEM (Graphics Environment Manager) ausgestattet. GEM ist vom Konzept her ein von der Hardware unabhängiges System. GEM existiert beispielsweise auch für DOS-Rechner (der sogenannte Industriestandard). Wer liebäugelt nicht damit, sein GEM-Programm auch auf andere Rechner zu portieren? Dementsprechend sind richtige GEM-Programme unabhängig von der Hardware geschrieben. Jedoch müssen wir auf dem ST unterscheiden zwischen Programmen, die nur für den ST gedacht sein können, und solchen, die unabhängig sind.

Die Gruppe der “Nur ST/TT" Programme beinhaltet alle die Programme, die in irgendeiner Weise Betriebssystemeigenschaften ausnutzen. Hierzu gehören Formatierprogramme, Mausbeschleuniger und ähnlich gelagerte Programme. “Nur ST“ heißt jedoch trotzdem nicht, daß man jetzt munter drauflosprogrammieren kann, denn der ST mit seiner vielfältigen Hardware verlangt entsprechende Vorkehrungen in den Programmen.

Kommen wir zuerst zu Grundregeln, die beide Programmsparten betreffen. Programmierer(-innen) stehen hier zuerst vor der Wahl der Programmiersprache. In Frage kommen nur Hochsprachen, da Assembler immer von einem bestimmten Prozessor ausgeht. DOS-Rechner und STs haben jedoch unterschiedliche Prozessoren! Die Hochsprachen sollten modularisierte. strukturierte Programmierung zulassen. Modula-2 und Pascal kommen prinzipiell in Frage, eine Portierung ist leider schwierig, da auf DOS- und ST-Rechnern nicht einmal einheitliche GEM-Bibliotheken für diese beiden Sprachen existieren. Wer “Nur ST"-Programme schreiben will, kann natürlich zu den beiden genannten Programmiersprachen greifen. Aber auch hier sollte man darauf achten, daß man - sofern es möglich ist - für alle auf dem ST erhältlichen Entwicklungssysteme portabel bleibt. Es bleibt folglich nur C! Aber auch C ist nicht immer C, weshalb es empfehlenswert ist, keine speziellen Eigenschaften der C-Compiler auszunutzen.

Bei portabler Programmierung (auch im Hinblick auf den ATARI TT) innerhalb und außerhalb der ST-Reihe ist darauf zu achten, daß keine Line-A-Aufrufe gemacht werden. Line-A gehört nicht zum GEM, und es besteht auch keine Sicherheit, daß diese Routinen nicht doch einmal geändert werden. Betriebssystemaufrufe (BIOS, XBIOS, GEMDOS) dürfen lediglich “Nur ST“-Programme reichlich benutzen. Bei portablen Programmen ist man auf die Programmiersprache angewiesen - für das Datei-Handling bei C etwa auf die entsprechenden C-Routinen. Sollten dann doch einmal bestimmte Aufrufe des Betriebssystems benötigt werden, so bringt man diese in einem speziellen, gut dokumentierten Modul unter, am besten mit unabhängigen Bezeichnern, damit eine Portierung einfacher wird. Viele Funktionen, wie solche zur Dateibearbeitung. gehören üblicherweise zum Sprachumfang einer Programmiersprache, so daß man vielfach gar nicht erst auf Betriebssystemroutinen angewiesen ist. Betrachten wir nun die “Nur ST“-Programme. Allein von der Hardware her gesehen, ergeben sich vielfältige Variationen und damit auch Einschränkungen. Ist es grundsätzlich nicht möglich, daß ein Programm mit bestimmten Hardware-Konfigurationen zurechtkommt (beispielsweise mit der Auflösung 320 mal 200 Pixel bei 16 Farben), so darf das Programm nicht einfach abstürzen. Statt-dessen sollte eine Warnung erscheinen, die dem/der Anwender(in) einen Hinweis darauf gibt, warum das Programm nicht läuft. Hardware-Konfigurationen, die Beachtung finden müssen, sind zum Beispiel die Monitorauflösung (man denke in diesem Zusammenhang an die vielen Auflösungen des TT oder diejenigen, die man mit dem Programm BigScreen von Julian F. Reschke emulieren kann, oder die MAXON Graphic Expansion), die Diskettenlaufwerke und Harddisks.

In diesem Zusammenhang ist auch die Funktion Getrez (XBIOS 4) zu erwähnen, die keine korrekten Werte liefert. Daher sollte diese Funktion niemals Verwendung finden. Die Monitorauflösung (oder besser die Größe des Arbeitsbereichs) kann mit entsprechenden GEM-Funktionen korrekt abgefragt werden! In diesem Zusammenhang sei auf die Funktion wind_get (AES 104) verwiesen. Bei Disketten bzw. Harddisk-Betrieb ergibt sich das Problem, daß Programme nicht grundsätzlich von Laufwerk A gestartet werden, wie es diverse Programme annehmen. Mit Dgetdrv (GEMDOS 25) läßt sich abfragen, welches Laufwerk das aktuelle ist. Gerade Besitzer(innen) von Festplatten kennen das Problem, daß diverse Programme Dateien immer zuerst auf Laufwerk A suchen!). Bei GEM-Funktionen ist dies noch nicht einmal nötig, denn beispielsweise rsrc_load (AES 110) und shell_find (AES 124) suchen selbst an diversen Orten (aktueller Pfad und all die Pfade, die in der AES-Environment-Variablen PATH= angegeben sind). Hier darf folglich nicht einmal ein Pfad angegeben werden!

Bild 1: Eine Dialogbox aus der GEMINI-Shell
Bild 2: Das Fenster der CLIPBRD-Accessorys
Bild 3: Das Menü der GEMINI-Shell

Ob eine ausführbare Datei als Programm oder Accessory gestartet wurde, läßt sich auf dem ST nur über die Basepage ermitteln. Ist der Pointer auf den Parent-Prozeß Null, so handelt es sich um ein Accessory, sonst nicht. Leider unterstützen nicht alle Entwicklungssysteme die Möglichkeit, eine ausführbare Datei wahlweise als Accessory oder Programm zu benutzen, weshalb hier erst einmal ausprobiert werden muß, ob diese Möglichkeit der Abfrage benutzt werden kann oder nicht. Andererseits bieten andere Systeme komfortable Möglichkeiten der Abfrage, um festzustellen, wie eine ausführbare Datei gestartet wurde. Somit kann eine umständliche Ermittlung unterbleiben. (Beispiel: _app bei Turbo C, Accessory() bei Megamax Modula-2.)

Ein letzter Punkt betrifft Betriebssystemadressen. Das Betriebssystem des ST und auch die Anfangsadresse des Betriebssystems verändern sich mitunter. In diesem Zusammenhang sei auf die bekannten TOS-Versionen und Rechner wie den 1040STE und den TT verwiesen! Systemadressen, die man abfragen kann, müssen über die Systemvariablen abgefragt werden! Andere darf man grundsätzlich nicht verwenden!

Prinzipiell gelten die eben genannten Regeln (mit Ausnahme der Betriebssystemadressen und der Abfrage auf Accessory/Programm) auch für echte GEM-Programme, denn auch hier darf selbstverständlich nicht von einer bestimmten Monitorauflösung oder von einem bestimmten Laufwerk ausgegangen werden. GEM-Programme beschränken sich auf die Funktionen des GEM. Es taucht also auch keine Standardausgabefunktion wie die C-Funktion printf auf! Diese Funktion ist - wie ähnliche Funktionen in anderen Entwicklungssystemen - nicht über die GEM-Ausgabe realisiert, sondern über die Funktionen des Betriebssystems. (GEM zählt genaugenommen nicht zum Betriebssystem, sondern ist ein “Aufsatz”.) Das ST-Betriebssystem beinhaltet den VT52-Emulator, mit dem es beispielsweise möglich ist. Vorder- und Hintergrundfarbe zu ändern. Entsprechend werden dann Ausgaben über printf verändert! Das ist nicht nur unschön, sondern auch im GEM-Sinne - inkorrekt! Das Programm VT52Inst (Public Domain) ermöglicht beispielsweise, über den VT52-Emulator die Farbeinstellungen schnell zu verändern, womit man Programme auf die Verwendung von Ausgabefunktionen (wie printf) hin überprüfen kann.

Werden mehrere “Bildschirme” oder mehrere Bilder in schneller Folge benötigt, so ist dazu nicht die Funktion Setscreen (XBIOS 5), sondern die Rasterkopierfunktion vro_cpyfm (VDI 109) zu verwenden. Dies hat sogar den Vorteil, daß man nicht für jedes Bild Speicherplatz in der Größe des Bildschirms anfordern muß, sondern es reicht vielmehr, den Speicherplatz für das eigentliche Bild zu reservieren. Für ein Bild von 27 mal 38 Pixeln mit einer monochromen Auflösung (die Anzahl der Farbebenen sowie weitere gerätespezifische Werte werden beim Anlegen der virtuellen Workstation zurückgeliefert) wird ein 32 mal 38 Bit großer Speicherplatz benötigt. Die 32 Bits werden statt der tatsächlichen 27 Bits für die Pixel (eine Farbebene!) benötigt, da auf die nächste Word-Grenze aufgerundet werden muß. Um mit den Rasterfunktionen ein Bild vom oder auf den aktuellen Bildschirm zu kopieren, ist es nicht nötig, die Adresse des Bildschirmspeichers zu kennen. Es reicht, als Adresse auf den Speicherblock einen Null-Pointer zu übergeben. Das VDI ergänzt die benötigten, anderen Werte intern, gibt diese aber nicht zurück!

Kein echtes GEM-Programm darf Probleme mit GDOS (oder dem neueren AMCGDOS) haben. Sollte es dennoch zu Problemen kommen, so sollte man zuerst davon ausgehen, daß es nicht an GDOS liegt. Ein beliebter Fehler ist es, vor dem Öffnen der virtuellen Workstation das Handle der aktuellen physikalischen Bildschirm-Workstation nicht mit graf_handle (AES 77) abzufragen. Die Verträglichkeit mit GDOS kann jeder leicht testen, denn dieses Programm ist frei zugänglich.

Die Scrap-Ablage (oder das GEM-Clipboard) wird von vielen Programmen zur Zeit noch nicht unterstützt. Aber gerade in den letzten Monaten häufen sich die Programme, die die Scrap-Ablage benutzen (beispielsweise GEMINI, CLIPBRD, Disk-Info 3.00). Der Vorteil einer solchen Ablage liegt klar auf der Hand. Dateien, die ein Programm angelegt hat, können von anderen weiterverarbeitet werden. Somit könnten etwa mit einem Grafik-Programm Grafiken entworfen werden, die dann von einem Desktop Publishing-Programm automatisch geladen und zur Verfügung gestellt werden könnten. Alles das geschieht, ohne daß der Anwender den Dateinamen irgendwo angeben oder eine Datei laden mußte. Das Public Domain-Accessory CLIPBRD (läuft auch als Programm) ermöglicht zudem eine Verwaltung des Clipboards. Es können sogar alle Dateien in Standardformaten, die GEM-Programme verwenden, dargestellt werden.

Werden Dateien an andere GEM-Programme übergeben, so fragt man die Namen der Dateien nicht über die systemabhängige Basepage, sondern über shel_read (AES 120) ab. Hier wird auch gleich der Programmname inklusive Pfad mitgeliefert.

Damit auch andere GEM-Anwendungen etwas Zeit zur Bearbeitung der eigenen Aufgaben erhalten, ist darauf zu achten, daß gerade bei langwierigen Operationen hin und wieder ein evnt_timer-Aufruf (für 0 Sekunden) gemacht wird. Mit einem längeren evnt_timer-Aufruf kann sogar erreicht werden, daß beispielsweise Accessories im Hintergrund quasi gleichzeitig Weiterarbeiten können. Allerdings verwendet man diese Möglichkeit besser sehr sparsam.

Generell soll hier noch einmal erwähnt werden, keine Annahmen über irgendwelche Soft- oder Hardware-Gegebenheiten zu machen. Das GEM bietet ausreichend Möglichkeiten, alle notwendigen Werte abzufragen. Hier seien nur noch einmal ein paar Beispiele genannt: Arbeitsbereich, Font-Größe, Anzahl der Farben. Dazu gehört aber auch, daß nicht jedes Programm eigene Druckertreiber (beispielsweise zur Ausgabe von Grafik) benötigt. Soweit die technische Seite des Programmierens von portablen und “Nur ST"-GEM-Programmen.

Auf der gestalterischen Seite ist viel zu berichten, was hier jedoch nicht in voller Breite erfolgen kann. Menüs, Dialog- und Alertboxen können mit einem Resource-Construction-Programm, wie es annähernd jedem Entwicklungssystem beiliegt, angelegt werden. Die hiermit angelegten Resource-Dateien werden zur Laufzeit des Programms nachgeladen. Dies hat den Vorteil, daß bei einer Übertragung des Programms in eine andere Sprache nur die Resource-Datei geändert werden muß, nicht jedoch der Programmcode. Bei Accessories kann es allerdings erforderlich sein, die entstandenen Resourcen im Programmcode unterzubringen, da es sowohl unter GEM 2.0 als auch unter TOS 1.4 (Autostart-Option) zu Problemen kommen kann. (Hier sei nur als Stichwort “Speicherplatzreservierung” genannt.)

Ein korrektes Menü hat wie unter GEM 2.x den Programmnamen als Titel des Desk-Menüs (im folgenden sind mit den Menüs die Drop-Down (nicht Pull-Down!)-Menüs gemeint). Dieser Titel wird in Großbuchstaben geschrieben. Die restlichen Titel hingegen werden mit einem Großbuchstaben begonnen und dann klein fortgesetzt. Rechts und links vom Titel steht ein(!) Leerzeichen. Standardmäßig ist das linke Menü (abgesehen vom Desk-Menü) das Datei-Menü, welches die Möglichkeit der Beendigung des Programms beinhaltet. Weiterhin haben sich das Edieren- oder Edit-Menü (rechts neben dem Datei-Menü, das Parameter- oder Optionen-Menü (vorletztes von links aus gesehen) und das Hilfe-Menü (letztes von links aus gesehen) durchgesetzt. Zu jedem oder mindestens jedem wichtigen Menükommando gehört an den rechten Rand des Eintrags ein Tastenkürzel, wobei man sich hier an bestehenden orientieren sollte. Vor jedem Menükommando oder -eintrag befinden sich zwei Leerzeichen (für ein Häkchen davor, egal ob es gesetzt wird oder nicht), es sei denn, es handelt sich um eine Trennlinie, die ganz durchgezogen wird. Drei Punkte hinter einem Eintrag deuten an. daß nach Anwahl dieser Option ein Dialog folgt. Ein Eintrag sollte übrigens eine Gesamtlänge von höchstens 20 bis 25 Zeichen inklusive der beiden Leerzeichen und des Tastenkürzels haben.

Dialogboxen sollten klar gestaltet sein. Buttons für OK und Abbruch stehen immer an der gleichen Stelle (beispielsweise unten rechts oder links). Unter OK versteht man, daß etwas ausgeführt oder gesetzt wird, Abbruch beinhaltet, daß alle gemachten Veränderungen seit Aufruf des Dialogs rückgängig gemacht werden. Dialogboxen sollten nie zu groß ausfallen. Es ist besser, mehrere kleinere Dialogboxen zu nehmen, als Farbanwendern das Programm zu verwehren.

Die Gestaltung der Alertboxen lehnt sich an die Gestaltung der Dialogboxen an. Da bei Alertboxen unter GEM 1.x die Buttons immer unten zu finden sind, bietet es sich an, auch in Dialogboxen die Exit-Buttons am unteren Rand zu plazieren. Texte in Alertboxen haben höchstens 30 Zeichen pro Zeile. Auf jeden Button entfallen maximal 10 Zeichen, beispielsweise für Ja, Nein, OK oder Abbruch.

Bringen Sie nicht zuviele Dinge im Menü unter. Das Menü soll klein und übersichtlich bleiben. Viele Einstellungsmöglichkeiten lassen sich beispielsweise in Dialogboxen unterbringen! Die Anzahl der Drop-Down Menüs sollte höchstens 7 betragen, sonst wird das Menü zu unübersichtlich. Die Anzahl der Einträge pro Drop-Down Menü liegt ebenso bei maximal sieben oder acht, in Ausnahmefällen bei bis zu zehn.

Die meisten Mausformen sind reserviert und sollten dementsprechend benutzt werden. So werden die Biene oder das Stundenglas bei lang andauernden Operationen (beispielsweise dem Speichern einer Datei), die flache Hand zum Ver schieben, die Hand mit dem Zeigefinger bei Größen Veränderungen, der gesplittete Balken bei Texteingaben benutzt. Für normale Dinge bleibt der Mauszeiger in der Form eines Pfeils.

Ausgaben erfolgen ausschließlich in Fenstern oder Dialogboxen. In Dialogboxen sind höchstens kurze Informationen oder Texte zu finden, längere Texte (zum Verändern) oder Bilder werden in Fenstern ausgegeben. Die etwas niedrigere Geschwindigkeit der Textausgabe via GEM-Funktionen läßt sich zumindest teilweise dadurch erhöhen, daß man Texte grundsätzlich auf Byte- oder noch besser auf Word-Grenze in der horizontalen Richtung beginnen läßt.

Wem diese Gestaltungsmöglichkeiten nicht reichen sollten, der hat die Möglichkeit, eigene AES-Objekte zu kreieren. Dies kann zum Beispiel mit einem AES-Objekt vom Typ G_USERDEF geschehen. Bei der Gestaltung gilt immer der Grundsatz: Weniger ist mehr! Also bitte nicht zu viel des schönen Schnickschnacks.

Die Bilder zeigen ein paar Gestaltungsvorschläge, die als Beispiel für Eigenentwicklungen dienen können. Eine pfiffige, schön gestaltete Anwendung ist manchmal besser als ein Programm mit tollen Eingangsmelodie und einer unüblichen Benutzerführung.

Und noch ein Tip: Testen Sie Ihr Programm mit BigScreen, dem GEM 2.x-Demo, mit und ohne Harddisk usw. Da man nicht über alle Hardware verfügen kann, empfiehlt es sich, das Programm auch mal anderen Anwendern/innen oder Programmierern/innen zum Testen zu geben. Oder besprechen Sie Ihr geplantes Programmprojekt mit Freunden/innen oder Kollegen/innen. Ein klares Wort bei einer Programmbesprechung hilft, Fehler bereits im Vorfeld zu vermeiden.

Quellen und weiterführende Literatur sowie Programme:

[1] BigScreen (ab Blitter TOS) ist erhältlich bei

[2] Protos (beinhaltet auch die Emulationsmöglichkeit des Ganzseitenmonitors) ist erhältlich bei

[3] AMCGDOS ist (bei nichtkommerzieller Nutzung frei kopierbar) erhältlich bei

[4] GEM 2.0 gibt es von der Firma ABC Software, von der man leider seit Monaten nichts mehr gehört hat.

[5] CLIPBRD ist erhältlich bei

[6] GEMINI ist erhältlich bei

[7] VT52Inst ist erhältlich bei

[8] ATARI ST Profibuch, H.-D. Jankowski/ D. Rabich/ J. F. Reschke, Svbex-Verlag 1987/88/89

[9] Professional GEM, T. Oren, erschien vor Jahren in der US-Zeitschnft Start (erhältlich z.B. über die ATARI-Mailbox)

[10] GEM-Programmierhandbuch, P Balma/ W. Filler, Sybex-Verlag 1987/88

[11] Vom Anfänger zum GEM-Profi, D. und J. Geiß, Hüthig-Verlag, voraussichtlich Anfang 1990

[12] Über Pfade im allgemeinen und die Dateiauswahlbox im besonderen, D. Rabich, ST Computer 5/89

[13] Kochrezept für ein Menü, D. Rabich. ST Computer 6/89

[14] Programme unter GEM, D. Rabich, ST Computer 9/89 und 11/89


Dietmar Rabich
Aus: ST-Computer 04 / 1990, Seite 135
Links
Copyright-Bestimmungen: siehe Über diese Seite