@(#) bugs.txt, Fehler in GFABASIC 3.x - Uwe Ohse, 15.4.93


               Liste des Grauens - willkommen im Land der Bugs!


     Dieser Text fhrt die mir bekannten fehlerhaften oder prinzipiell nicht
     zukunftssicheren Befehle im GFABASIC 3.6. Er ist nicht als vollstndig zu
     betrachten! Die Anzahl mir unbekannter Fehler im GFABASIC 3.6 ist mg-
     licherweise sehr hoch.

1. Die GFA-Fensterverwaltung.
   Die einfache Fensterverwaltung mit OPENW, CLOSEW usw. ist in frheren
   Versionen fehlerhaft gewesen. Wie es heute aussieht, wei ich nicht, da ich
   schon lange auf direkte AES-Aufrufe umgestiegen bin.
   Prinzipiell jedoch ist ein gravierender Mangel nicht beseitigt worden: Es
   knnen mit den GFA-Fensterbefehlen nur bis zu vier Fenster verwaltet werden,
   was in Zukunft ein ernsthafter Mangel werden drfte.
   Auch ist die GFA-Fensterverwaltung recht unflexibel.
   Die GFA-Fensterverwaltung kann brigens mit groen Fensterhandles (WINX,
   MultiTOS) umgehen.

2. Die Dateifunktionen unter Multitasking
   Tritt bei OPEN ein Fehler auf, z.B. weil gerade ein anderer Prozess die
   Datei gesperrt hat, so meldet GFABASIC sofort einen Fehler. Damit sind
   die gesamten I/O-Operationen unter MTOS/MiNT ziemlich unsicher, und es
   ist nicht mglich, z.B. zwei Bugsicprogramme auf denselben Datenbestand
   loszulassen.
   Fr dieses Problem gibt es bisher keine Lsung auer der Verwendung des
   GFA-nach-C-Konverters (gut, aber fr den Hobbygebrauch etwas teuer) oder
   einer selbstgeschriebenen Ein/Ausgabelibrary auf GEMDOS()-Basis. Letztere
   verlangsamt das Programm recht stark, falls sie nicht in Assembler
   realisiert wird.

3. Bekannte Bugs, die nicht auf einen speziellen Befehl beschrnkt sind
   3.1 Allgemein
   - GFABASIC verlt sich darauf, da VDI-Aufrufe den Inhalt von
     CONTROL(6) (das Handle der Workstation) nicht verndern. Dies ist eine
     undokumentierte Eigenschaft einiger VDI-Versionen, die andere Versionen
     nicht teilen. Mit anderen Worten: Mglicherweise steht nach dem
     Aufruf einer VDI-Funktion etwas ganz anderes in Control(6) als vorher.
     Und beim nchsten Aufruf stimmt das Handle nicht -> im schlimmsten
     Falle Crash!
     Abhilfe: Nach _jedem_ VDI-Aufruf CONTROL(6) setzen, z.B. mit V~H=xxx.
     (was definitiv zuviel verlangt ist, ich wei)
   - Auerdem unterscheidet sich die Syntax einiger VDI-Aufrufe (rund um
     das ffnen und Schlieen von virtuellen oder physikalischen Workstations)
     stark von der in anderen Sprachen gebruchlichen.
   3.2 Compiler
   - Bitte "kommentieren" Sie mal einen Block oder eine Zeile in ihrem
     Programm mit "IF FALSE" und "ENDIF" aus und compilieren sie es dann.
     In vielen Fllen strzt der Compiler whrend der Arbeit bombenwerfend
     ab.
   - Konstruktionen wie "IF exist(datei$)" knnen unter Umstnden im
     compilierten Programm falsch ausgewertet werden. Verwenden Sie besser
     "IF exist(datei$)<>FALSE".
     Dieser unangenehme Effekt ist mehr oder weniger unbekannt und nicht
     beliebig reproduzierbar. Eines meiner Programme findet aber erst seit
     der nderung der EXIST-Bedingungen seine smtlichen Dateien wieder.
     Auch ein beim Mailboxprogramm Q_MAIL aufgetretener Effekt ist nur so
     erklrbar gewesen. Eine Programmteil der Form
     IF EXIST(zugriffsliste$)
       [lesen der Liste]
     ELSE
       [neuanlegen der Liste]
     ENDIF
     fhrte ab und zu (wenn auch selten) dazu, da eine existierende Liste
     gegen die Defaultliste "ersetzt wurde".
     hnliches fr alle anderen "Vergleiche irgendwas" Bedingungen, also
     auch fr WHILE und UNTIL. Die Probleme lassen sich nicht vernnftig
     reproduzieren (und schon gar nichts in ein paar Zeilen), sind aber
     mittlerweile von gengend anderen Leuten besttigt worden.
   - in einem relativ groen Programm (undokumentiert 250 K) ist es
     vorgekommen, da der Compiler Funktionen nicht gefunden hat, wenn sie
     hinter den Funktionen standen, aus denen sie aufgerufen wurden. Abhilfe
     brachte es, die in der Hierarchie niedrigeren Funktionen vor den anderen
     zu plazieren.
   - TT? fhrt auf Gerten ohne Cookiejar zum Absturz, da hier einfach
     unterstellt wird, da eine FPU vorhanden ist.
   3.3 Interpreter
   - Der Interpreter greift in starkem Mae auf LineA zu. Schaltet man z.B.
     unter NVDI das LineA ab, funktioniert der Interpreter nicht mehr.
   - Er verbiegt auch Systemvektoren ohne die dafr vorgesehene Betriebs-
     systemfunktion setexc zu verwenden. Damit ist er unter MiNT und MultiTOS
     nicht mehr lauffhig. (Es sei denn, man patcht ihn. Siehe unten).
   3.4 Linker
   - Das Anlegen von Symboltabellen sollte man bei lngeren Programmen
     unterlassen. Der Linker kann abstrzen.
   3.5 Speicherverwaltung in Interpreter und Compiler
   - RESERVE arbeitet unter TOS 3.06 und MiNT nur unzureichend. Es kann den
     einmal freigegebenen Speicher nicht wieder vergrern. Dies war GFA
     vor der Auslieferung von Bugsic 3.6 bekannt und ist nicht behoben
     worden. Man denke darber, wie man will.
     Die einzige Abhilfe ist, auf eine dynamische Speicherverwaltung mit
     Malloc umzusteigen. Leider untersttzt GFABASIC dies in keiner Weise.
     Unter MultiTOS wird die damit erzwungene starre Speicherverwaltung
     rgerlich werden.
   - Die Speicherverwaltung ist nicht nur unflexibel, sondern auch
     fehlerhaft. Mit freundlicher Erlaubnis von Christoph Conrad @ AC3:

       Probieren Sie mal folgendes (danach neu booten):
       ' Compilerversion mit $m statt RESERVE
       RESERVE 1000
       $m 4711
       ' RESERVE damit's etwas schneller abstrzt, aber eigentlich unntig.
       ' Die (**) Zeilen braucht man beim Interpreter, damit nach dem RESERVE
       ' auch wirklich (FRE() MOD 16) == 0 gilt
       ' minus 4: wegen Backtrailer bei rest16$ beim Compiler falls $m XXXX
       ' mit (XXXX MOD 16)<>0
       rest16%=(FRE(0) MOD 16)-4   ! **
       IF rest16%<0                ! **
         ADD rest16%,16            ! **
       ENDIF                       ! **
       rest16$=STRING$(rest16%,0)  ! **
       ' (FRE() MOD 16) == 0 jetzt erfllt
       str$="AHAH"
       DO
         @crash(str$)
       LOOP
       PROCEDURE crash(str$)
         str$="OHOH"
       RETURN

       ' (Der Bug ist nicht auf jedem Rechner zu jeder Zeit reproduzierbar,
       '  z.B. tritt er auf meinem TT nicht auf, auf dem STE aber schon. Uwe)
   - Ein weiterer Bug in der internen Speicherverwaltung tritt unter noch
     selteneren Umstnden auf, es ist mir bisher nicht gelungen, ihn in
     kleineren Programmen zu reproduzieren. Er tritt im Zusammenhang mit der
     bergabe lokaler Variablen als Parameter an eine Prozedur oder
     Funktionen besonders gerne auf, wenn man dabei Call-by-Reference- und
     Call-by-Value-Parameter mischt und nach Mglichkeit auch Felder
     bergibt.
     Die Folgen reichen von kompletten Systemhngern bis zu einigermaen
     zivilisierten, aber vollkommen falschen Fehlermeldungen des Interpre-
     ters.
     Abhilfe: CbV- und CbR-Parameter nach Mglichkeit nicht mischen, Felder
     nach Mglichkeit nur eine Prozedur tief hinunterreichen (?).

     Nachtrag:
      PROCEDURE test
        LOCAL a&
        '
        adr%=V:a&            !Adresse von a& vorher
        PRINT adr%
        '
        a&=@zahl             !Funktion aufrufen
        '
        PRINT a&             !a& => falsch <= ERROR hier!
        '
        PRINT V:a&           !Adresse von a& nachher = verschoben!!
        PRINT WORD(adr%)     !An der alten Adresse steht es
      RETURN
      FUNCTION zahl
        DIM a$(10)           !Hier verschiebt sich die Adresse von a& !
        RETURN 10
      ENDFUNC
      Ausgabe beispielsweise:
      1000000 (beliebige, noch korrekte Adresse)
      42      (irgendeine Zahl)
      2000000 (beliebige Adresse ungleich der obigen)
      10

      In anderen Fllen treten solche Probleme in der Funktion "zahl" auf,
      wenn dort z.B. die Variable a benutzt wird.

     Konsequenz daraus: Vorsicht mit lokal deklarierten Feldern! (u.a.)
Gruppe: GFABASIC
ID  : A1724@PB2
Kommentar zu A9378@OS
Wg. : Bugs: Teil 2 (Befehle)
Von : Uwe Ohse @ PB2 (Fr, 16.04.93 10:15)
 
4. Diverse fehlerhafte oder unbrauchbare Befehle:
Im folgenden bedeutet LA LINE-A!
ACHAR:       ruft LA (Textblt) auf. Abhilfe: TEXT
ACLIP:       ruft LA auf. Abhilfe: CLIP.
AFTER:       hngt von $I+ ab und sollte deshalb vermieden werden. Abhilfe
             bieten die AES-Events (EVNT_TIMER, EVNT_MULTI) oder zur Not auch
             ON MENU.
ALINE:       ruft LA (Arbitrary line) auf. Abhilfe: LINE
APOLY:       ruft LA (Filled polygon) auf. Abhilfe. POLYLINE
ARECT:       ruft LA (Filled rectangle) auf. Abhilfe: PBOX
ATEXT:       ruft LA (TextBlt) auf. Abhilfe: TEXT
BITBLT:      Die Varianten
                   BITBLT adresse%
             und
                   BITBLT ein_feld%()
             benutzen LA (Bitblt) und sind deshalb unsauber. Als Abhilfe
             bietet sich die Benutzung von
                   BITBLT q%(),z%(),d%()
             an. Hier wird das VDI benutzt.
             Anmerkung: Leider ist dies der einzige saubere
             Rasterkopierbefehl, den Bugsic bietet.
CALL:        Funktioniert im Interpreter nicht. Abhilfe bietet folgender
             Patch von Christoph Conrad: (3.6 D TT - Groesse 104770)
             Byte:
               Dateioffset $34AC. Dort sollten die Bytes $48 $ E7 $ 00 $ 0A
               zu finden sein.
               Das $0A in $0E umpatchen, das wars.
CRSCOL:      greift auf LA-Variablen zu. Abhilfe: Keine. Es sollte aber nicht
             schwierig sein, sich die Cursorposition zu merken!
CRSLIN:      greift auf LA-Variablen zu. Siehe CRSCOL.
DEFMOUSE:    greift auf LA zu, um die Mausform sofort zu ndern. Schaltet man
             unter NVDI das LA ab, wird die Mausform erst bei der nchsten
             Mausbewegung gendert. Abhilfe: GRAF_MOUSE() (ist sowieso
             sauberer).
EVERY:       hngt von $I+ ab und sollte vermieden werden. Abhilfe: Siehe
             AFTER.
EXEC:        Modus 4 funktioniert offenbar nur zufllig.
FILESELECT:  schaltet die Maus mit LA ab. Abhilfe: FSEL_(EX)INPUT benutzen.
GET:         in einen String passen nur 32K, und das reicht schon unter
             Overscan u.U. nicht mehr aus. Man sollte sich auch nie
             darauf verlassen, da 100*100 Pixel in den String passen: Es
             knnte z.B. eine TrueColor-Karte laufen. Weiterhin benutzt
             GET die LineA-Variable M_HID_CT und Logbase (XBios(3)).
             Abhilfe: VDI-BITBLT.
HIDEM:       ruft LA (Hide mouse) auf. Abhilfe: GRAF_MOUSE()
HLINE:       ruft LA (Horizontal line) auf. Abhilfe: LINE.
INPUT:       greift u.U. auf LA-Variablen zu. Leider hilft es auch nicht, CON:
             zum Lesen zu ffnen und INPUT # zu benutzen: So schlau ist Bugsic
             leider. Abhilfe: In GEM-Programmen Dialoge benutzen oder gleich in
             Fenstern arbeiten, in TOS-Programmen GEMDOS(10,...) (=Cconrs)
             benutzen.
             Nachtrag: Es hilft auch, mit INPUT # von "STD:" zu lesen, diese
             Variante benutzt kein LA und ermglicht auch eine I/O-Umlenkung.
             In GEM-Programme passt sie allerdings nicht (dasselbe gilt
             allerdings auch fr INPUT).
INP?:        benutzt LA. Abhilfe: BIOS(1,device)
INSTR:       Die Varianten INSTR("xyz","xyz",2) und INSTR(2,"xyz","xyz")
             liefern 1 zurck, obwohl "xyz" in "yz" nicht vorhanden ist.
KEYDEF:      hngt von $I+ ab und ist deshalb zu meiden. Abhilfe: in
             GEM-Programmen simpel, bei Eintreffen eines Tastaturereignisses
             statt der Funktionstaste die entsprechenden Strings verarbeiten.
             In TOS-Programmen wird es schwieriger, ich persnlich glaube auch
             nicht, da die benutzung der Funktionstasten in reinen
             TOS-Programmen schn ist und gebe hierzu konsequenterweise
             keinen Tip.
L~A:         die Basisadresse der LA-variablen persnlich. Sozusagen der
             Teufel selbst. Fr die allermeisten Zwecke braucht man sowieso
             keinen Zugriff darauf. Wenn doch, tja, dann mu man halt.
MOUSE,
MOUSEX,
MOUSEY,
MOUSEK:      greifen auf LA-Variablen zu. Abhilfe bietet mal wieder das AES,
             wenn man auf Mausereignisse abfragt (EVENT_MULTI, EVENT_BUTTON,
             EVENT_MOUSE) oder (einfacher) GRAF_MKSTATE verwendet.
POS():       benutzt zwar kein LA, ist aber trotzdem unbrauchbar, da es ganz
             einfach "Anzahl der seit dem letzten Carriage Return ausgegebenen
             Zeichen modulo 256" zurckzugibt und nicht die tatschliche
             Cursorposition!
PRINT:       gibt normalerweise ber das BIOS aus. Arbeitet man aber mit
             PRINT#x, wenn x mit OPEN "O",x,"STD:" geffnet ist, wird ber
             die Standardausgabe ausgegeben. Diese Variante ist fr Tools,
             bei denen eine Ein/Ausgabeumlenkung denkbar ist, vorzuziehen!
             PRINT auf Bildschirm oder STD: Hat in GEM-Programmen zu nichts
             zu suchen!
PSET:        ruft LA (Put pixel) auf. Abhilfe: PLOT
PTST:        ruft LA (Get pixel) auf. Abhilfe: POINT()
PUT:         Da GET nicht ausreichend verllich arbeitet, ist auch PUT nicht
             zu gebrauchen.
RC_COPY:     ruft LA (BltBlt) auf. Abhilfe: Siehe BITBLT.
RESERVE:     ist fehlerhaft. Unter TOS 3.06 und MiNT kann RESERVE den Speicher
             nicht wieder vergrern. Abhilfe: Mglichst nur einen RESERVE
             benutzen, nmlich den zum Verkleinern des Arbeitsspeichers, oder
             diese Option zumindest unter MiNT/TOS3.06 anbieten, oder auf
             dynamische Speicherverwaltung mittels MALLOC umsteigen.
RESUME:      hngt von $I+ ab und sollte deshalb vermieden werden. Abhilfe:
             RESUME label. Auch hier heit es aufpassen, da bei RESUME label
             der GFA-interne Stack inkonsistent wird. Ein Rcksprung (RETURN)
             aus einem Unterprogramm ist deshalb nicht sicher mglich, der
             RESUME label sollte also in eine Prozedur fhren, die nicht wieder
             verlassen werden mu, z.B. das Hauptprogramm.
             (Ich erbitte mir Tips hierzu!)
RESUME NEXT: hngt von $I+ ab und sollte deshalb vermieden werden. Abhilfe:
             Siehe RESUME.
SETCOLOR:    benutzt das XBIOS. Getreu der Regel, da man Betriebssystemaufrufe
             unterschiedlicher Ebenen nicht mischt, sollte man stattdessen
             VSETCOLOR verwenden, wenn man mit den VDI-Aufrufen zeichnet.
SETMOUSE:    ndert LA-Variablen.  Abhilfe: APPL_TPLAY, leider deutlich
             komplizierter.
SGET:        in einen String passen nur 32K, und das reicht schon unter
             Overscan ganz sicher nicht aus. Abhilfe: VDI-BITBLT.
SPUT:        Wenn SGET nicht zu gebrauchen ist, fllt auch SPUT aus.
SHOWM:       ruft LA (Show mouse) auf. Abhilfe: GRAF_MOUSE
SPRITE:      ruft LA (Draw sprite, Undraw sprite) auf. Abhilfe: viel
             Mehrarbeit. Im allgemeinen bentigt man Sprites sowieso nur in
             Spielen, und fr die gelten andere Regeln.
STE?:        Arbeitet grob fehlerhaft: Ist kein Cookiejar angelegt, so ange-
             nommen, das Programm liefe auf einem ST, sonst wird der Cookie
             _SND abgefragt, ob das Bit fr Stero/DMA-Sound gesetzt ist.
             Somit macht Bugsic von der Soundhardware abhngig, auf welcher
             Maschine das Programm luft. Was passiert auf dem Falcon? Mg-
             licherweise alles schlechte der Welt.
             Abhilfe: Den _MCH-Cookie selbst abfragen.
STICK:       sollte vermieden werden. Unter MultiTOS drfte es sehr unschn
             sein, wenn eine Applikationen den Mausport als Joystick schaltet.
STICK():     Benutzt KbdvBase = XBios(34) und Bconout(Ikbdsys) = Bios(3,4,...),
             und schaltet die Maus auf die Hardwarenaheste Weise ab. Damit
             sollte die Funktion unter MultiTOS nicht mehr genutzt werden.
STRIG():     Siehe STICK().
TT?:         arbeitet fehlerhaft und fhrt unter bestimmten Umstnden zum
             Absturz des Programms (fehlender Cookiejar, bzw. fehlender
             Cookie). btw: Wie arbeitet TT? eigentlich genau? _FPU, _CPU?
             Auerdem berschreibt TT? Teile des Programmcodes, ein
             Verfahren, das nun wirklich schmutzig ist. Selbstmodifizierende
             Programme sind MEGA-OUT!
             Verschiedentlich wurde auch berichtet, da bei Benutzung von TT?
             grere Teile des Programmes berschrieben wurden. Nach kurzem
             Debuggen des entsprechenden Routine kann ich das weder
             ausschlieen noch erhrten.
VDIBASE:     Die Funktion liefert m.W. seit TOS 1.02 keine vernnftigen Werte
             zurck. Abhilfen: Work_out-Feld, vqt_extend().
XBIOS():     XBIOS(2 ... 5) sollten nicht mehr genutzt werden. Die Abfrage und
             das Setzen der Bildschirmadresse kann auf diversen Graphikkarten
             nicht funktionieren, XBIOS(4) ist nur fr die Standardauflsungen
             definiert.
_C,
_X,
_Y:          Liefern im compilierten Programm 0 zurck. Abhilfe: In
             GEM-Programmen entweder die Werte aus dem WORT_OUT-Feld
             benutzen oder, besser noch, den Bereich des Hintergrundfensters
             mit WIND_GET erfragen. Die Anzahl der Farbebenen kann man z.B.
             dem AES-Globalfeld entnehmen.
             brigens ist dieser Fehler (wie auch diverse andere) GFA seit
             ber einem Jahr bekannt.

Hinweis a): Mir ist klar, da STICK und STRIG fr Spiele durchaus noch eine
   Existenzberechtigung haben. Unter GEM jedoch sollte man darauf verzichten!
