AES-Funktionen von MagiC 3
--------------------------

Andreas Kromke
27.4.95

- wind_create blendet bei aktivierter Kompatibilitt keine Bits mehr aus.

- WM_BACKDROPPED (Mag!X) wird nicht mehr verschickt, stattdessen wird
  WM_BOTTOMED (AES 4.1) verschickt.
  Alle Programme, die Fenster mit explizitem Backdrop-Element nach Mag!X-
  Konvention erstellen, mssen leider fr MagiC 3.0 gendert werden bzw.
  nicht gendert werden, wenn sie das nicht vorhandene MultiTOS untersttzen.

- AES beherrscht das Ikonifizieren von Fenstern. Folgendes ist zu beachten:
  - wind_get/set liefern Fehlercodes, wenn versucht wird, ikonisierte Fenster
    nochmal zu ikonisieren usw.
  - Der Button liegt rechts, also hat man im Extremfall 3 Buttons am rechten
    Fensterrand. Vielleicht wre es sinnvoll, den Backdrop- Button nach links
    zu verbannen ?
  - Der Algorithmus zum Festlegen der Position des ikonifizierten Fensters
    funktioniert anders als bei MultiTOS. MagiC durchsucht die aktuellen
    Positionen der bereits ikonisierten Fenster und setzt das neue Fenster
    auf einen freien Platz. Ein Platz ist nur dann frei, wenn der Schnitt
    mit der neuen Position leer ist.
  - Das Programm Adresse 1.81 hat Probleme und zeichnet das Icon versetzt
    auf, vielleicht wegen der dicken MultiTOS- Fensterrahmen.
  - INTRFACE und GEMVIEW merken nicht, da das System Ikonisierung
    untersttzt. Wird kein appl_getinfo gemacht ?

- AES kennt einen neuen Objekttyp, den Gruppenrahmen. Erzeugt wird er durch
  Setzen von WHITEBAK sowie durch Setzen des Highbytes von ob_state auf -2.
  Zusammenfassend gibt es jetzt folgende Sondertypen:

  G_STRING:
  ---------
  WHITEBAK=0:  TOS-String, nicht unterstrichen
  WHITEBAK=1,Highbyte!=-1: String, unterstrichen
                           (Highbyte&0xf) ist Unterstreichpos.
  WHITEBAK=1,Highbyte==-1: String, komplett unterstrichen

  G_BUTTON:
  ---------
  WHITEBAK=0:  TOS-Buttons, nicht unterstrichen
  WHITEBAK=1,Bit15=0:    TOS-Buttons,unterstrichen
                           (Highbyte&0xf) ist Unterstreichpos.
  WHITEBAK=1,Bit15=1:    Sonderbuttons (rund oder Kreuzchen)
   Highbyte=-2:     Gruppenrahmen
   Highbyte=-1:     Sonderbutton, nicht unterstrichen
   Highbyte!=-1/-2  Sonderbutton, unterstrichen
                           (Highbyte&0xf) ist Unterstreichpos.

