Bug
2. Fehler/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5

English


Kurzübersicht:

2.0. PowerBASIC-Fehlerbibliotheken
2.1. Das NUMERIC/OVERFLOW-Problem in PowerBASIC 3.0
2.2. Das NUMERIC/OVERFLOW-Problem in PowerBASIC 3.1/3.2
2.3. Kein Overflow-Fehler beim Doubleword
2.4. Absturz der PowerBASIC IDE und fertiger EXE's beim Laden
2.5. unterschiedlich große EXE-File beim Komplieren mit PB/PBC
2.6. unterschiedliche EXE-Files bei gleicher Kompilation
2.7. Probleme mit der Maus innerhalb der IDE
2.8. Das Fixup Overflow Syndrom
2.9. Die Sache mit dem ASCII-154 nach einen REMARK im Inline-ASM
2.10. Fehler 454: END FUNCTION expected
2.11. Noch ein REMARK-Problem bei $ALIAS
2.12. Der Fehler CDWRD in der OnLine-Hilfe
2.13. Der Fehler CVDWRD in der OnLine-Hilfe
2.14. Absturz bei Betätigen von CNTRL-C
2.15. Fehler bei Verwenden der Ausgabe über "CONS:" und CNTRL-C
2.16. Die Sache mit dem Fehler 244 in einer Stand Alone EXE-Datei
2.17. Probleme bei Verkettung mehrerer Zeilen Sourcecode
2.18. Probleme mit dem WATCH-Fenster und mehrdimensionalen Arrays
2.19. Fehlerhafte interne Funktion/Variable: pbvScrnCols
2.20. unkorrekte interne Funktion/Variable: pbvHost
2.21. Ein kleiner Unterschied im neuen InLine-Assembler der V3.1/3.2
2.22. Das dd-Problem bei PowerBASIC 3.1/3.2
2.23. undokumentierte interne Variablen in PowerBASIC 3.0/3.1/3.2
2.24. Der PRINT-Bug in PowerBASIC 3.2
2.25. Der Fehler "File not found" nach Verwendung von NAME
2.26. Rechenfehler bei der Verwendung von Konstanten
2.27. falsches "Bit schieben" bei ROTATE
2.28. Overflow bei Verwendung von FOR/NEXT-Schleifen
2.29. Overflow bei Verwendung von STEP -1 in FOR/NEXT-Schleifen
2.30. Der Bug im VARPTR32-Befehl
2.31. Der "KEY ON" Bug
2.32. Absturz der PowerBASIC IDE im Pick-Menü
2.33. Absturz der PowerBASIC IDE bei fehlerhaften Syntax
2.34. falsches Vertauschen der Variablen bei Verwendung von SWAP
2.35. Der Multiplexer Interrupt Fehler im REG-Befehl
2.36. Inhalt eines Verzeichnis wird mit KILL gelöscht
2.37. Die Sache mit der Zeichenkette "USR"
2.38. Der GOTO DWORD Bug
2.39. Der 'ON LOCAL ERROR' Bug
2.40. ... und nochmal 'ON LOCAL ERROR'
2.41. Laufzeitfehler im PowerBASIC Helpcompiler
2.42. Der Fehler Truncating im PowerBASIC Helpcompiler
2.43. Absturz der PowerBASIC-IDE nach Aufruf der eigenen Hilfe

2.0. PowerBASIC-Fehlerbibliotheken

Zur besseren Sicherheit Ihrer eigenen Programme empfehle ich prinzipiell die Einbindung aller Fehlerbibliotheken. Nur so können Sie sicher sein, das PowerBASIC auch den wahren Fehler anzeigt und z.B. nicht bei:
            SELECT CASE pbvrevision