Hinweis b): Auch wenn man keine LA-Befehle verwendet, rufen sowohl der
   Interpreter als auch der Compiler LA auf. Abhilfe schafft nur ein Patch,
   siehe dazu unter Punkt 7.
Gruppe: GFABASIC
ID  : A1725@PB2
Kommentar zu A9378@OS
Wg. : Bugs: Teil 3
Von : Uwe Ohse @ PB2 (Fr, 16.04.93 10:17)
 
5. Compileroptionen:
- $B+  "Fngt Bombenfehler ab"
  Hierfr werden diverse Vektoren verbogen. Die Anwendung dieser Option in
  Accessoires verbietet sich also von selbst ("Accessoires should not steal
  vectors"), sonst hagelt es Abstrze beim Auflsungswechsel.
  Es ist eigentlich berflssig zu bemerken, da selbstverstndlich weder XBRA
  noch SETEXC verwenden wird. Also darf diese Option unter MiNT nicht verwendet
  werden, oder der Absturz unter MiNT (und MultiTOS) ist nur eine Frage von
  Millisekunden.
- $I+ "Interruptroutinen einschalten"
  verbiegt Kbdvbase()->ikbdsys. Verbietet sich in Accessoires also ebenfalls.
  Auch hier wird natrlich weder XBRA noch setexc benutzt, und unter MiNT
  lauffhig sind Programme, die mit dieser Option compiliert wurden, auch
  nicht. Diese Option sollte man also ebenfalls besser nicht setzen.
  Aber: Das Setzen von $I- fhrt zu einigen Nebenwirkungen:
  -- Every und After knnen nicht mehr benutzt werden. Im Ernstfall kann man
     sie aber ber EVNT_TIMER() nachbilden.
  -- CTRL/ALT/SHIFT funktioniert nicht mehr (kein Verlust, ist unter MiNT
     sowieso nicht zu gebrauchen)
  -- RESUME und RESUME NEXT werden unbenutzbar. Einzig RESUME marke kann noch
     verwendet werden, lscht aber den bugsicinternen Stack und sollte nur ins
     Hauptprogramm oder eine Prozedur, die garantiert nicht per RETURN
     verlassen wird, fhren.
-- $m Speicherbedarf festlegen
  $m bestimmt den Speicherplatz, den das compilierte Programm fr Variablen
  und als Stack etc. verwenden soll. Nicht dazu zhlt der Platz fr
  Programmcode und Konstanten (Strings, Festzahlen ...). Ein $m5000
  beschrnkt also den Platz im BSS-Segment auf 5000 Bytes und sorgt auch
  dafr, da das compilierte Programm nicht noch weiteren Speicher mit Malloc
  an sich reit.
  Sehr sinnvoll ist diese Option fr Programme, die unter Multitos laufen
  sollen oder Accessoires. [Siehe auerdem RESERVE]

  Es gibt keine Mglichkeit, aus Bugsic herauszukitzeln, wieviel Speicher ein
  Programm denn bentigt. Die Mhe mu man sich leider selbst machen.
  - Man knnte im Interpreter in einer mit EVERY "kleiner Zeitabschnitt"
    aufgerufenen Funktion das Maximum gleichzeitig belegten Speichers
    bestimmen.
  - Natrlich kann man sich diesen Wert auch berechnen. In der Praxis ist das
    relativ einfach, da man sein Programm ja schlielich ordentlich
    vorbereitet hat und dabei natrlich aus der Programmdokumentation den
    Umfang aller Variablen und Strukturen sowie ihre Lebenszeit entnehmen
    kann ;-)
  Auf jeden Fall sollte man eine ausreichende Sicherheitsspanne dazurechnen,
  denn aufgrund von Speichermangel entstehende Fehler knnen sehr schwer zu
  finden sein.

  Faustformel:
   Der bentigte Arbeitsspeicher ist
      "maximaler Speicherverbrauch aller Variablen und Felder"
      plus "Stackplatz"
      plus "sonstiger Verwaltungskram"
      plus "IO-Puffer"
      plus "Sicherheitsreserve".

   Speicherverbrauch der Variablen und Felder: Kann nur abgeschtzt werden
   (mankann aber auch mal mit EVERY danach forschen).
   Stackplatz: Sollte man recht hoch ansetzen, wenn man ein tief
   verschachteltesoder gar rekursives Programm hat. In letzterem Fall sollte
   man auch noch mal genauer ber den Speicherbedarf der lokalen Variablen
   nachdenken!
   Sonstiger Verwaltungskram: Was Bugsic halt so braucht, z.B. den Platz fr
   AES- und VDI-Parameterfelder. 5K reichen aber locker.
   IO-Puffer: Fr jedes mit OPEN geffnete File braucht Bugsic 4K Speicher.
   Reserve: Ein Sicherheitsabstand von ein paar K sollte fr den Fall, da mal
   mehr Speicher bentigt wird, als man gedacht hat, immer eingeplant werden.

   Der Speicherplatz fr Resourcen wird mit "Malloc" alloziert, er braucht fr
   $m also nicht berechnet zu werden. Denke aber daran, da Resourcen bei ACC's
   frhzeitig geladen werden mssen - wie auch alle Mallocs am Programmstart
   gettigt werden mssen (erste AES-Aktion am Programmbeginn:
   WIND_UPDATE(BEG_UPDATE), RSC_LOAD(), MALLOC(), WIND_UPDATE(END_UPDATE)).

   Inlines stehen brigens im Programmtext und brauchen also nicht berechnet
   zu werden.