- AES untersttzt jetzt 3D-Objekte nach AES 4.0-Norm. Die Typen "Background",
  "Activator" und "Indicator" werden verarbeitet.
  Unterschiede zu AES 4.0:

  - In TOS 4.0 kann man per objc_sysvar das Verhalten von "Indicator" und
    "Activator" sowie die Farben beeinflussen, in MagiC kann man die Daten
    zwar abrufen, aber nicht verndern. "Activator" werden bei SELECTED immer
    eingedrckt, "Indicator" oder "Background" werden verfrbt.
  - MagiC UNTERSTTZT DEFINITIV KEINE 3D-EFFEKTE, WENN WENIGER ALS 16 FARBEN
    GLEICHZEITIG MGLICH SIND. DIE ENTSPRECHENDEN OBJEKTE SEHEN DANN EINFACH
    "FLACH" AUS.
    appl_getinfo() liefert bei weniger als 16 Farben oder bei explizit
    deaktivierten 3D-Objekten die Information: Keine 3D-Objekte vorhanden.
  - Fr alle Objekttypen knnen 3D-Effekte angefordert werden. D.h. auch
    fr Texteingabefelder, berschriften, Gruppenrahmen usw.
  - 3D-Objekte bekommen keinen zustzlichen Rahmen und ndern sich daher
    nicht in der Gre. Je nach Rahmenbreite stehen sie weiter heraus und
    haben ggf. auch noch einen zustzlichen Rand und Schatten.
    berschriften sollten statt bisher 1+2 die Hhe 1+3 haben, damit es
    ordentlich aussieht.
  - Bei 3D-Objekte vom Typ G_USERDEF werden die 3D-Effekte nicht vom System
    gezeichnet, wie dies bei MTOS der Fall ist (?). Dies darf auch nicht sein,
    weil bei MagiC die 3D-Rnder innerhalb des Objekts liegen und dieses
    nicht berschrieben werden darf.
  - Damit die Fensterrnder nicht verbreitert zu werden brauchten, werden
    jetzt innerhalb von Buttons oder Boxchars die Zeichen auch dann
    ausgegeben, wenn die Box zu klein ist. Das Problem ergab sich bei den
    Fensterelementen, die die Hhe (text+3) haben, aber eigentlich mindestens
    (text+4) bentigen.
  - Das Namensfeld der Fenster ist nicht 3D. Dies kann mit der nchsten
    Version des Programms "wincolor.cpx" von Martin Osieka aber beeinflut
    werden. Dann lt sich fr jedes Fensterelement angeben, ob es 3D sein
    soll oder nicht.
  - Die "Schmuckrnder" fr Dialogboxen werden genau dann erzeugt, wenn ein
    Rahmen von 2 innen und OUTLINED angewhlt wurde.

