Computer Club Elmshorn Atari PD/CCE_PD.iso/mac/0700/CCE_0708.ZIP/CCE_0708.PD/GFAHILFE/L_D_GRAU.TXT

Text File | 1993-04-23 | 29KB | 525 lines

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


               Liste des Grauens - willkommen im Land der Bugs!


     Dieser Text führt die mir bekannten fehlerhaften oder prinzipiell nicht
     zukunftssicheren Befehle im GFABASIC 3.6. Er ist nicht als vollständig zu
     betrachten! Die Anzahl mir unbekannter Fehler im GFABASIC 3.6 ist mög-
     licherweise sehr hoch.

Diese Liste darf, mit Ausnahme der Verwendung in kommerziellen Produkten, frei
kopiert werden. Für die Verwendung in kommerziellen Produkten ist die schrift-
liche Genehmigung des Autors (E-Mail-Adresse: Uwe Ohse @PB2.MAUS.DE) einzuholen.
Updates zu diesem Text gibt es ausschließlich in der Quark-Box Paderborn.

1. Die GFA-Fensterverwaltung.
   Die einfache Fensterverwaltung mit OPENW, CLOSEW usw. ist in früheren
   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
   können mit den GFA-Fensterbefehlen nur bis zu vier Fenster verwaltet werden,
   was in Zukunft ein ernsthafter Mangel werden dürfte.
   Auch ist die GFA-Fensterverwaltung recht unflexibel.
   Die GFA-Fensterverwaltung kann übrigens mit großen 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 möglich, z.B. zwei Bugsicprogramme auf denselben Datenbestand
   loszulassen.
   Für dieses Problem gibt es bisher keine Lösung außer der Verwendung des
   GFA-nach-C-Konverters (gut, aber für 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 beschränkt sind
   3.1 Allgemein
   - GFABASIC verläßt sich darauf, daß VDI-Aufrufe den Inhalt von
     CONTROL(6) (das Handle der Workstation) nicht verändern. Dies ist eine
     undokumentierte Eigenschaft einiger VDI-Versionen, die andere Versionen
     nicht teilen. Mit anderen Worten: Möglicherweise steht nach dem
     Aufruf einer VDI-Funktion etwas ganz anderes in Control(6) als vorher.
     Und beim nächsten 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ß)
   - Außerdem unterscheidet sich die Syntax einiger VDI-Aufrufe (rund um
     das Öffnen und Schließen von virtuellen oder physikalischen Workstations)
     stark von der in anderen Sprachen gebräuchlichen.
   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 Fällen stürzt der Compiler während der Arbeit bombenwerfend
     ab.
   - Konstruktionen wie "IF exist(datei$)" können unter Umständen 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 sämtlichen Dateien wieder.
     Auch ein beim Mailboxprogramm Q_MAIL aufgetretener Effekt ist nur so
     erklärbar gewesen. Eine Programmteil der Form
     IF EXIST(zugriffsliste$)
       [lesen der Liste]
     ELSE
       [neuanlegen der Liste]
     ENDIF
     führte ab und zu (wenn auch selten) dazu, daß eine existierende Liste
     gegen die Defaultliste "ersetzt wurde".
     Ähnliches für alle anderen "Vergleiche irgendwas" Bedingungen, also
     auch für WHILE und UNTIL. Die Probleme lassen sich nicht vernünftig
     reproduzieren (und schon gar nichts in ein paar Zeilen), sind aber
     mittlerweile von genügend anderen Leuten bestätigt worden.
   - in einem relativ großen 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? führt auf Geräten ohne Cookiejar zum Absturz, da hier einfach
     unterstellt wird, daß eine FPU vorhanden ist.
   3.3 Interpreter
   - Der Interpreter greift in starkem Maße auf LineA zu. Schaltet man z.B.
     unter NVDI das LineA ab, funktioniert der Interpreter nicht mehr.
   - Er verbiegt auch Systemvektoren ohne die dafür vorgesehene Betriebs-
     systemfunktion setexc zu verwenden. Damit ist er unter MiNT und MultiTOS
     nicht mehr lauffähig. (Es sei denn, man patcht ihn. Siehe unten).
   3.4 Linker
   - Das Anlegen von Symboltabellen sollte man bei längeren Programmen
     unterlassen. Der Linker kann abstürzen.
   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 vergrößern. Dies war GFA
     vor der Auslieferung von Bugsic 3.6 bekannt und ist nicht behoben
     worden. Man denke darüber, wie man will.
     Die einzige Abhilfe ist, auf eine dynamische Speicherverwaltung mit
     Malloc umzusteigen. Leider unterstützt 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 abstürzt, aber eigentlich unnötig.
       ' 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 erfüllt
       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 Umständen 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 Möglichkeit auch Felder
     übergibt.
     Die Folgen reichen von kompletten Systemhängern bis zu einigermaßen
     zivilisierten, aber vollkommen falschen Fehlermeldungen des Interpre-
     ters.
     Abhilfe: CbV- und CbR-Parameter nach Möglichkeit nicht mischen, Felder
     nach Möglichkeit 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 Fällen 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.)

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:       hängt 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 nächsten
             Mausbewegung geändert. Abhilfe: GRAF_MOUSE() (ist sowieso
             sauberer).