6. Verschiedenes:
- das INTIN-Array ist auf 120 Elemente begrenzt. Daraus ergibt sich, da
  der Befehl TEXT nur Zeichenketten mit bis zu 120 Zeichen ausgeben kann, der
  Rest wird abgeschnitten.
  hnliches gilt fr POLYLINE.
  Generell gilt dies fr alle Befehle, die viele Koordinaten an das VDI
  bergeben. Das ist kein Bug, nur eine Beschrnkung.

7. Hinweise auf weitere Quellen in rein zuflliger Reihenfolge:
- Von Karsten Isakovic (Maus Berlin) kreist ein Text mit Tips ber
  auflsungsunabhngiges Programmieren durch die Mailboxen. Unbedingt
  empfehlenswert!!!
  Er liegt zum Beispiel in der Quark Paderborn im Brett "Textfiles allgemein"
  als "PRG_TIPS.LZH".
- Von Christoph Conrad (Maus Aachen 3) stammt eine Anleitung zum Patch des
  Compilers (genauer der Lib.) und Interpreters 3.6. Damit gelinkte
  Programme rufen keine LineA mehr auf, wenn der Programmierer die
  im Abschnitt 2 angegebenen LA-aufrufenden Befehle nicht verwendet.
  Auf der Grundlage dieser Anleitung habe ich ein Programm geschrieben, das
  die Patches an Interpreter und Compiler selbst durchfhrt. Es liegt als
  Buglafix.Zoo im Brett ST-Tools in der Quark Paderborn (05251/71409,
  Gastdownload frei).
