AES

Das AES

Applikationsfunktionen

8.2 Grundlagen des AES

Das AES (Application Environment Services) bildet die obere Schicht des GEM. Es befasst sich mit all jenen GEM-Bestandteilen, die über elementare Grafikausgaben und -eingaben hinausgehen. Da das AES ausschließlich VDI- und GEMDOS-Aufrufe tätigt, ist es sowohl von der Grafikhardware, vom Eingabegerät als auch vom Dateisystem unabhängig. In diesem Abschnitt werden die folgenden Punkte behandelt:

• Accessories
• Bindings des AES
• Das Desktop-Fenster
• Datenaustausch per Klemmbrett
• Nachrichten
• Objektstruktur im AES
• Quarter-Screen-Buffer
• Rechteckliste eines Fensters
• Screen-Manager
• Toolbar-Support

Auch beim AES gibt es eine interessante Entwicklung, denn verschiedene Programmierer haben mittlerweile eigene AES-Clones angekündigt; zur Zeit sind hier die Projekte N.AES und XaAES zu nennen. Neben einer stetigen Weiterentwicklung darf man wohl auch auf eine Quelltext-Version dieser GEM Komponente hoffen.

Querverweis: Style-Guidelines

8.2.1 Accessories

• Startupcode für Accessories
• Accessories in MagiC

8.2.1.1 Startupcode für Accessories

Um zu testen, ob eine Applikation als Programm oder als Accessorie gestartet worden ist, kann man wie folgt vorgehen:

• wenn beim Programmstart das Register a0 den Wert Null hat, dann handelt es sich um einen normalen Programmstart
   

• anderenfalls handelt es sich um ein Accessorie, und Register a0 enthält einen Zeiger auf die (unvollständig) ausgefüllte BASEPAGE. Die TPA ist bereits passend geschrumpft (auf die Summe von Basepagegröße und der Länge der drei Programmsegmente), ein Stack muß erst noch angelegt werden.
   

Hinweis: Mit diesen Informationen ist es kein Problem, den Startupcode für ein Programm so zu gestalten, daß es selbständig erkennt, wie das Programm gestartet worden ist, und entsprechend die Initialisierung fortzusetzen. Bei den meisten C-Compilern wird im Startupcode automatisch die externe Variable _app initialisiert, die genau dann gleich Null ist, wenn das Programm als Accessorie gestartet worden ist. Damit kann man Programme so entwickeln, daß sie sowohl als Accessorie als auch als normales Programm eingesetzt werden können.

Querverweis: AES   Accessories in MagiC   Programmstart und TPA

8.2.1.2 Accessories in MagiC

Unter MagiC sind Accessories den Programmen fast gleichgestellt. Ihre Fenster bleiben beim Programmwechsel erhalten. Sie dürfen Menü und Desktophintergrund besitzen, Programme nachladen, Speicher anfordern, Dateien öffnen, schließen, löschen, kopieren usw.

Da kein Grund mehr besteht, beim Programmwechsel Fenster zu schließen, gibt es keine AC_CLOSE Meldung mehr. Accessories werden vom System nicht von Programmen unterschieden, abgesehen davon, daß sie sich keinesfalls beenden dürfen. ACCs dürfen sich wie unter GEM/2 auch wieder im Menü abmelden, und zwar mit dem AES-Aufruf menu_unregister(). Anstelle von ACCs sind unter MagiC Applikationen sinnvoll, die einfach nur eine Menüleiste mit einem Menü anmelden und im APP- Autostart- Ordner liegen. Diese Applikationen kann man dann bei Bedarf nachladen und auch wieder entfernen.

Hinweis: Ab MagiC-4 können Accessories zur Laufzeit nachgestartet werden. Ferner ist es möglich, bei einem Klick auf einen Accessory-Eintrag (und gedrückter Control-Taste) das entsprechende Accessory zu entfernen. Ein Nachteil ist, daß Accessories z.Zt. noch kein Pexec mit Modus 104 ausführen dürfen.

Querverweis: AES   GEM   Startupcode für Accessories   shel_write

8.2.2 Das Desktop-Fenster