EVERY:       hängt von $I+ ab und sollte vermieden werden. Abhilfe: Siehe
             AFTER.
EXEC:        Modus 4 funktioniert offenbar nur zufällig.
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
             könnte 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 ermöglicht auch eine I/O-Umlenkung.
             In GEM-Programme passt sie allerdings nicht (dasselbe gilt
             allerdings auch für INPUT).
INP?:        benutzt LA. Abhilfe: BIOS(1,device)
INSTR:       Die Varianten INSTR("xyz","xyz",2) und INSTR(2,"xyz","xyz")
             liefern 1 zurück, obwohl "xyz" in "yz" nicht vorhanden ist.
KEYDEF:      hängt 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 persönlich glaube auch
             nicht, daß die benutzung der Funktionstasten in reinen
             TOS-Programmen schön ist und gebe hierzu konsequenterweise
             keinen Tip.
L~A:         die Basisadresse der LA-variablen persönlich. Sozusagen der
             Teufel selbst. Für 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" zurückzugibt und nicht die tatsächliche
             Cursorposition!
PRINT:       gibt normalerweise über das BIOS aus. Arbeitet man aber mit
             PRINT#x, wenn x mit OPEN "O",x,"STD:" geöffnet ist, wird über
             die Standardausgabe ausgegeben. Diese Variante ist für 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 verläßlich 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 vergrößern. Abhilfe: Möglichst nur einen RESERVE
             benutzen, nämlich den zum Verkleinern des Arbeitsspeichers, oder
             diese Option zumindest unter MiNT/TOS3.06 anbieten, oder auf
             dynamische Speicherverwaltung mittels MALLOC umsteigen.
RESUME:      hängt von $I+ ab und sollte deshalb vermieden werden. Abhilfe:
             RESUME label. Auch hier heißt es aufpassen, da bei RESUME label
             der GFA-interne Stack inkonsistent wird. Ein Rücksprung (RETURN)
             aus einem Unterprogramm ist deshalb nicht sicher möglich, der
             RESUME label sollte also in eine Prozedur führen, die nicht wieder
             verlassen werden muß, z.B. das Hauptprogramm.
             (Ich erbitte mir Tips hierzu!)
RESUME NEXT: hängt 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, fällt 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 benötigt man Sprites sowieso nur in
             Spielen, und für 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 für Stero/DMA-Sound gesetzt ist.
             Somit macht Bugsic von der Soundhardware abhängig, auf welcher
             Maschine das Programm läuft. Was passiert auf dem Falcon? Mög-
             licherweise alles schlechte der Welt.
             Abhilfe: Den _MCH-Cookie selbst abfragen.
STICK:       sollte vermieden werden. Unter MultiTOS dürfte es sehr unschön
             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 führt unter bestimmten Umständen zum
             Absturz des Programms (fehlender Cookiejar, bzw. fehlender
             Cookie). btw: Wie arbeitet TT? eigentlich genau? _FPU, _CPU?
             Außerdem ü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?
             größere Teile des Programmes überschrieben wurden. Nach kurzem
             Debuggen des entsprechenden Routine kann ich das weder
             ausschließen noch erhärten.
VDIBASE:     Die Funktion liefert m.W. seit TOS 1.02 keine vernünftigen Werte
             zurück. 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 für die Standardauflösungen
             definiert.
_C,
_X,
_Y:          Liefern im compilierten Programm 0 zurück. 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 für 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.