mit einem unerklärlichen Fehler aussteigt. Im fertigen Programm könnnen Sie die Bibliotheken wieder entfernen, da sie eigentlich nur während der Programmentwicklung wirklich benötigt werden.
Die $ERROR-Bibliotheken können Sie innerhalb der IDE ständig einbinden oder direkt in Ihrem Sourcecode definieren. Die Einstellungen im Sourcecode haben gegenüber den Einstellungen der IDE Vorrang!

Die $ERROR-Bibliotheken binden Sie wie folgt ein:
            $ERROR NUMERIC ON
            $ERROR OVERFLOW ON
            $ERROR BOUNDS ON
            $ERROR STACK ON
Achtung: Einige der hier aufgezeigten Ungereimtheiten können nur mit diesen Bibliotheken aufgedeckt werden!

2.1. Das NUMERIC/OVERFLOW-Problem in PowerBASIC 3.0

Versionen: 3.0
bekannt : teilweise in Version 3.10 beseitigt

Die hier aufgeführten Probleme beziehen sich nur auf die Verwendung von vorzeichenlosen Variablen und werden an Variablen vom Typ WORD aufgeführt:
    Beispiel 1:
            Demo?? = &hA000
führt zu einem Overflow, da PowerBASIC dies als vorzeichenbehaftete Variable versucht zu interpretieren. Dieser Fehler kann nur durch Angabe einer Realzahl umgangen werden.
Ähnliche Effekte lassen sich im $NUMERIC-System auch bei Verwendung des REG()-Befehles nachvollziehen:
    Beispiel 2:
            Demo?? = REG(1)
kann unter Umständen ebenfalls zu einem Überlauf führen, sofern der übergebene Wert als INTEGER negativ wäre. Den Fehler können Sie umschiffen, sofern sie bei der Verwendung von REG() nur Variablen vom Typ INTEGER verwenden, die NUMERIC-Bibliothek beim Kompilieren entfernen.
Noch viel besser ist es allerdings, den alten BASIC-Unsinn über Bord zu werfen und die Geschichte gleich im InLine-Assembler sauber zu programmieren! ;-)

Interessant ist auch das 'Verschleppen' von Fehlern bei ausgeschalteter $ERROR NUMERIC Bibliothek. Der Fehler tritt dann etwas später im Programm auf, komischerweise aber ebenfalls bei Variablen vom Typ WORD. Eigenartigerweise läßt sich dies am besten mit den internen PowerBASIC- Variablen vom Typ WORD nachvollziehen.

Ein weiterer Overflow-Effekt verbirgt sich in den PowerBASIC-Funktionen STRSEG/STRPTR, VARSEG/VARPTR, CODESEG/CODEPTR. Im Gegensatz zum REG() Befehl müssen die Variablen definitiv vom Typ WORD sein, ansonsten droht wiederum ein Überlauf in größeren Programmen.

2.2. Das NUMERIC/OVERFLOW-Problem in PowerBASIC 3.1/3.2

Versionen: 3.1/3.2
bekannt : Nachbesserung bei PowerBASIC Inc. verlangt

Man soll nicht denken, das eine neue Version auch die ganzen alten Fehler in Vergessenheit geraten läßt ;-).
    Beispiel 1:
            Demo?? = &hA000
kann weiterhin zu einem Überlauf führen. Leider läßt sich dieser Fehler nicht mehr in einer Zeile demonstrieren, da er gelegentlich in sehr komplexen Programmen weiterhin auftritt. Das hat sich mit PowerBASIC in der Version 3.20 leider immer noch nicht geändert. Im Gegensatz zur Version 3.00 kann der Fehler aber durch explizente Unsigned-Angabe beseitigt werden:
            Demo?? = &h0A000
Sollten Sie Toolbox-Entwickler sein und auf Nummer sicher gehen wollen, dann geben Sie in folgene Zeile ein, sofern Ihre Sourcen auch unter PowerBASIC 3.0 laufen sollen:
            ! mov ax, &hA000
            ! mov Demo??, ax

    Beispiel 2:
            Demo?? = REG(1)
