=========================================================
2. Errors (Bug's) in PowerBASIC Versions 3.0, 3.1 and 3.2
=========================================================
Shortindex:
2.0. PowerBASIC-Errorlibraries
2.1. The NUMERIC/OVERFLOW-Problem in PowerBASIC 3.0
2.2. The NUMERIC/OVERFLOW-Problem in PowerBASIC 3.1/3.2
2.3. No Overflow-Error with Doublewords
2.4. Crash of the PowerBASIC IDE and compiled EXE's while loading
2.5. Different sized EXE's when compiling with PB/PBC
2.6. Different EXE-Files with same Compilation
2.7. Problems with the Mouse within the IDE
2.8. The Fixup Overflow Syndrome
2.9. The thing with ASCII-154 after a Remark in the Inline-ASM
2.10. Error 454: END FUNCTION expected
2.11. Another REMARK-Problem with $ALIAS
2.12. The Mistake CDWRD in the Online-Help
2.13. The Mistake CVDWRD in the Online-Help
2.14. Crash when pressing CTRL-C
2.15. Error when producing Output with "CONS:" and CTRL-C
2.16. The Problem with Error 244 in a Stand Alone EXE
2.17. Problems with linking of multiple Lines of Source
2.18. Problems with the WATCH-Window and multidimensional Arrays
2.19. Buggy internal Function/Variable: pbvScrnCols
2.20. Incorrect internal Function/Variable: pbvHost
2.21. A little difference in the new Inline-Assembler of V3.1/3.2
2.22. The dd-Problem in PowerBASIC 3.1/3.2
2.23. Undocumented internal Variables in PowerBASIC 3.0/3.1/3.2
2.24. The PRINT-Bug in PowerBASIC 3.2
2.25. The "File not found"-Error after using NAME
2.26. Calculationerror when using Constants
2.27. Wrong "Bit Movement" with ROTATE
2.28. Overflow when using FOR/NEXT-Loops
2.29. Overflow when using STEP -1 in FOR/NEXT-Loops
2.30. The Bug in the VARPTR32 Command
2.31. The "KEY ON" Bug
2.32. Crash of the PowerBASIC IDE in the Pick- Menu
2.33. Crash of the PowerBASIC IDE with faulty Syntax
2.33. Runtimeerror in the PowerBASIC Helpcompiler
2.34. The Bug "Truncatig" in the PowerBASIC Helpcompiler
2.35. Crash of the PowerBASIC-IDE after calling its own Help
2.0. PowerBASIC-Errorlibraries
------------------------------
For better Security of your own programs I would recommend that you
link all Errorlibraries. This is the only way to make sure that
PowerBASIC shows the true Error and not an unexplainable Error at:
SELECT CASE pbvrevision
You can remove all Errorlibraries in the finished program, because
they are only needed in development.
The $ERROR-Libraries can be linked within the IDE or directly in your
Source. The Settings in the Source are used above the Settings in the
IDE!
The $ERROR-Libraries are linked as follows:
$ERROR NUMERIC ON
$ERROR OVERFLOW ON
$ERROR BOUNDS ON
$ERROR STACK ON
Note: Some of the Bugs shown here can only be found with these
Libraries linked!
2.1. The NUMERIC/OVERFLOW-Problem in PowerBASIC 3.0
---------------------------------------------------
Versions: 3.0
Known : partly removed in version 3.10
The problems shown here only apply to the use of unsigned variables
and are shown as variables of type WORD:
Example 1:
Demo?? = &hA000
causes an Overflow, because PowerBASIC interprets this as a signed
variable. This error can be solved by using a real number.
Similar effects can occur with the $NUMERIC-System when using the
REG()-Command:
Example 2:
Demo?? = REG(1)
can, under special circumstances, cause an Overflow, too, if the
passed value would be negative as INTEGER. This error can be solved,
if only using variables of type INTEGER with REG(), by removing the
NUMERIC-Library when compiling
It would be much better though to trash the old BASIC-Crap and do the
whole thing in InLine-Assembler right away! :-)
It is also interesting to see the 'floating' of error with deactivated
$ERROR NUMERIC library. The error occurs some later time in the
program, strangely at variables of type WORD, too. Even stranger that
you can at best see this at internal PowerBASIC variables of type
WORD.
Another Overflow effect is hidden behind the PowerBASIC-Functions
STRSEG/STRPTR, VARSEG/VARPTR, CODESEG/CODEPTR. Unlike REG(1) the
variables MUST be of type WORD, else an Overflow can occur in bigger
programs.
2.2. The NUMERIC/OVERFLOW-Problem in PowerBASIC 3.1/3.2
-------------------------------------------------------
Versions: 3.1/3.2
Known : Correction recommended at PowerBASIC Inc.
One shouldn't think that a new version lets the old bugs be forgotten
;-).
Example 1:
Demo?? = &hA000
can still cause an Overflow. This can't be demonstrated in one line
anymore, because it sometimes still occurs in very complex programs.
This still has not changed with version 3.20. Unlike version 3.00 this
bug can be passed by using definite unsigned variables:
Demo?? = &h0A000
Should you be Toolbox-Developer and want to make sure that your
sources work under PowerBASIC 3.0 then enter the following lines:
! mov ax, &hA000
! mov Demo??, ax
Example 2:
Demo?? = REG(1)
does not cause an Overflow anymore, as far as I know, but you can't be
sure about that. But one should still use variables of type INTEGER
when using REG. Many PowerBASIC-Functions work better now, others
still cause trouble. this affects some special routines which are only
set for INTEGER variables, but still work with variables of type WORD.
The Overflow problem with STRSEG/STRPTR, VARSEG/VAROTR and CODESEG/
CODEPTR is still existing.
2.3. No OVERFLOW-Error with Doublewords
----------------------------------------
Versions: 3.0/3.1/3.2
Known : No
For Variables of the type Doubleword no Overflowtest was integrated
into PowerBASIC. This can be tested with this small example.
Example:
i??? = -1
PRINT i???
As you can see, PowerBASIC always interprets the negative value as its
unsigned Opposite. Normally this isn't to important, but in connection
with the REG()-Command it can cause calculationmistakes. As shown in
the two preceeding Chapters, the REG()-Command 'likes' to pass signed
values.
2.4. Crash of the PowerBASIC IDE and compiled EXE's while loading
-----------------------------------------------------------------
Versions: 3.0/3.1 (3.2 not tested)
Known : No (partly)
A Crash of the IDE while loading occurs rather rarely and can usually
be traced back to one of the following:
- QEMM Memorymanagementsystem (up to Version 7.03)
- extremly low ammount of free Low Dos Memory
- You have tried to load the IDE with the LOADHIGH-Command
- 4DOS
In most cases the IDE will return to the Commandline with a graphical
Error (Cursor within the IDE) while loading.
Also struck with this effect are all compiled PowerBASIC-EXE Files. If
you want to get around this effect at any cost, you will have to
compress the PowerBASIC-EXE with an EXE-Packer like PKLITE.
2.5. Different sized EXE's when compiling with PB/PBC
-----------------------------------------------------
This isn't really a Bug, because there is only a small difference in
the cause of the IDE-Compiler and the Commandlinecompiler, which
explains the differently sized EXE-Files.
The IDE always compiles the EXE-File with the Settings in the IDE,
meaning that if you don't want to compile the VGA-Lib into it, you set
it in the IDE. The PBC always compiles the VGA-Lib into it, IF you
haven't declared it differently with a Metastatement.
The Metastatements are always taken before the IDE-Settings!
2.6. Different EXE-Files with same Compilation
----------------------------------------------
Versions: 3.0/3.1
Known : Seems so
A nice effect is to be reported, when you compile Sources more than
once and then compare them with a Filecompare-Utility. If your free
Memory has changed, the created EXE-Files will be different.
As far as I see it, the two PowerBASIC Compilers save some Information
about the system they were compiled on, which are of Integer/Word type
and are at the Offset's &h9C/&hA0. (PB3.1) This effect can be shown as
well in the PB-IDE as with PBC.
Some say that PB-EXE-Files which were compiled under a PowerBASIC-
Shell with PBC seem to crash more often.
But even since I have been compiling all of my projects like this for
two years, I can not approve to this effect. Version 3.0 of the
PowerBASIC-Compiler SHELL seemed to cause other effects with big EXE-
Files. The problems were solved back then by using an alternativ
PBSHELL-Command.
2.7 Problems with the Mouse within the IDE
-------------------------------------------
Versions: 3.0
Known : Seemingly corrected in Version 3.1
Should you work with a Mouse in the IDE, so that you can insert and
cut Sorucecode easily, this could cause a partly crash when marking
long texts which go past the right screen border. Furthermore the
Mousecursor does not mark the text correctly.
There also seem to be some problems when using the Mouse in the 80*43
/50 Mode.
2.8. The Fixup Overflow Syndrome
--------------------------------
Versions: 3.0/3.1/3.2
Known : Correction demanded at PowerBASIC Inc.
This is my favorite Bug, since it is actually caused by a real error
in the programming of a PowerBASIC- User. The description in the
Manual, as well as in the Online-Help is slightly irritating, but
principally correct.
Personally I would decribe the Bug like this:
PowerBASIC could not find the named Jumpaddress. A possible cause for
this is a SHORT-Jump to a Label not in the valid Area for a SHORT-
Jump. Please check all Jumpcommands for validity.
There is a small Bug in this Errormessage in both PowerBASIC Versions.
But since the human mind will not really believe what is written
there, the Source is compiled again (without change). The IDE crashes
for doing that immediately.
I will save myself a closer description of the working of the
different Assemblercommands, especially the different ways of
addressing in relation to the CPU. There are many Assemblerbooks out
there, and they are something really needed for good programming with
the Inline-Assembler anyways.
2.9. The thing with ASCII-154 after a REMARK in the Inline-Assembler
--------------------------------------------------------------------
Versions: 3.0/3.1/3.2
Known : No
For example there is a nice little thing that can drive you crazy when
doing good commenting in the Inline-Assembler Source.It's the thing
with the ASCII-154 after a REMARK
(REM or ; ):
Example:
CLS
PRINT "1"
! nop ; Ue <- (ASCII-154)
PRINT "2"
PowerBASIC will in this case continue the running of the program the
the line with the ASCII-154 (after the REM) and then stop. The hard-on
guys can trace the whole thing with the Debugger. They'll notice that
in this case PowerBASIC will simply add seven ASCII-Zeros to the Code
and then stops compiling.
--- CrossPoint v3.11 R
---------------
* Origin: -= http://www.snafu.de/~pbsound/ =- (2:2410/330.1)
|