- Dann ist da noch die Professional-GEM-Serie von Tim Oren, die in vielen
  Mailboxen als PROGEM.LZH oder PRO_GEM.LZH zu finden ist. So unter anderem
  in der Quark Paderborn im Brett Textfiles Allgemein.
  Tim Oren ist einer der GEM-Programmierer, schon alleine deshalb ist der
  Text lesenswert. Er enthlt allerhand wertvolle Tips.
- Um den Interpreter unter MiNT zum Laufen zu bekommen, habe ich einen
  Patch der Kategorie "brutal und wirksam" geschrieben. Zumindest auf
  meinem TT funktioniert er, wenn auch prinzipbedingt deutlich instabiler
  als ein ungepatchter Interpreter. (Quark PB, Brett ST-TOOLS,
  Bugmntfx.zoo).
- Um den Interpreter auch auf Graphikkarten wenigstens grundstzlich zum
  Laufen zu bekommen, hat Frank Baumgart ein Tool geschrieben, das die
  diversen setscreens abfngt. Es liegt als BUGSSFIX.LZH im Brett ST-Tools in
  der Quark Paderborn.

  Falls jemand glaubt, ich mache Werbung fr die Quark PB: So ist es :-)

8. Programmierung von Accessoires
  - Wie oben schon erwhnt: Die Benutzung von $B+ und $I+ ist verboten und
    fhrt beim Auflsungswechsel zum Absturz.
  - Das Beispiel-ACC im Handbuch zu Version 3.0 auf den Seiten 52 bis 53 ist
    fehlerhaft, der Block
      CASE 22,41
        CLOSEW#1
        exit!=TRUE
    sollte ersetzt werden in
      CASE 22
        CLOSEW#1
        exit!=TRUE
      CASE 41
        exit!=TRUE
    Bei Eintreffen der Message 41 (AC_CLOSE) ist das Fenster schon
    geschlossen!
  - RESERVE ist im ACC's VERBOTEN! Ebenso mu man mit Malloc vorsichtig sein,
    da vom ACC's allozierter Speicher dem Hauptprogramm zugerechnet wird, und
    bei Beendigung der Applikation freigegeben wird.
    Wenn aber das allozieren von Speicher unbedingt notwendig ist, sollte man
    aber den WIND_UPDATE-Trick von Laurenz Prner verwenden.
  - Accessoires haben keine vollstndige Basepage. Man sollte sich auf die
    Werte darin nicht verlassen.
  - Accessoires sind keine echten GEMDOS-Prozesse. Daraus ergeben sich eine
    Reihe unerfreulicher Folgen, eine davon haben wir oben schon kennen-
    gelernt (das Speicherproblem). Weitere Probleme:
    - die DTA (benutzt fr FSFIRST/FSNEXT/EXIST) ist defaultmig dieselbe,
      die das laufende Hauptprogramm benutzt. Chaos kann die Folge sein!
      In Accessoires sollte es blich sein, vor allen DTA-Operationen die
      DTA zu setzen!
    - ACCs knnen (ohne greren Aufwand und schmutzige Tricks) keine
      Programme starten.

