------------------------------------------------------- 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: < new Bugdescription > 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. < End > 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/301.12) --------------- FIDO MESSAGE AREA==> TOPIC: 214 POWER BASIC Ref: DD200004 Date: 09/01/96 From: THOMAS GOHEL Time: 12:00am \/To: ALLE (Read 5 times) Subj: FAQ: PowerBASIC 04/16 (Bug's - Part 2) 2.10. Error 454: END FUNCTION expected --------------------------------------- Versions: 3.0/3.1/3.2 Known : No This Bug can occur when a comment in an Inline-Assemblerline contains the ASCII- 154. Please read the previous paragraph for more information. 2.11. Another REMARK-Problem with $ALIAS