- Die gesamte 3D-Untersttzung kann abgeschaltet werden, indem das Bit 1 des
  Flags in magx.inf gesetzt wird (Bit 0 ist fr die Position des Logos
  zustndig. Bei laufendem Betrieb kann dann immer noch per objc_sysvar()
  umgeschaltet werden.
- AES untersttzt jetzt objc_sysvar mit folgenden Unterfunktionen. Die
  Parameter:

     #define LK3DIND      1
     #define LK3DACT      2
     #define INDBUTCOL    3
     #define ACTBUTCOL    4
     #define BACKGRCOL    5
     #define AD3DVALUE    6
     #define MX_ENABLE3D  10

  Mit MX_ENABLE3D kann man in MagiC komplett und global alle 3D-Objekte
  deaktivieren, d.h. auch Fensterrahmen, Dateiauswahl, Fensterrand usw.
  Ferner kann man abfragen, ob z.Zt. 3D untersttzt wird. Der Versuch, 3D
  zu aktivieren, wenn weniger als 16 Farben zur Verfgung stehen, fhrt zu
  einer Fehlermeldung durch objc_sysvar().
  MagiC UNTERSTTZT DEFINITIV KEINE 3D-EFFEKTE, WENN WENIGER ALS 16 FARBEN
  GLEICHZEITIG MGLICH SIND. DIE ENTSPRECHENDEN OBJEKTE SEHEN DANN EINFACH
  "FLACH" AUS.
  AD3DVALUE liefert immer 0, weil MagiC die Objektgren nicht antastet.
  Als Farben werden immer 8 (hellgrau) und 9 (dunkelgrau) verwendet.
- objc_sysvar liefert Fehlercode, wenn keine 3D-Effekte aktiviert sind.

- Auch Objekte ohne Rand werden im Fall 3D in grau statt wei gezeichnet

- F_TEXT und F_BOXTEXT haben nur dann den eingedrckten Rand um das Eingabe-
  feld, wenn ein Rand von mindestens 2 Pixeln auerhalb angegeben ist. Damit
  stimmen die Objektausmae wieder.
- Im Fall G_FBOXTEXT und 3D-Modus "Activator" wird eine Art Button wie unter
  MTOS gezeichnet, der Eingabebereich wird dabei nicht hervorgehoben.

- AES schickt beim (De-)Ikonifizieren explizit eine Redraw-Nachricht, auch
  wenn sich die Gre nicht gendert hat.

- Der "Crossbutton" hat immer eine ungerade Hhe, damit im Kreuzungspunkt
  der Linien kein dicker Punkt entsteht.

- Nicht bentigte Fensterrnder (links oder unten) werden wie bei AES 4.x
  weggelassen. Derartige Fenster sehen zwar bescheiden aus, aber bringen
  immerhin ein paar Pixel mehr an nutzbarer Flche.

- Bit 2 des Flags von MAGX.INF schaltet den expliziten Backdrop-Button aus
  und bewirkt, da ein kurzer Klick auf das Namensfeld eines aktiven Fensters
  ein Backdrop bewirkt. Das ist fast die Vorgehensweise von AES 4.x, bis auf
  die Tatsache, da MagiC nach wie vor den Backdrop selbst erledigt, wenn die
  Applikation dazu selbst nicht in der Lage ist.

- Bei 3D-Dialogen wird eine passende Flugecke gezeichnet.

- Das ARGV-Verfahren wird untersttzt. Hiermit knnen beliebig lange
  Kommandozeilen bergeben werden, die auerdem Leerstellen und alle
  mglichen anderen Zeichen enthalten drfen.
  Als Lngenbyte in der Kommandozeile der Basepage wird dabei $7f
  eingetragen, die Argumente (einschlielich argv[0] als Kommando, d.h. als
  Programmdatei) werden im Environment bergeben. Das Environment enthlt
  dazu folgende Variablen hinter allen anderen:

     "ARGV=irgendwas\0"
     "arg0\0"
     "arg1\0"
     ...
     "argn\0\0"

  Die Argumente folgen also der Variablen ARGV, sind durch Nullbytes getrennt
  und durch zwei Nullbytes abgeschlossen.
  Beispielprogramme zur Auswertung von ARGV gibt es von Atari. Ob es
  berhaupt ein Programm gibt, das ARGV auswertet, wei ich nicht und
  bezweifle ich auch.

  MultiTOS implementiert das Verfahren im AES. Man mu den Parameter iscr,
  der in MagiC anderweitig belegt ist und "isover" heit, auf 1 setzen, dann
  erstellt MultiTOS das ARGV im Environment.

  MagiC implementiert ARGV auf einem tieferen Level. Das ARGV- Verfahren wird
  auf drei Arten bereits von Pexec untersttzt:

     1. Ist das Lngenbyte der Kommandozeile $7f, geht Pexec davon aus, da
        das aufrufende Programm ARGV untersttzt und das Environment
        entsprechend manipuliert ist.
        Pexec ndert daher nicht das Environment.
     2. Ist das Lngenbyte $fe, erwartet MagiC direkt dahinter die
        Zeichenkette "ARGV=", gefolgt von einem Nullbyte und von einer durch
        zwei Nullbytes abgeschlossenen Liste von Parametern. Durch bergaben
        von "ARGV=NULL..." usw. kann man auch das erweiterte ARGV-Verfahren
        verwenden, das die bergabe von leeren Parametern ermglicht.
        Pexec lscht ein evntl. vorhandenes ARGV und trgt das neue ins
        Environment ein. Die Kommandozeile besteht nur aus $7f als Indikator,
        da die Parameter im Environment liegen.
        Das Verfahren ist geeignet, wenn das aufgerufene Programm mit
        Sicherheit das ARGV-Verfahren beherrscht.
     3. Ist das Lngenbyte $ff, erwartet MagiC direkt dahinter eine durch
        Leerstellen getrennte und durch ein Nullbyte abgeschlossene Liste von
        Parametern (wie i.a. als Kommandozeile bergeben wird).
        Pexec lscht ein evntl. vorhandenes ARGV, erstellt aus der
        Kommandozeile eine Argumentliste und trgt diese als ARGV ins
        Environment ein. Als argv[0] wird der Programmdatei-Pfad genommen,
        der Pexec bergeben wurde. Ist dieser Pfad ungltig, gibt es Mll,
        deshalb sollte man auch bei Modus 5 (Basepage erstellen) einen
        sinnvollen Programmnamen bergeben. Bei Modus 7 heit argv[0] dann
        einfach "NONAME", weil hier kein Name bergeben wird.
        Die Kommandozeile hat als Lngenbyte $7f als Indikator fr das
        Vorhandensein von ARGV. Ist die Lnge der Kommandozeile < 127, wird
        diese auerdem in die Basepage kopiert, ansonsten besteht die
        Kommandozeile nur aus $7f.
        Das Verfahren ist geeignet, wenn das aufrufende Programm nicht sicher
        ist, da das aufgerufene Programm ARGV versteht.

  Warum lege ich nicht grundstzlich immer ARGV an ? Klar! Weil es nmlich
  garantiert Programme gibt, die ber ARGV stolpern. Nehmen wir nmlich mal
  an, ein Parameter laute "VAR=wert", dann wird jedes Programm
  dies fr eine Environment-Variable halten. Werden neue Variablen angehngt,
  etwa durch einen Kommandoprozessor, sind diese sofort verloren, wenn sie
  hinter "ARGV=" liegen.
- ARGV- Verfahren gendert. Die Zeichenkette "ARGV=blubber" mu jetzt
  bergeben werden, damit ist die bergabe von leeren Parametern mglich.

- shel_write wurde folgendermaen erweitert:

 1. Wird als "tail" eine Zeichenkette bergeben, die mit $ff beginnt und mit
    '\0' abgeschlossen ist, wird die tatschliche Lnge der Kommandozeile vom
    AES bestimmt und in ganzer Lnge ans DOS weitergereicht. Das DOS
    konstruiert hieraus einen ARGV-Parameter im Environment (s.o.).
    Ist die Kommandozeile krzer als 127 Bytes, wird sie ber Basepage und
    shel_read bergeben, ansonsten besteht sie nur aus dem Byte $7f.
 2. Wird als tail eine Zeichenkette bergeben, die mit $fe beginnt, erwartet
    das AES dahinter die Zeichenkette "ARGV=irgendwas" und eine durch '\0'
    getrennte und durch "\0\0" abgeschlossene Liste von Parametern.
    Diese wird vollstndig dem DOS bergeben, das daraus einen ARGV-Parameter
    konstruiert (s.o.).
    Ist die Kommandozeile krzer als 127 Bytes, wird sie ber Basepage und
    shel_read bergeben, wobei die Nullbytes durch Leerstellen ersetzt
    werden, ansonsten besteht sie nur aus dem Byte $7f.
 3. Nach MultiTOS-Konvention knnen jetzt erweiterte Parameter bergeben
    werden. Werden im Parameter "doex" Bits im Hibyte gesetzt, wird statt
    "command" ein Zeiger auf eine Tabelle von Langworten bergeben:

     tab[0]         ist ein Zeiger auf "command"
     tab[1]         Wert fr Psetlimit, wird seit 25.9.95 untersttzt
     tab[2]         Wert fr Prenice, wird z.Zt. ignoriert
     tab[3]         Zeiger auf Default-Verzeichnis, z.Zt. ignoriert
     tab[4]         Zeiger auf das Environment

    Das Default-Verzeichnis wird unter MagiC viel einfacher gesetzt, das neue
    Programm erbt nmlich alle Pfade auf allen Laufwerken vom aufrufenden
    Programm. Wichtig ist hier hauptschlich die Mglichkeit, ein Environment
    vorzugeben.

- wind_set(WF_UNICONIFY) gendert, anstelle der gespeicherten werden nun die
  bergebenen Parameter bercksichtigt.

- shel_find korrigiert fr PATH-Variable ohne abschlieenden '\'.

- MGFORMAT benutzt nicht mehr Protobt, um den Bootsektor zu erstellen.
  Bei 720k-Disketten wird jetzt ein MSDOS-Format mit 730.112 freien Bytes
  erzeugt.

- wind_get(WF_BOTTOM) korrigiert.

- wind_get(WF_TOP) den Hack fr Tempus entfernt.
  Tempus KANN JETZT NICHT MEHR LAUFEN!!!!!!!! Bei Problemen bitte an Wilfried
  wenden.

- appl_getinfo() liefert zu shel_write() die Information:
  Nur Modi 0 und 1 vorhanden.
  Tatschlich sind vorhanden: 0/1/4/5/9/10

- wind_set() mit ungltigem Modus liefert 0.

- wind_get(WF_KIND) untersttzt.

- Das Programm XMEN_MGR (am besten in den APPS-Ordner legen) installiert
  folgende Funktionen:

     menu_popup()
     menu_attach()
     menu_istart()
     menu_settings()

  appl_getinfo() liefert bei den entsprechenden Unterfunktionen eine "1",
  wenn XMEN_MGR installiert ist.
  Intelligenterweise hat menu_popup() dieselbe AES-Funktionsnummer wie
  menu_unregister(), und menu_attach() hat dieselbe wie menu_click(). Die
  Funktionen werden durch die Art und Anzahl der bergebenen Parameter
  unterschieden.

- appl_find("?AGI") => 0 statt bisher (-1)

- Auf besonderen Wunsch zweier einzelner Herrn, die immer paarweise genannt
  werden, wird der Kreuzchenbutton im 2D- Modus nicht mehr im Modus XOR,
  sondern REPLACE gezeichnet.
  Es ist daher darauf zu achten, da im 2D-Modus der Hintergrund wei ist,
  sonst gibt es Grtze.

- MAGXDESK kann Fenster ikonisieren. "Iconify all" wird bisher allerdings
  geflissentlich ignoriert.
  MAGXDESK 3 untersttzt Iconify voll.

- Ich habe versuchsweise die AES-Versionsnummer auf 4.0 gesetzt. Leider zeigt
  GEMVIEW immer noch keinen Iconifier. Ein neues Sorgenkind ist XCONTROL, das
  zwar angeblich AP_TERM versteht, aber die Nachricht geflissentlich
  ignoriert.
  SHUTDOWN meldet daher eine Zeitberschreitung.

- ikonifizierte Fenster haben keinen Backdrop-Button mehr. Die Gre wurde
  MultiTOS angeglichen und betrgt 72 Pixel brutto Hhe und Breite.

- Ist die Auflsung ungeeignet, um Fenster mit 3D-Rahmen darzustellen, wird
  die Breite des 3D-Rahmens verkleinert. Vorher waren smtliche 3D-Buttons
  leer.
  Es wird dringend empfohlen, in TT low auf 2D-Darstellung zu schalten.

- Bei wind_set(WF_ICONIFY) kann man fr das GRECT {-1,-1,-1,-1} bergeben. In
  diesem Fall wird die Icon-Position berechnet. Das funktioniert auch in der
  Beta-Version von MultiTOS, aber dort mu man das Fenster vorher schlieen.

- menu_register wird nicht ausgefhrt und liefert -1, wenn es nicht von einem
  ACC ausgefhrt wurde.

- Farbicons untersttzt.

- G_F(BOX)TEXT mit 3D-Flags "Indicator" oder "Background" fr kleine Schrift
  implementiert. Bisher war nur groe Schrift mglich, wer benutzt auch
  Eingabefelder mit kleiner Schrift ?
  Wenn man kein Eingabefeld machen will, sollte man auf keinen Fall ein
  3D-Flag setzen, wenn das Aussehen dem eines 2D-Objekts mit Modus
  "transparent" entsprechen soll.
  D.h.: Hnde weg von den 3D-Flags, es sei denn, man wei, was man tut.

- Internen Menmanager erweitert. Das erweiterte MN_SELECTED Format wird
  jetzt auch vom internen Menmanager untersttzt (appl_getinfo entsprechend
  abgendert). Man erhlt in buf[5,6] den Menbaum (OBJECT *), d.h. den an
  menu_bar() bergebenen Baum. Der Fall, da ein anderer Baum angewhlt wurde,
  wie in MultiTOS das linke Men, tritt in MagiC bisher nicht auf. In buf[7]
  erhlt man den parent des angewhlten Meneintrags, d.h. die Objektnummer
  der "heruntergefallenen" Box, die den angewhlten Meneintrag enthlt.

- Knnen Farbicons aufgrund eines nicht untersttzten Bildschirmspeicher-
  Formats nicht angezeigt werden, werden Monochrom-Icons angezeigt.
  Will man keinen Text, mu man
  - entweder Textbreite auf 0 setzen (besser!)
  - oder den Text dorthin positionieren, wo er vom Icon bergebgelt wird.

- wind_set(WF_DCOLOR) ist folgendermaen erweitert:

  W_FULLER:    ndert wegen Kompatibilitt zu alten Versionen den Iconifier
               und den Backdrop-Button mit.
  W_SMALLER:   Wie in AES 4.1 kann damit der Iconifier modifiziert werden.
               Andere Objekte werden nicht mit verndert. Man mu also erst
               den FULLER und dann den ICONIFIER ndern.
  W_BOTTOMER:  Fr den Backdrop-Button. Geht nur in MagiC, nicht in MultiTOS.
               Auch hier wird kein anderes Objekt beeinflut.

- wind_set(WF_ICONIFY) legt bei g = {-1,-1,-1,-1} das Fenster an die nchste
  freie Position fr ikonifizierte Fenster.
- wind_open() legt bei g = {-1,-1,-1,-1} das Fenster an die nchste
  freie Position fr ikonifizierte Fenster.


ERWEITERUNGEN ab der ersten Release-Version:
============================================

ab 15.4.95:

- Erweiterte Version von appl_write() eingefhrt. Ist die ap_id der Ziel-
  Applikation -2, zeigt "msgbuf" auf folgende Struktur (->MAGX.H):

     typedef struct {
          int  dst_apid;
          int  unique_flg;
          void *attached_mem;
          int  *msgbuf;
          } XAESMSG;

  Dabei enthalten <dst_apid> und <msgbuf> die blichen Nachrichten-
  Informationen.
  <unique_flg> gibt an, ob gleichartige Nachrichten (d.h. solche mit gleichem
  Nachrichtentyp msgbuf[0]) von der neuen Nachricht berschrieben werden
  sollen.
  Wenn <attached_mem> != NULL ist, wird damit ein per Malloc() allozierter
  Speicherblock angegeben, der die erweiterten Nachrichten-Informationen
  enthlt. Die Lnge dieses Blocks ist beliebig und fr das System
  uninteressant, sie knnte z.B. als erstes Langwort des Blocks oder in
  msgbuf[4,5] bergeben werden. Das System weist den Speicherblock der
  Zielapplikation zu und bermittelt dessen Adresse in msgbuf[6,7]. Die
  aufrufende Applikation mu davon ausgehen, da msgbuf[6,7] nach dem Aufruf
  von appl_write() zerstrt sind. Das System behlt sich vor, den Inhalt des
  Speicherblocks umzukopieren und den bergebenen Block freizugeben. Der
  Aufrufer darf nach dem appl_write() NICHT MEHR AUF DEN BLOCK ZUGREIFEN UND
  IHN AUF GAR KEINEN FALL FREIGEBEN !!!

  Gibt appl_write() einen Fehlercode zurck, ist der Block nicht bergeben
  worden und gehrt nach wie vor der aufrufenden Applikation. Ein Fehler
  tritt dann auf, wenn:

     a) die Zielapplikation ungltig (nicht existent oder eingefroren) ist
     b) der Nachrichtenpuffer der Zielapplikation voll ist
     c) die Zielapplikation kein Proze ist (z.B. der SCRENMGR) und ein
        "attached memory block" angegeben worden ist.