Unter den verfügbaren Fenstern nimmt das Desktop- oder Hintergrundfenster eine besondere Rolle ein. Es besitzt die Kennung 0, nimmt die gesamte Bildschirmfläche in Anspruch, ist immer geöffnet und kann auch nicht geschlossen werden. Der Arbeitsbereich ist die Fläche unter der Menüleiste. Nur in diesem Arbeitsbereich dürfen andere Programme Bildschirmausgaben machen oder eigene Fenster öffnen.

Normalerweise erscheint der Arbeitsbereich des Desktop als solide grüne Fläche (im Farbbetrieb) bzw. als graues Raster (im Monochrombetrieb). Der Screen-Manager kümmert sich völlig selbsttätig um den Redraw; über einen Aufruf von wind_set können Anwendungsprogramme einen beliebigen anderen Objektbaum als Hintergrund verankern. Auch dann kümmert sich der Screen-Manager um das fällige Neuzeichnen von Bildausschnitten. Obwohl diese Möglichkeit sehr verlockend ist, gibt es etliche Gründe, die gegen eine Benutzung des Desktop-Fensters sprechen; der wichtigste:

• auch unter einem multitaskingfähigen GEM (MagiC oder MultiTOS), kann es nur einen Bildschirmhintergrund geben. Dieser sollte dem Programm vorbehalten bleiben, das daraus den meisten Nutzen ziehen kann - in der Regel ist dies das Desktop bzw. ein Desktop-Ersatz wie z.B. die Shell Gemini.
   

Fazit: Der Desktop-Hintergrund sollte nach Möglichkeit in eigenen Programmen nicht benutzt werden.

Querverweis: AES   wind_set   WF_NEWDESK

8.2.3 Der Datenaustausch über das GEM-Klemmbrett

Um Dateien im Klemmbrett abzulegen, sollte man folgendermaßen vorgehen:

• alle Klemmbrett-Dateien, die auf die Maske 'scrap.*' und 'SCRAP.*' passen, löschen. Anmerkung: Die Maske 'SCRAP.*' muss berücksichtigt werden, da alte Programme noch nichts von alternativen und case-sensitiven Dateisystemen wussten.
• die abzulegenden Daten in einem oder mehreren Formaten sichern.
• die Nachricht SC_CHANGED an alle Applikationen im System, SH_WDRAW an die System-Shell schicken.

Der Dateiname ist immer 'scrap.', die Namenserweiterung (Suffix) hängt dabei vom gewählten Format ab; nach Möglichkeit sollte immer eines der folgenden Standardformate unterstützt werden:

Zusätzlich kann man eines oder mehrere der folgenden Formate unterstützen (der Empfänger hat dann die Möglichkeit, das Format mit den meisten Informationen zu benutzen):

Das empfangende Programm sollte zunächst überprüfen, welche der vorhandenen Dateien die meisten Informationen enthält, und dann diese Datei nehmen.

Wichtig: Jede der Dateien im Klemmbrett enthält prinzipiell die gleichen Informationen, nur eben in einem anderen Format. Die Textverarbeitung Papyrus z.B. importiert 'scrap.rtf' nur dann, wenn das eigene Format 'scrap.pap' nicht gefunden werden konnte.

Aus den obigen Erklärungen wird ersichtlich, daß sich immer nur ein Datenobjekt (allerdings in verschiedenen Formaten) auf einmal im Klemmbrett befinden kann.

Querverweis: Klemmbrett-Funktionen   scrp_clear   Style-Guidelines

8.2.4 Die Objekt-Struktur

Die Datenstruktur des Objektbaums ist zwar kein Baum im Sinne eines Binärbaums, besitzt jedoch innerhalb eines Zeigers die logischen Verkettungen eines Baums, mit Vorgängern und Nachfolgern. Die Spezifikation von Vorgängern und Nachfolgern wird durch Indizes auf ein Array vorgenommen.

