Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File9.1  Das XCONTROL                                                  TOS

XControl ist ein modulares (erweiterbares) Kontrollfeld, das von Atari 
zuerst mit den Computern der TT und Mega-STE Serie ausgeliefert wurde.


Die einzelnen Module sind Dateien mit der Namenserweiterung '.CPX' 
(Control-Panel eXtension), und XControl selbst kann als 
Steuerungsprogramm für diese Module angesehen werden.

Wichtig: XControl sollte nur als Tool für Konfigurationsdialoge 
angesehen werden, und nicht für andere Zwecke mißbraucht werden.

Die Kommunikation zwischen XControl und seinen Modulen erfolgt über 
zwei Strukturen, die mit XCPB und CPXINFO bezeichnet werden. Über 
erstere werden einige Flags sowie eine ganze Reihe von Hilfsfunktionen 
zugänglich gemacht.

Beim Start lädt XControl alle verfügbaren CPX-Header; sofern im Header 
ein entsprechendes Flag gesetzt ist, werden alle CPX-Dateien einmal 
zum initialisieren aufgerufen. Für jedes einzelne Modul kann angegeben 
werden, ob es resident geladen werden soll (dies kann auch über das 
mitgelieferte Konfigurations-CPX verändert werden). Darüber hinaus ist 
es möglich, CPX-Module zu schreiben, die nur bestimmte Werte setzen. 
Man spricht in diesem Zusammenhang von 'Set-Only'-Modulen, die nur 
beim Booten bzw. erneuten Laden der CPX-Module durch XControl 
aufgerufen werden, und bei der Initialisierung einfach einen 
Nullzeiger zurückliefern.

Sobald ein CPX-Modul vom Anwender ausgewählt wird, lädt XControl 
dieses in den Speicher, und ruft die Funktion cpx_init auf. 
Anschließend wird noch cpx_call aufgerufen, wobei im wesentlichen nun 
das Modul selbst die Steuerung übernimmt.

Man unterscheidet zwischen Form-CPX und Event-CPX. Erstere sind 
relativ einfach zu programmieren, bieten jedoch nur eine 
eingeschränkte Flexibilität. Letztere sind flexibler, da sie die AES- 
Events direkt auswerten. Alle mit XControl 1.0 ausgelieferten CPX- 
Module sind Form-CPX Dateien, woraus geschlossen werden kann, daß 
Form-CPX in den meisten Fällen ausreichen.

Für die Dateinamen von CPX-Modulen gilt die folgende Terminologie:

 Suffix   Bedeutung 
 *.CP     Standard-CPX ohne Header 
 *.CPX    Standard-CPX, fertig zum Gebrauch 
 *.CPZ    inaktive CPX (von XControl deaktiviert) 
 *.HDR    Header für die CPX-Datei 
 *_R.CPX  residente CPX-Datei 
 *_S.CPX  Set-Only CPX-Datei 

Der Aufbau einer CPX-Datei ist einem normalen Programm sehr ähnlich. 
Sie besteht aus einem 512 Byte großen Header und dem übrigen 
Dateiinhalt, bei dem es sich fast um eine normale GEMDOS-Programmdatei 
handelt. Der Header ist dabei wie folgt definiert:

typedef struct
{
    uint16_t magic;                 /* Magic-Konstante = 100   */

    struct
    {
        unsigned reserved : 13;  /* reserviert              */
        unsigned resident :  1;  /* RAM-resident            */
        unsigned bootinit :  1;  /* Boot-Initialisierung    */
        unsigned setonly  :  1;  /* Set-Only                */

    } flags;

    int32_t  cpx_id;                /* eindeutige CPX-ID       */
    uint16_t cpx_version;           /* CPX-Versionsnummer      */
    int8_t   i_text[14];            /* Icontext                */
    uint16_t sm_icon[48];           /* Bitmap (32*24 Pixel)    */
    uint16_t i_color;               /* Iconfarbe               */
    int8_t   title_text[18];        /* Name des CPX            */
    uint16_t t_color;               /* Textfarbe               */
    int8_t   buffer[64];            /* nicht-flüchtiger Puffer */
    int8_t   reserved[306];         /* reserviert              */

} CPXHEAD;

Zum Header noch einige Anmerkungen:

   ∙ die erste Funktion im TEXT-Segment muß die 
     Initialisierungsroutine für die CPX sein
   ∙ zur Konstruktion eines CPX-Headers gibt es mehrere Toolkits
   ∙ Header und gelinkte Programmdatei können in den meisten UNIX- 
     ähnlichen Shells (z.B. der Mupfel aus Gemini) mit dem Kommando 
     'cat' zusammengefügt werden.
   ∙ bei der CPX-Entwicklung ist es sehr praktisch, daß man XControl 
     auch als Programm starten kann (Suffix ändern !). Dies erlaubt 
     es, ohne permanentes Neu-Booten des Rechners zu arbeiten.
   ∙ CPX-ID und -Versionsnummer sorgen dafür, daß jede CPX nur ein 
     einziges mal (und auch nur die neueste Version) erscheint.

Bei der Programmierung eines CPX-Moduls sind einige Feinheiten zu 
beachten. Da ein solches Modul (mit Ausnahme von 64 Byte) über keinen 
nichtvergänglichen Speicher verfügt, ist nichts erlaubt, was Speicher 
in irgendeiner Form fest reserviert. Insbesondere gehen 
Variableninhalte mit dem Verlassen der CPX in aller Regel verloren ! 
Daher sollte man:

   ∙ Resourcen statisch einbinden
   ∙ Speicheranforderungen nur kurzzeitig erlauben
   ∙ virtuelle VDI-Workstations nicht dauerhaft anlegen

Bei der Programmierung eines CPX-Moduls kann auf Funktionen der beiden 
folgenden Kategorien zurückgegriffen werden:

   ∙ CPX-Funktionen

   ∙ XCONTROL-Funktionen

Hinweis: Als Alternative zu XCONTROL, welches von Atari nicht mehr 
weiterentwickelt wird, bieten sich verschiedene Programme an. 
Besonders empfehlenswert ist dabei COPS (COntrol Panel Server, mit 
dessen Hilfe sich nicht nur beliebig viele CPX-Module gleichzeitig 
öffnen lassen, sondern das auch Kontrollfelder mit größerer 
Arbeitsfläche als XCONTROL erlaubt.