führt meines Erachtens nicht mehr zu einem Overflow, ganz ausschliessen kann ich dies aber nicht. Trotzdem sollte man bei der Verwendung von REG weiterhin nur Variablen vom Typ INTEGER verwenden. Viele PowerBASIC- Funktionen funktionieren jetzt besser, andere bereiten trotzdem Probleme. Dies betrifft wieder diverse spezielle Routinen welche nur für Integer- Variablen ausgelegt sind, aber trotzdem mit Variablen vom Typ WORD funktionieren.

Das Overflow-Problem bei STRSEG/STRPTR, VARSEG/VARPTR und CODESEG/CODEPTR ist weiterhin existent.

2.3. Kein OVERFLOW-Fehler beim Doubleword

Versionen: 3.0/3.1/3.2/3.5
bekannt : ja

Für Variablen vom Typ Doubleword ist in PowerBASIC kein Overflowtest integriert. Dies können Sie an einem kleinen Beispiel testen.
    Beispiel:
            i??? = -1
            PRINT i???
Die Ursache für diesen Mangel liegt in der Intel CPU selbst begründet, denn dort gibt es keinen Overflow den der Compiler auswerten könnte.

2.4. Absturz der PowerBASIC IDE und fertiger EXE's beim Laden

Versionen: 3.0/3.1 (3.2 nicht getestet)
bekannt : nein (teilweise)

Ein Absturz der IDE beim Laden tritt eigentlich recht selten auf und ist im Prinzip immer auf folgende Ursachen zurückzuführen: In den meisten Fällen wird die IDE während des Ladevorganges mit einem Grafikfehler (Cursor innerhalb der IDE) auf die Kommandozeile zurückkehren.
Ebenfalls betroffen von diesem Effekt sind alle fertigen PowerBASIC-EXE Files. Wollen Sie diesen Effekt auf alle Fälle umgehen, so müssen Sie die PowerBASIC-EXE mit einem EXE-Packer wie PKLITE komprimieren.

2.5. unterschiedlich große EXE-File beim Komplieren mit PB/PBC

Eigentlich ist dies kein Fehler, da es nur einen kleinen Unterschied in der Wirkungsweise des IDE-Compilers zu dem Kommandozeilencompiler gibt, welche die unterschiedlich großen EXE-File erklärt.
Die IDE compiliert die EXE-Datei immer nach den Einstellungen in der IDE, das heißt wenn Sie dort zum Beispiel die VGA-Lib nicht mit compilieren wollen, so geben sie das als Standard in der IDE an. Der PBC compiliert dagegen die VGA-Lib immer mit, sofern sie das nicht als Metastatment anderweitig deklariert haben.
Die Metastatment-Einstellung haben immer Vorrang vor den Einstellungen in der IDE!

2.6. unterschiedliche EXE-Files bei gleicher Kompilation

Versionen: 3.0/3.1
bekannt : anscheinend

Einen netten Effekt gibt es zu berichten, sofern Sie Sourcen mehrmals compilieren und diese dann mit einem Filevergleich-Utility einer genauen Betrachtung unterziehen. Sofern sich Ihr verfügbarer freier Speicher geändert hat, werden die erstellten EXE-Files unterschiedlich sein.

Meines Erachtens speichern die beiden PowerBASIC Compiler auch Ursprungsinformationen mit ab, welche vom Typ Integer/Word sind und sich immer an den Offset's &h9C/&hA0 befinden (PB3.1). Dieser Effekt läßt sich mit der PB-IDE und auch dem PBC nachvollziehen.

Nach einigen Auskünften sollen PB-EXE-Files, welche unter einer PowerBASIC-SHELL mit PBC compiliert wurden zum Abstürzen neigen.