- Versuchsweise: Backdrop-Button schaltet ggf. die Menleiste um. Es knnte
  noch Probleme geben, falls jemand die Backdrop-Meldung selbst bearbeitet,
  dann wird nmlich die Menleiste nicht umgeschaltet. Aber wer macht das ?
- Inaktive Mens lassen sich zeichnen, indem das Flag RBUTTON des Objekts #0
  gesetzt wird (fr Tear-Off-Mens).
- AES: objc_draw() an MultiTOS angepat. Nach einer Reihe von Versuchen hat
  sich jetzt folgendes ergeben:

 1. G_BOXTEXT DECKEND 3D wird in G_BOXTEXT TRANSPARENT 3D gewandelt
 2. G_TEXT DECKEND 3D wird ebenfalls in G_BOXTEXT TRANSPARENT 3D gewandelt

  Schwachsinnig ist, da im Fall 2. das gesamte Objekt mit einer grauen Box
  unterlegt wird, nicht nur die Zeichenkette. Diese Umwandlungen sind
  weiterhin eigentlich vllig berflssig, weil man auch gleich G_BOXTEXT
  nehmen knnte. Tut man aber nicht, weshalb einige Objekte unter MagiC nicht
  wie gewnscht aussahen.
- AES: objc_draw() zeichnet die selektierten 3D-Objekte, die nicht dunkelgrau
  werden und die nicht "reingedrckt" werden, wie im 2D-Fall mit einer
  schwarzen XOR-Box. Das macht MultiTOS auch so (wenn ich das nicht sage,
  gibt es Protest). Betroffen: G_TEXT, G_IBOX und der MagiC- Gruppenrahmen.