Die Baumstruktur der einzelnen Objekte kann man sich am leichtesten an Hand eines einfachen Beispiels veranschaulichen: Ein Menü setzt sich zunächst aus der Menüleiste zusammen. Diese enthält wiederum mehrere Titeltexte. Die Titeltexte sind also direkt in der Menüleiste enthalten, sie sind beide Nachfolger des Objekts 'Menüleiste', bewegen sich also auf der selben hierarchischen Ebene. Das Objekt Menüleiste verweist mit ob_head auf den ersten Menütitel und mit ob_tail auf den letzten Menütitel. Im ersten Menütitel dient der Zeiger ob_next zur Adressierung des nächsten Menütitels. Die Verkettung weist also folgende Struktur auf:

      Menüleiste:
   +---------+---------+--------+
   | ob_head | ob_tail | ...    |
   |    o    |    o    |        |
   +----|----+----|----+--------+
        |         +-------------------------+
        V                                   V
   +---------+---------+--------+       +---------+---------+--------+
   | ...     | ob_next | ...    |  ...  | ...     | ...     | ...    |
   |         |    o    |        |       |         |         |        |
   +---------+----|----+--------+       +---------+---------+--------+
      1.Menütitel |                         n-ter Menütitel
                  +-----> 2.Menütitel

Welche Aktionen mit einem Objekt durchgeführt werden dürfen, wird in ob_flags festgelegt. Der Zustand eines Objekts wird im Eintrag ob_state festgehalten. Der Eintrag ob_type legt den Objekttyp fest. Manche Objekte benötigen zur exakten Festlegung eine zusätzliche Datenstruktur, wie TEDINFO oder BITBLK. In ob_spec wird dann ein Zeiger auf diese zusätzliche Struktur abgelegt. Zusammenfassend nochmals der Gesamtaufbau der Datenstruktur für Objekte OBJECT:

         +-------------+
         |  ob_next    |   Index für das nächste Objekt
         +-------------+
         |  ob_head    |   Index des ersten Kindes
         +-------------+
         |  ob_tail    |   Index des letzten Kindes
         +-------------+
         |  ob_type    |   Objektart
         +-------------+
         |  ob_flags   |   Manipulationsflags
         +-------------+
         |  ob_state   |   Objektstatus
         +-------------+
         |  ob_spec    |   siehe unter Objektart
         +-------------+
         |  ob_x       |   relative x-Koordiante zum Eltern-Objekt
         +-------------+
         |  ob_y       |   relative y-Koordinate zum Eltern-Objekt
         +-------------+
         |  ob_width   |   Breite des Objekts
         +-------------+
         |  ob_height  |   Höhe des Objekts
         +-------------+

Querverweis: Objektfarben des AES   Objektart   Manipulationsflags   Objektstatus

8.2.4.1 Objektarten des AES

Folgende Objektarten stehen zur Auswahl:

Hinweis: Für G_BOX, G_IBOX und G_BOXCHAR zeigt die Komponente ob_spec der OBJECT-Struktur nicht auf eine andere Datenstruktur, sondern enthält weitere Informationen zum Aussehen des Objektes. Dabei gilt:

Das Hibyte wird vom AES nur für Submenüs verwendet. Ist das höchste Bit von ob_type 0x8000, sowie das Bit SUBMENU in ob_flags gesetzt, so geben die Bits 8..14 an, welches Submenü mit dem Menüeintrag gekoppelt ist. Jede Applikation kann daher maximal 128 Submenüs haben. MagiC liest aus ob_type stets nur das Lowbyte aus, außer für die Submenü-Behandlung. TOS reagiert auf unbekannte Objekttypen (z.B. die reinen MagiC-Typen G_SWBUTTON usw.) sauber, d.h. die Objekte werden nicht gezeichnet.

Querverweis: Objektstruktur im AES   Objektfarben des AES

8.2.4.2 Objektfarben des AES

Die folgende Tabelle enthält die vordefinierten Objektfarben. Einzelheiten hängen natürlich von der gewählten Bildauflösung, sowie den Einstellungen des Benutzers ab.

Hinweis: Diese Farben entsprechen auch weitestgehend den unter Windows und OS/2 verwendeten Iconfarben. Über ein geeignetes CPX-Modul können die richtigen RGB-Werte für die ersten 16 Farben eingestellt werden.

Querverweis: Objektstruktur im AES   Objektarten des AES

8.2.4.3 Objektflags des AES

Die Manipulationsflags eines Objektes bestimmen seine Eigenschaften. Folgende Möglichkeiten stehen zu Auswahl:

