QBasic from the Hell

[TheBigBasicQ]

Zack: How young were you?

[Spotted Cheetah]

I happily thought that i found the purpose of the bug. But QBasic won again
The same thing happens with type prefixes exactly the same way. The most annoying is
that the same code worked before. Then i cut out a few things from an another part,
and inserted some others, but the code became smaller (70Kb source; 89Kb EXE), and
then this horrible bug had risen. No way to fix it except inserting a third variable.

Here is the code:

DEFINT A-Z
something& = array1&(num1%) + array2&(num2%)

And this does not add that two number together only if i do this:
(Here there is no third variable, but sometimes it is needed to be included)

DEFINT A-Z
something& = array1&(num1%)
something& = something& + array2&(num2%)

If one of the values were plain integer, i would understand that, but since all of
them are the same type there should be no bug in this. And it worked originally, QB
started to not add them together when it "thought it is the time to make it more
exciting". If anyone can explain why is this happen, i would give him $1 000 000
(just joking, but this is a problem what would worth that money... Deassemble QB,
hunt down that bug, then assemble it again making it working...).


And this bug was not what made me the most upset. Yes, it is that integer addition
when exactly the same thing happened, but PRINTing the result fixed it.

This not worked:

something% = a% + b% + c%

But this worked:

something% = a% + b% + c%
PRINT something%

The value of 'something%' became correct. Is there any acceptable explanation why
this happens? Another $1 000 000...



I am planning to write my own version of Basic once because of these annoying things
in pure ASM, the problem is not that i will not be able to do it rather that i have
not got time. But once you might run into a "Cheetah - Basic"

I like Basic since this language is the most close to ASM in structure. Assembly
never had real functions, or never needed to have main(). The GOTO statement, and
the EXIT SUB thing are ASM styleish too. A very good Basic compiler would be able to
create faster codes than any high - level C style language (If the programmer who
works in it uses up the flexibility of GOTOs what not exist in C, but there are many
other places too where the basic programmer can use up the relation to ASM).

What i am planning sometimes is a pseudo - compiler outputting assembly code can be
fed with NASM. This way i would include all the commands offered in QBasic, but would
add support for inline ASM too. Since this compiler would rely on NASM, it could be
made to program Win32 applications too. My concept is then that every Basic statement
have to work the same way as in the DOS version except that they will call Windows' or
Linux's functions where needed. So for example i would include SCREEN this way:

Code:

DOS:
  0 - 13: calls the modes what QBasic calls
14 - xx: calls some special modes (Unchained 256 color VGA / 16 color modes)
yy -   : calls standard VESA modes
Windows:
  0 - xx: emulates those VGA modes
yy -   : sets the VESA modes using up the OS's handler

To make PSETting faster i would include support for buffered graphic operations (what
i made already in ASM for a try). This means that every graphic operation is being
sent in a buffer until it is being filled, or the programmer sends it's data to the
screen. This would be done automatically with PCOPYing, or page flipping if the
programmer had worked on an invisible page. When working on the active page the
buffer would not be used except if the programmer turns it on by a compiler directive.
This would really speed up unchained VGA operations (Of course it would be only used
there). This would not be used at Windows where i would create an easier to handle
structure for the emulated VGA modes.
I would include an other useful thing at graphic: to use up not needed video memory
as you wish. For example when programming Screen 12 you will have more than 64Kb of
it. It is not the fastest thing, but might be useful to store certain things in it.
It will be useful as a screen page fraction too, for example if you only need a
600 * 300 sized playing area on the screen.

At interrupt handlers i would emulate the most common things (For example mouse) in
Windows, for ports too. This would be made by catching the OUT statement during
translating to ASM, and inserting the appropriate ASM commands calling the appropriate
function of the OS to achieve the effect. For example if the compiler finds an
OUT &3D8 what would modify the palette, then it would change the colors in it's array
storing the palette, then it would update the screen (This way palette flipping will
become a slow operation, but there are no other ways to update an SVGA mode).

So i would create that language to support at least 90% of the original BASIC (there
are some so rarely used commands that do not wort to include them), and to compile
the programs well for Windows or Linux too (of course some parts should be rewritten
then, but the "good old game" feeling would be kept).