- 3D/FTEXT/DECKEND wird zwar mit einer Box hinterlegt (wie BOXTEXT), aber
  jetzt wie in MultiTOS ohne Rahmen gezeichnet.
- Neue Regel:

     FL3DBAK:       Objekt immer mit XOR-Maske selektieren
                    und objc_change immer durch XOR-Maske
     andere 3D:     Objekt nie mit XOR-Maske
                    und objc_change zeichnet das Objekt immer neu

- Neue Regel:
  Selektieren verwandelt die Boxfarbe nur noch dann von hellgrau in
  dunkelgrau, wenn FL3DIND gesetzt ist.
- In MultiTOS werden Objekte mit den Flags INDICATOR durch grauen Hinter-
  grund und eine nderung der Textfarbe selektiert.
  Das funktioniert NICHT bei G_BUTTON, G_TITLE und G_STRING !!!!
  Die nderung der Textfarbe berechnet sich in MultiTOS folgendermaen:

     0    <=>  1
     2    <=>  13
     3    <=>  15
     4    <=>  14
     5    <=>  10
     6    <=>  12
     7    <=>  11
     8    <=>  9

  Eine Systematik kann ich darin nicht erkennen, auer da hellgrau und
  dunkelgrau und schwarz und wei vertauscht werden.
  MagiC hat daher folgende Umsetzung:

     0    <=>  1
     8    <=>  9
     sonst: Bit 3 toggeln, d.h. Farbe abdunkeln/aufhellen

  Eine IBOX mit Typ Indicator und ohne Rand ist dann allerdings nicht mehr
  als selektiert zu erkennen, weil sie weder Text noch Box enthlt.
  Im Gegensatz zu MultiTOS funktioniert das Umschalten der Textfarben auch
  bei G_BUTTON, G_TITLE und G_STRING.
- AES: Bei shel_write() den Modus mit doex=7 eingebaut (SHW_BROADCAST).
  Unglaublich wichtig, besonders deshalb, weil sowieso jede Applikation einen
  Workaround mittels appl_search() besitzt.
- AES: shel_write() mit Modus 8 fhrt zu Fehlercode 0 statt zum Start eines
  Programms.