Querverweis: Objektstruktur im AES   Objektarten des AES

8.2.4.4 Objektstati des AES

Vom Objektstatus hängt es ab, wie ein Objekt später auf dem Bildschirm dargestellt wird. Ein Objektstatus kann von folgendem Typ sein:

In GEM/5, CROSSED makes the object draw in 3D:

• If an object is both CROSSED and SELECTABLE, then it is drawn as a checkbox.
• If it is CROSSED, SELECTABLE and an RBUTTON, it is drawn as a radio button.
• If it is a button or a box and it is CROSSED, then it is drawn as a raised 3D shape, similar to Motif.
• If a button is CROSSED and DEFAULT, a "Return key" symbol appears on it (rather like NEXTSTEP).
• Boxes and text fields that are CROSSED and CHECKED appear sunken.

GEM/5 can be detected by calling vqt_name for font 1. If nothing is returned, GEM/5 is running.

Recent FreeGEM builds contain a system based on the GEM/5 one, but extended and backwards-compatible. The DRAW3D state is used instead of CROSSED:

• If an object is both DRAW3D and SELECTABLE, then it is drawn as a checkbox.
• If it is DRAW3D, SELECTABLE and an RBUTTON, it is drawn as a radio button.
• If a button is DRAW3D and DEFAULT, a "Return key" symbol will be on it.
• If an object with a 3D border has the WHITEBAK state, then the 3D border will not have a black edge.
• If a radio button or checkbox has the WHITEBAK state, then it will be drawn with a white background rather than in the colour used by 3D objects.

To check for these abilities, use appl_init and check that bit 3 of xbuf.abilities is set.

Querverweis: Objektstruktur im AES   Objektarten des AES

8.2.5 Der Quarter-Screen-Buffer

Der Quarter-Screen-Buffer wird vom Screen-Manager benötigt, um beim Herunterklappen von Drop-Down-Menüs den Inhalt des Menühintergrundes zu retten. Auch bei der Anzeige von Alarmboxen kommt der 'QSB' (so die gebräuchliche Abkürzung) zum Einsatz. Normalerweise sollte seine Größe von der Anzahl der Farbebenen und der Größe des Systemzeichensatzes, nicht aber von der Gesamtgröße des Bildschirms abhängen.

Eine gute Formel wäre:
   500(Zeichen) * Platzbedarf eines Zeichens * Farbebenen

Damit käme man in der Auflösung 'ST-Hoch' genau auf den Wert 8000 (also ein Viertel des Bildspeichers). Leider ist das AES in vielen Fällen jedoch nicht so clever; die folgende Tabelle enthält eine Übersicht über die benutzten Algorithmen einiger GEM-Versionen:

Hinweis: Die GEM-Versionen 1.0 und 1.2 (also bis einschließlich TOS-Version 1.02) sind mithin nicht für Farbgrafikkarten vorbereitet - einer unter mehreren Gründen, warum man selbst bei Benutzung eines speziellen VDI-Treibers unter diesen GEM-Versionen Farbgrafikkarten nicht einsetzen kann.

Querverweis: GEM

8.2.6 Die Rechteckliste eines Fensters

Um dem Problem sich überlappender Fenster zu begegnen, unterhält das AES für jedes Fenster die sogenannte Rechteckliste; alle Elemente dieser Liste ergeben gerade den komplett sichtbaren Arbeitsbereich des entsprechenden Fensters.

Um ein Fenster (bzw. dessen Inhalt) neu zu zeichnen erfragt man zunächst per wind_get( WF_FIRSTXYWH) das erste Rechteck der o.g. Liste. Dann stellt man fest, ob sich dieses Rechteck mit dem neu zu zeichnenden Bildschirmbereich überschneidet; dann und nur dann zeichnet man diesen Bereich unter Ausnutzung von vs_clip neu.

Diese Methode wird mit allen übrigen Elementen der Rechteckliste fortgesetzt, bis die Höhe und Breite eines Rechtecks den Wert Null besitzen.

Querverweis: Clipping   WM_REDRAW   wind_get   wind_update

8.2.7 Der Screen-Manager