9. Programmierung MiNT- und MultiTOS-fester Programme
  - $I+ und $B+ sind unter MiNT tdlich
  - RESERVE kann nur einmal zum Verkleinern des Speichers benutzt werden,
    $m ist vorzuziehen
  - man darf keineswegs auf fremden Speicher zugreifen
  - Es ist nicht gesagt, da zwei direkt nacheinander geMALLOCte
    Speicherblcke im direkt aufeinander folgen
  - Fensterhandles knnen grer als nur 7 werden (MTOS)
  - Fensterelemente knnen auch im Hintergrund bedient werden.
  Programmiertip: Wird ein Pfeil oder ein Scrollbalken eines im Hintergrund
  liegenden Fensters bettigt, kann man die neuzuzeichnenden Teile des
  Fensters aus der Rechteckliste holen.

10. disclaimer: Ich, Uwe Ohse, bernehme keine Verantwortung fr Korrektheit
  oder Vollstndigkeit dieser Tips. Sollte sich durch ihre Anwendung irgendein
  Problem ergeben, bin ich, egal welches Art es ist und wie schlimm es auch
  sein mag, in keiner Weise dafr verantwortlich.

11. Dieser Text ist auf Grundlage meines heutigen Wissens entstanden. Ich bin
  gerne bereit, ihn zu korrigieren und zu ergnzen. Dazu brauche ich
  natrlich Mitarbeit!
  Die jeweils aktuellste Version dieser Mngelliste wird immmer im  Brett 120
  (Textfiles allgemein) in der Quark Paderborn liegen.

12. Alternativen:
  - Pure C (sehr schnell Compiler, sehr guter Debugger, sehr gute Onlinehilfe)
  - Lattice C (sehr gute Bibliotheken, schneller Compiler, hoch portabel,
    Weiterentwicklung fraglich)
  - GNU C (sehr gute Bibliotheken, langsamer Compiler, hoch portabel,
    kostenlos, alle Sourcen erhltlich, kein funktionierender Debugger, C++ )
  - Hnisch Modula II (schnell, Onlinehilfe, sehr gute Libs, fr Modula
           sehr portabel)
  - Pure Pascal (Turbo 6.0 kompatibel, sehr guter Debugger, Onlinehilfe,
           sehr schnell, Oberflche Gift fr MTOS)
  - GFA 4.0, sobald es fertig ist, knnte eine werden.

  Fr die C-Compiler gibt es mittlerweile eine Unzahl von Librarys, mit denen
  man fast alle Probleme erschlagen kann. U.A. gibt es die MiNTLib, die eine
  MiNT-Untersttzung liefert, ohne da die Programmierer etwas daran tun
  mte, und auch garantiert, da das Programm unter reinem TOS lauffhig ist.
  Der erzeugte Code ist bei allen oben genannten Systemen gut bis sehr gut.