Da ich aber selbst seit ca 2 Jahren alle meine Projekte auf ähnliche Weise compiliere, kann ich diesen Effekt nicht nachvollziehen oder bestätigen. In Version 3.0 des PowerBASIC-Compilers schien allerdings der SHELL-Befehl anderweitige Effekte bei großen EXE-File auszulösen. Die Probleme lösten sich damals mit der Verwendung eines alternativen PBSHELL-Befehls.

2.7. Probleme mit der Maus innerhalb der IDE

Versionen: 3.0
bekannt : anscheinend in Version 3.1 behoben

Sollten Sie innerhalb der IDE mit der Maus arbeiten damit Sie komfortabel Sourcecode Einfügen und Ausschneiden können, so kann dies beim Markieren längerer Texte (welche den rechten Bildschirmrand überschreiten) zu einem Teilabsturz führen. Des weiteren markiert der Maus-Cursor die Texte nicht richtig. Sie erkennen das daran, das Sie in der Regel eine längere Zeile nicht markieren können.
Des weiteren scheint es vereinzelt Probleme mit der Mausunterstützung zu geben, Sofern sie den 80*43/50'er Textmodus verwenden.

2.8. Das Fixup Overflow Syndrom

Versionen: 3.0/3.1/3.2
bekannt : Nachbesserung bei PowerBASIC Inc. verlangt

So jetzt kommen wir zu meinem Lieblingsfehler, zumal er eigentlich durch einen ernsthaften Programmierfehler seitens des PowerBASIC Anwenders ausgelöst wird. Die Beschreibung im Handbuch, sowie der OnLine-Hilfe, ist leicht irreführend dennoch prinzipiell richtig.

Ich persönlich würde den Fehler wie folgt beschreiben:

<neue Fehlerbeschreibung>
PowerBASIC konnte die angegebene Sprungadresse nicht finden. Eine mögliche Ursache ist ein SHORT-Sprung zu einem Label der nicht im gültigen Bereich für einen SHORT-Sprung liegt. Bitte Überprüfen Sie alle Sprungbefehle auf Ihren Gültigkeitsbereich.
<Ende>

Leider hat sich gerade bei dieser Fehlermeldung in beiden PowerBASIC Versionen ein Fehler eingeschlichen. Da die menschliche Natur prinzipiell nicht so recht glauben will was da so steht, wird die Source eben nochmals (ohne Änderung) kompiliert. Die IDE quittiert das sofort mit einem Absturz.

Eine genauere Beschreibung des Zusammenspiels der einzelnen Assembler- Befehle, vor allem die verschiedenen Adressierungsarten in Abhängigkeit von der CPU, erspare ich mir hier. Dafür gibt es jede Menge Assembler- Bücher, meines Erachtens eh eine Voraussetzung zur sinnvollen Programmierung mit dem InLine-Assembler.

2.9. Die Sache mit dem ASCII-154 nach einen REMARK

Versionen: 3.0/3.1/3.2
bekannt : Fehler in Version 3.50 beseitigt

Eine nette Sache kann Sie zum Beispiel in Verbindung mit einer guten Kommentierung Ihrer InLine-Assembler Source schlichtweg zum Wahnsinn treiben: Die Sache mit dem Sonderzeichen ASCII-154 nach einem REMARK (REM bzw. ; ):
    Beispiel:
            CLS
            PRINT "1"
            ! nop                ; Ü   <- (ASCII-154)
            PRINT "2"
PowerBASIC wird in diesem Fall die Programmausführung bis zu der Zeile mit dem Sonderzeichen (nach dem REM) fortsetzen und dann stoppen. Die hartgesottenen können diese Sache auch einmal mit dem Debuger verfolgen. In diesem Fall werden Sie feststellen, das PowerBASIC nach dem REMARK einfach nur noch sieben ASCII-Nullen an den Code anhängt und das weitere Compilieren einstellt.


Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 2)
Fehler (Bug's)/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5 (Teil 3)


(c) 1995/2007 by Thomas Gohel, All rights and bug's reserved