What i wrote here? Writing a compiler?! Harder than i think! Yes, this is true, and
that i have not got time for it. But once i will have (and i will have a computer too
what can run at least Win 95), i will do it since i like Basic's structure (This was
why i like ASM too). Then, of course, i will make my further programs using that
compiler (So if once i will start it writing... So then the age will come when
everyone will be able to learn programming, and develop himself or herself to
professional using the same programming language. Nice dreams...)



(Note: i did not read any post since i put up this topic as i must hurry when i am
online. I will download them now and read, and reply only later. Sorry.)

[Spotted Cheetah]

Sorry, i just noticed that i hit Post so angrily last time that it went twice... It looked like that my computer freezed and i have no time...

[HQSneaker]

Zack: How young were you?

He's thirteen now, so he was pretty young I guess :wink:

[TheBigBasicQ]

There is an annoying flaw with QB. Sometimes when I used interrupts, some variables just used to dissappear! I *mean* disappeared! The definations, expressions and all. Other part of the code would remain intact =P.

[na_th_an]

That's not a QB fault, but a DOS16 fault. There is no protection, so that kind of stuff happens.

[jatos]

I have little problem with qb except on nt based versions of windows, ie xp, 2000 and just haven't tried nt 4 yet....

[adosorken]

NT4 = the most stable of all NT versions after installing the final SP. Of course...you better hope you have an IE download ready-to-go before installing the OS, because it comes with Internet Explorer 2.0 installed, which is incompatible with Windows Update. As far as the MSDOS VM, I have no idea how good it is but I imagine it's probably quite limited.

[Spotted Cheetah]

"Some variables disappearing" - yes, that appeared for me too, but in the reality the
code is not being modified. After hitting ENTER, or altering somehow it, the disappeared
part appears again. So this was a so little problem that i almost not noticed it or
taken seriously.


The mouse bug of QB: If it should really not exist then every computer has the same bug
around us. I had tried it with two computers, four mouses from all common types, two
different mouse drivers, and both DOS and Windows (3.1 and 95) already and it existed on
all of these configurations. Not only with my current copy of QB, it appeared in 4.0 too,
and an another copy of QB4.5 which i got from a completely different place to my current
one. The bug should appear after running a program completely randomly: once it happened
that the mouse stuck after the first RUN, but sometimes it is possible to test a code 40
times flawlessly.

Now i think it will not bother me any more as my program's memory need grew out of the
amount of memory supported by the IDE, so i can not run it in it (It is annoying too that
QB's IDE eats so much memory. I have got 619Kb free at startup, but in the IDE i only can
allocate at about 320Kb for my program).

To make that bug appear load something (i think it more likes to start when running
bigger codes, but i am not sure), and hit RUN, and try to move the mouse after getting
back to the IDE. Once you will not be able to pull it down from the upper - left
corner... And possibly the left button stuck too to prevent doing anything any more...


The function bug seems to exist only when using functions without type prefixes (relying
on DEFINT). After i got used to use them this bug gone, and never appeared again. But
try it, pick a bigger program, and remove the type prefixes from the name of the
functions (relying on an appropriate DEF), then if the bug not appears, remove from it's
parameters too. It should start appearing once.


The case of "program is too big" never annoyed me: if someone creates so big program
then he or she has asked for it. Almost all program can be optimized to fit in that
limit what QB has (To give an example: I had a program which reached the limit at
Version 1.6, but i could keep it increasing to V 1.9 with many addition just by
optimizing the already done parts. I was so succesful in it that the EXE of the program
is now "only" 124Kb when the maximum was 131Kb with much less functionality. So i will
have to find out something what fills that 7Kb of "waste" ).


But when the variables start to not add together... Then it is something more annoying
than when Windows thinks that it is the time for a real - good one - day - reinstall.
You can reinstall Windows in an one - day work, but when you have 80Kb of source code
where you can not imagine what started to fail... This is something what really can make
someone pulling out the plug and never thinking about programming any more


(No, it is not me who will stop as i found all the things failing in my codes already.
It was not an easy work, but i could finish with it. It is the time for Stage 5...)

[TheBigBasicQ]

Poor cheetah =(. Lemme pat you =P.