2. Fehler/Ungereimtheiten in den PowerBASIC-Versionen 3.0, 3.1, 3.2 & 3.5
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:
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:
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:
- QEMM Speicherverwaltungsmanager (bis Version 7.03)
- extrem wenig verfügbarer Arbeitsspeicher
- Sie haben versucht die IDE mit dem Befehl LOADHIGH zu laden
- 4DOS
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)