5. Compileroptionen:
- $B+  "Fängt Bombenfehler ab"
  Hierfür werden diverse Vektoren verbogen. Die Anwendung dieser Option in
  Accessoires verbietet sich also von selbst ("Accessoires should not steal
  vectors"), sonst hagelt es Abstürze beim Auflösungswechsel.
  Es ist eigentlich überflüssig zu bemerken, daß selbstverständlich 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 natürlich weder XBRA noch setexc benutzt, und unter MiNT
  lauffähig sind Programme, die mit dieser Option compiliert wurden, auch
  nicht. Diese Option sollte man also ebenfalls besser nicht setzen.
  Aber: Das Setzen von $I- führt zu einigen Nebenwirkungen:
  -- Every und After können 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, löscht aber den bugsicinternen Stack und sollte nur ins
     Hauptprogramm oder eine Prozedur, die garantiert nicht per RETURN
     verlassen wird, führen.
-- $m Speicherbedarf festlegen
  $m bestimmt den Speicherplatz, den das compilierte Programm für Variablen
  und als Stack etc. verwenden soll. Nicht dazu zählt der Platz für
  Programmcode und Konstanten (Strings, Festzahlen ...). Ein $m5000
  beschränkt also den Platz im BSS-Segment auf 5000 Bytes und sorgt auch
  dafür, daß das compilierte Programm nicht noch weiteren Speicher mit Malloc
  an sich reißt.
  Sehr sinnvoll ist diese Option für Programme, die unter Multitos laufen
  sollen oder Accessoires. [Siehe außerdem RESERVE]

  Es gibt keine Möglichkeit, aus Bugsic herauszukitzeln, wieviel Speicher ein
  Programm denn benötigt. Die Mühe muß man sich leider selbst machen.
  - Man könnte im Interpreter in einer mit EVERY "kleiner Zeitabschnitt"
    aufgerufenen Funktion das Maximum gleichzeitig belegten Speichers
    bestimmen.
  - Natürlich kann man sich diesen Wert auch berechnen. In der Praxis ist das
    relativ einfach, da man sein Programm ja schließlich ordentlich
    vorbereitet hat und dabei natürlich 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 können sehr schwer zu
  finden sein.

  Faustformel:
   Der benötigte 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 abgeschätzt 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 für
   AES- und VDI-Parameterfelder. 5K reichen aber locker.
   IO-Puffer: Für jedes mit OPEN geöffnete File braucht Bugsic 4K Speicher.
   Reserve: Ein Sicherheitsabstand von ein paar K sollte für den Fall, daß mal
   mehr Speicher benötigt wird, als man gedacht hat, immer eingeplant werden.

   Der Speicherplatz für Resourcen wird mit "Malloc" alloziert, er braucht für
   $m also nicht berechnet zu werden. Denke aber daran, daß Resourcen bei ACC's
   frühzeitig geladen werden müssen - wie auch alle Mallocs am Programmstart
   getätigt werden müssen (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 für POLYLINE.
  Generell gilt dies für alle Befehle, die viele Koordinaten an das VDI
  übergeben. Das ist kein Bug, nur eine Beschränkung.

7. Hinweise auf weitere Quellen in rein zufälliger Reihenfolge:
- Von Karsten Isakovic (Maus Berlin) kreist ein Text mit Tips über
  auflösungsunabhängiges 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 durchführt. 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 enthält 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 grundsätzlich zum
  Laufen zu bekommen, hat Frank Baumgart ein Tool geschrieben, das die
  diversen setscreens abfängt. Es liegt als BUGSSFIX.LZH im Brett ST-Tools in
  der Quark Paderborn.

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

8. Programmierung von Accessoires
  - Wie oben schon erwähnt: Die Benutzung von $B+ und $I+ ist verboten und
    führt beim Auflösungswechsel 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 Prüßner verwenden.
  - Accessoires haben keine vollständige 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 für FSFIRST/FSNEXT/EXIST) ist defaultmäßig 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 können (ohne größeren Aufwand und schmutzige Tricks) keine
      Programme starten.

9. Programmierung MiNT- und MultiTOS-fester Programme
  - $I+ und $B+ sind unter MiNT tödlich
  - 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
    Speicherblöcke im direkt aufeinander folgen
  - Fensterhandles können größer als nur 7 werden (MTOS)
  - Fensterelemente können auch im Hintergrund bedient werden.
  Programmiertip: Wird ein Pfeil oder ein Scrollbalken eines im Hintergrund
  liegenden Fensters betätigt, kann man die neuzuzeichnenden Teile des
  Fensters aus der Rechteckliste holen.

10. disclaimer: Ich, Uwe Ohse, übernehme keine Verantwortung für Korrektheit
  oder Vollständigkeit 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 dafür verantwortlich.

11. Dieser Text ist auf Grundlage meines heutigen Wissens entstanden. Ich bin
  gerne bereit, ihn zu korrigieren und zu ergänzen. Dazu brauche ich
  natürlich Mitarbeit!
  Die jeweils aktuellste Version dieser Mängelliste 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 erhältlich, kein funktionierender Debugger, C++ )
  - Hänisch Modula II (schnell, Onlinehilfe, sehr gute Libs, für Modula
           sehr portabel)
  - Pure Pascal (Turbo 6.0 kompatibel, sehr guter Debugger, Onlinehilfe,
           sehr schnell, Oberfläche Gift für MTOS)
  - GFA 4.0, sobald es fertig ist, könnte eine werden.

  Für 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-Unterstützung liefert, ohne daß die Programmierer etwas daran tun
  müßte, und auch garantiert, daß das Programm unter reinem TOS lauffähig ist.
  Der erzeugte Code ist bei allen oben genannten Systemen gut bis sehr gut.


Gruß und viel Spass, Uwe