@(#) 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 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. Fr 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 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 k”nnen 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 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. Fr dieses Problem gibt es bisher keine L”sung aužer 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 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 strzt 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 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 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? fhrt 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 dafr 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 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 vergr”žern. 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 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 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 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 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: 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. 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 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 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 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 Rcksprung (RETURN) aus einem Unterprogramm ist deshalb nicht sicher m”glich, 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: 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 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 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 drfte 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 fhrt 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 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 Standardaufl”sungen 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. 5. Compileroptionen: - $B+ "F„ngt 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 Aufl”sungswechsel. Es ist eigentlich berflssig 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 natrlich 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- fhrt 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, fhren. -- $m Speicherbedarf festlegen $m bestimmt den Speicherplatz, den das compilierte Programm fr Variablen und als Stack etc. verwenden soll. Nicht dazu z„hlt der Platz fr Programmcode und Konstanten (Strings, Festzahlen ...). Ein $m5000 beschr„nkt 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 reižt. Sehr sinnvoll ist diese Option fr 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 Mhe 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. - Natrlich 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 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 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 fr AES- und VDI-Parameterfelder. 5K reichen aber locker. IO-Puffer: Fr jedes mit OPEN ge”ffnete File braucht Bugsic 4K Speicher. Reserve: Ein Sicherheitsabstand von ein paar K sollte fr den Fall, daž mal mehr Speicher ben”tigt 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 get„tigt 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 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 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 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 fr die Quark PB: So ist es :-) 8. Programmierung von Accessoires - Wie oben schon erw„hnt: Die Benutzung von $B+ und $I+ ist verboten und fhrt 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 fr 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 fr 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 dafr 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 natrlich 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, fr Modula sehr portabel) - Pure Pascal (Turbo 6.0 kompatibel, sehr guter Debugger, Onlinehilfe, sehr schnell, Oberfl„che Gift fr MTOS) - GFA 4.0, sobald es fertig ist, k”nnte 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 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