Der Screen-Manager ist immer aktiv und überwacht die Position des Mauszeigers, wenn dieser den Arbeitsbereich der Fenster anderer Applikationen verläßt. Die hier in Frage kommenden Flächen sind die Rahmen der Fenster, die Drop-Down-Menüs und die Menüleiste.

Beim Berühren des Menübereichs sorgt der Screen-Manager selbsttätig dafür daß der vom Menü belegte Bildschirmausschnitt gesichert und anschließend wiederhergestellt wird (dazu wird der Quarter-Screen-Buffer benutzt).

Auch Manipulationen an den Fensterkontrollen führen nicht zu dauerhaften Veränderungen des Bildspeichers; Resultat der Interaktionen mit dem Screen-Manager sind die sogenannten Mitteilungsereignisse, die die zuständige Applikation über die Aktion des Benutzers informieren.

Hinweis: Die ID des Screen-Managers kann übrigens leicht durch einen Aufruf von appl_find("SCRENMGR") ermittelt werden.

Querverweis: AES   GEM   Nachrichten

8.2.8 Toolbar-Support

Ab AES-Version 4.1 unterstützt das Betriebssystem sogenannte Toolbars. Es handelt sich dabei um einen OBJECT-Baum, der unterhalb der Info-Zeile eines Fensters (und über dem Arbeitsbereich) plaziert wird, und die Darstellung von Buttons, Icons etc. im Fenster ermöglicht.

Wie bereits von den Fensterroutinen bekannt, wird die Verwaltung einer Toolbar zwischen dem AES und der Applikation aufgeteilt. Dabei ist das AES für die folgenden Aktionen verantwortlich:

• Anpassung der x- und y-Koordinaten der Toolbar, wenn das Fenster bewegt oder in der Größe verändert wird.
• Sicherstellung, daß das Fenster auf die für die Fenster-Komponenten und die Toolbar notwendige Größe konfiguriert wird.
• Anpassung der Breite der Toolbar an die Breite des Fensters.
• Neuzeichnung der Toolbar beim Eintreffen einer WM_REDRAW-Nachricht.
• Verschicken von AES-Nachrichten, wenn der Benutzer ein Objekt der Toolbar aktiviert.

Die Applikation hingegen muss sich um die folgenden Dinge kümmern:

• Aufbau eines OBJECT-Baumes für die Toolbar (insbesondere muss darauf geachtet werden, daß alle anwählbaren Elemente der Toolbox den Status TOUCHEXIT besitzen).
• Anpassung der Breite eines Objektes der Toolbar, falls dieses von der Breite des Fensters abhängig ist (wird evtl. beim Verändern der Größe des Fensters notwendig sein).
• Behandlung von USERDEF-Objekten.
• Neuzeichnung alle Objekte, deren optische Erscheinung geändert werden soll. In diesem Fall muss unbedingt die Rechteckliste der Toolbar abgefragt bzw. berücksichtigt werden.
• Probleme die im Zusammenhang mit der Bildschirmauflösung stehen, müssen gelöst werden. So kann z.B. die Höhe eines Icons in der mittleren ST-Auflösung von der Höhe des Icons in der mittleren TT-Auflösung abweichen.

Bei der Unterstützung von Toolbars in eigenen Programmen sollten die folgenden Punkte beachtet werden:

• Kommunikation mit dem AES-Window-Manager
• Probleme bei wind_calc
• Redraw und Updating von Toolbars
• Toolbar-Support unter XaAES

Querverweis:
WF_TOOLBAR   WF_FTOOLBAR   WF_NTOOLBAR   WM_TOOLBAR   wind_get   wind_set

8.2.8.1 Redraw und Updating von Toolbars

Bei der Neuzeichnung (von Teilen) der Toolbar ist, wie üblich, die Rechteckliste zu beachten. Da die bisherigen wind_get Opcodes WF_FIRSTXYWH und WF_NEXTXYWH jedoch nur den Arbeitsbereich eines Fensters berücksichtigen, wurden zwei neue Parameter (WF_FTOOLBAR und WF_NTOOLBAR) eingeführt, mit deren Hilfe die Rechteckliste für eine Toolbar abgefragt werden kann.

Ein Redraw (von Teilen) der Toolbar kann in den folgenden Situationen notwendig sein:

• die Toolbar enthält benutzerdefinierte Objekte (USERDEF's).
• der Status eines Objektes der Toolbar wurde verändert. Der neu zu zeichnende Bereich besteht dabei aus der Größe des Objektes zzgl. des Platzes, welcher für Spezialeffekte (3D, Shadowing, Outline etc.) beansprucht wird.

Nicht notwendig ist ein Neuzeichnen z.B. in folgenden Fällen:

• das entsprechende Fenster ist ikonifiziert. Die Applikation braucht sich um keinerlei Verwaltung der Toolbar zu kümmern; dies ist erst wieder nach der Aufhebung des Iconify, dem sogenannten Uniconify, notwendig.
• die im Fenster vorhandene Toolbar soll durch eine andere ersetzt werden. In diesem Fall reicht ein Aufruf von wind_set mit dem Opcode WF_TOOLBAR und der Adresse des neuen OBJECT-Baumes aus.
• die im Fenster vorhandene Toolbar soll entfernt werden. In diesem Fall reicht ein Aufruf von wind_set mit dem Opcode WF_TOOLBAR und NULL-Parametern aus.

Querverweis: Rechteckliste eines Fensters   Toolbar-Support

8.2.8.2 Toolbars und der Window-Manager

Zur Handhabung von Toolbars kann eine Applikation auf den Window-Manager des AES zurückgreifen. Im einzelnen:

Um eine Toolbar an ein Fenster anzuheften, genügt ein Aufruf von wind_set(handle, WF_TOOLBAR, ...) mit der Adresse des Toolbar-Objektbaumes. Falls dieser Aufruf durchgeführt wird während das Fenster geöffnet ist, so ist dieses selbst für die korrekte Berechnung der Höhe der Toolbar verantwortlich.

Um eine Toolbar gegen eine andere auszutauschen, kann auf einen Aufruf von wind_set(handle, WF_TOOLBAR, ...) mit der Adresse der neuen Toolbar zurückgegriffen werden. Falls dieser Aufruf durchgeführt wird während das Fenster geöffnet ist, so ist dieses selbst für die korrekte Berechnung der Höhe der (neuen) Toolbar verantwortlich.

Um eine Toolbar aus einem Fenster zu lösen, ist ein Aufruf von wind_set(handle, WF_TOOLBAR, ...) mit NULL Parametern erforderlich. Falls dieser Aufruf durchgeführt wird während das Fenster geöffnet ist, so ist dieses selbst für die korrekte weitere Bearbeitung verantwortlich.

Darüber hinaus sind die folgenden Punkte zu beachten:

• Wird ein Fenster per wind_close geschlossen, so wird eine evtl. vorhandene Toolbar nicht entfernt. Bei einem späteren Öffnen ist die Toolbar also weiterhin vorhanden.
• Wird ein Fenster per wind_delete entfernt, so wird auch die Verbindung zur Toolbar aufgelöst.
• Um Mausklicks auf Toolbar-Objekte erkennen zu können, müssen diese den Status TOUCHEXIT besitzen. Bei einem Klick auf ein solches Objekt wird vom AES eine WM_TOOLBAR-Nachricht erzeugt, und an die betreffende Applikation geschickt.

Querverweis: AES   GEM   Toolbar-Support

8.2.8.3 Probleme bei wind_calc in Toolbar-Fenstern

Beim Einsatz der Funktion wind_calc auf Fenster, die eine Toolbar beinhalten, sind einige Probleme zu berücksichtigen:

Da dieser Funktion keine Fenster-Kennung (Window-Handle) übergeben wird, können die gewünschten Größen nicht korrekt berechnet werden, wenn sich eine Toolbar im Fenster befindet. Der Grund liegt ganz einfach darin, daß das AES in diesem Fall keine Informationen über die Toolbar, und speziell über deren Größe besitzt.

Daher müssen in diesem Fall die von wind_calc gelieferten Werte von der Applikation weiter aufbereitet werden. Da das Programm auf den entsprechenden OBJECT-Baum (und damit auch auf die Höhe der Toolbar) zugreifen kann, ist dies problemlos möglich. Konkret:

• Bei der Ermittlung des Randbereiches des Fensters, muß die Höhe der Toolbar auf die von der Funktion gelieferte Höhe addiert werden.
• Bei der Ermittlung des Arbeitsbereiches des Fensters, muß die Höhe der Toolbar auf den von der Funktion gelieferten y-Wert (couty) addiert werden.

Hinweis: Die Höhe der Toolbar sollte neben der Höhe des eigentlichen Objektes den Platzbedarf für Spezialeffekte (3D, Shadowing, etc.) beinhalten.

Querverweis: WF_FTOOLBAR   WF_NTOOLBAR   WM_TOOLBAR   objc_sysvar

8.2.9 AES-Bindings

Das AES wird über ein einziges Unterprogramm aufgerufen, dem 6 Parameter übergeben werden; es handelt sich dabei um Adressen verschiedener Arrays, die zur Ein-/Ausgabe-Kommunikation benutzt werden. Um eine AES-Funktion aufzurufen, muß der folgende Parameterblock mit den Adressen der unten beschriebenen Arrays bestückt werden:

typedef struct
{
    int16_t *cb_pcontrol;  /* Zeiger auf control-Array */
    int16_t *cb_pglobal;   /* Zeiger auf global-Array  */
    int16_t *cb_pintin;    /* Zeiger auf int_in-Array  */
    int16_t *cb_pintout;   /* Zeiger auf int_out-Array */
    int16_t *cb_padrin;    /* Zeiger auf adr_in-Array  */
    int16_t *cb_padrout;   /* Zeiger auf adr_out-Array */
} AESPB;

Die Adresse dieses Parameterblocks (der sich auf dem Stack befindet), muß dann im Register d1 vermerkt, und zusätzlich Register d0.w mit dem Wert 0xc8 (200) gefüllt werden. Durch einen TRAP #2 Systemaufruf kann dann das AES direkt aufgerufen werden. Für den Pure-Assembler könnte das z.B. so aussehen:

                .EXPORT aes         ; Funktion exportieren
                .CODE               ; Beginn des Code-Segments

        aes:     MOVE.L 4(sp),D1    ; Adresse des Parameterblocks
                 MOVE.W #200,D0     ; Opcode des AES
                 TRAP   #2          ; GEM aufrufen
                 RTS                ; raus hier

                .END                ; Ende des Moduls

Darüber, welche Register verändert werden dürfen, gibt es keine klaren Informationen. Tatsache ist jedoch, daß die entsprechenden Routinen im ROM alle Register retten.

Nun zu den einzelnen Arrays. Über jedes Feld können bestimmte Ein- bzw. Ausgaben getätigt werden; es gilt:

Achtung: Wenn das Betriebssystem Threads unterstützt, muss unbedingt darauf geachtet werden, eine Multithread-sichere Bibliothek zu verwenden. Insbesondere muss sichergestellt werden, daß jeder Thread sein eigenes global-Feld (s.o) erhält.

Querverweis: Beispiel-Binding   VDI-Bindings   TOS Liste

8.2.9.1 Beispiel-Binding für AES-Funktionen

Die Funktion 'crys_if' (Crystal Interface) sorgt für die Besetzung des control-Arrays, und macht den eigentlichen AES-Aufruf. Dazu bedient sie sich einer Tabelle, in der für jede einzelne AES-Funktion die Werte für control[1], control[2] und control[3] vermerkt sind.

AESPB c;

int16_t crys_if (int16_t opcode)
{
  int16_t i, *paesb;

  control[0] = opcode;
  paespb = &ctrl_cnts[ (opcode-10)*3 ];

  for (i = 1; i < 4; i++)
    control[i] = *paespb++;

  aes (c);
  return (int_out[0]);

} /* crys_if */

Die dabei verwendete Tabelle könnte beispielsweise folgendermaßen aufgebaut sein:

.GLOBAL ctrl_cnts
.DATA

ctrl_cnts: .dc.b     0,  1,  0       ; appl_init
           .dc.b     2,  1,  1       ; appl_read
           .dc.b     2,  1,  1       ; appl_write
            ...
            ...
            ...

.END

Querverweis: AES-Bindings   GEM

AES

Das AES

Applikationsfunktionen