Freebasic 1.20.0 Development

[exagonx]

I was not suggesting to change that, my suggestion was about how to handle symbol collisions in qb mode, and only in qb mode.

Now I understand, and yes indeed it would be useful.

By the way, GwBasic and BASICA were interpreted languages, and a compiler was available. QB 4.5 was both interpreted and compiled, and there were situations where the compiled and the interpreted mode returned different results (http://www.petesqbsite.com/phpBB3/viewtopic.php?p=39013)

As for QB 4.5 in 1998 I felt like pulling my nails out when I saw that the software in the IDE worked perfectly when the .exe file was generated I had to take stomach acid blockers, I had to write a software step by step and check each function by compiling it and generating the executable file each time.

In any case, many software would have to be rewritten because at the time many programmers wrote code without considering that in the future processors would become faster, some games, for example, need to add code that controls the speed of execution.

[coderJeff]

I really don't think that preserving legacy code was ever a goal of the project. I think the addition of dialects was a reaction to complaints about directions fb was taking. But then a faction of the fb/qb community split off to go do qb64 anyway (which they did a good job with compatibility and marketing a product, even though the source is horrendous and the language is a mess).

For interest, here's a couple of old posts:
- by voodooattack
- by yours truly

My question is: since such a feature should affect only -lang QB, and not other mode, can it be implemented with some solution like internally converting the name of any symbol used as array name, adding some prefix? Like, if the symbol "A" is encountered, and used as variable, compiler should check if it has an index, and in case process it as "_ARRAY_A" or something similar? It would avoid any conflict, since in QB code the underscore was never used in variable names.

I spent a day to estimate the amount of work needed. I think is a lot. I would guess like more than 80 hours but likely less than 200.

The internal / external naming of things is a of course a concern and probably needs some work, but the real effort is going through the 100's of places in the compiler where variables and arrays are used and writing special handling just for qb dialect; then proving that it all works.

This is just scratching the surface, look at the kind of rubbish that is allowed in qb(tm):

Code: Select all

DEFSNG A-Z
a(1) = 1   '' implicit array with float type due DEFSNG
a = 1      '' implied suffix ! due DEFSNG
PRINT UBOUND(a, a)
''           |  |
''           |  + scaler
''           + array

a% = 2     '' different type (suffix) makes this a new variable
a%(1) = 3  '' ditto for arrays

DEFINT A-Z '' implied suffix is now integer

PRINT a    '' a is now a%
PRINT a(1) '' a(1) is now a%(1)
PRINT

[coderJeff]

Some algorithms are written in spaghetti code, maybe the author themselves cannot figure how they work anymore (it's what happened in the game Entombed, https://en.wikipedia.org/wiki/Entombed_(Atari_2600)), but they work.

Interesting, though seems to me the author of the algorithm knew how it worked even if the programmer didn't.

[angros47]

I really don't think that preserving legacy code was ever a goal of the project. I think the addition of dialects was a reaction to complaints about directions fb was taking. But then a faction of the fb/qb community split off to go do qb64 anyway (which they did a good job with compatibility and marketing a product, even though the source is horrendous and the language is a mess).

As far as I know, the goals were defined as the project was going on. And FreeBASIC went far beyond its original goals. As in many open source projects, several people joined, with different goals, and each one tried to pull FreeBASIC toward their own goals: some wanted to preserve retrocompatibility, others wanted to move forward, and dialects were introduced to make everyone happy (I remember the discussion that brought to introduce dialects: it was about a change made by V1ctor, to disallow GOSUB inside subroutines, and allow RETURN to be used to return a value from subroutine itself, instead)

I agree with you about QB64: it is a miracle it works at all, and it wastes a lot of resources (for example, if I recall correctly, it supported direct mode, but each time you entered a command directly it created a C++ code, invoked the GCC compiler, and ran it. It supports COMMON SHARED between multiple programs, but implements it by saving the variables to a temporary file): it uses a lot of inefficient solution, with the excuse "modern computers are fast enough": but what is the point of a faster computer if you clog it to slow it down like 40 years ago?

Also, the attempt to maintain complete compatibility with QB4.5 has actually killed any attempt to do anything creative with original QB45, even when 16 bit computing wasn't totally dead yet: in fact, the few people who still used QB45 aimed to keep their code compatible with QB64, too, and that meant giving up on any external library. And this tendency is happening again: there is a separate project, QBJS (for web pages), that aims to be compatible with QB64, and this means that now developers who use QB64 have to care about not breaking compatibility with it, too; FreeBASIC doesn't have that issue, because the equivalent feature is achieved through the Emscripten target, so the compiler used to produce web pages is the same, and any change will apply to it, too.

I am actually surprised by the success of QB64, I guess it has marketed better than FreeBASIC

I spent a day to estimate the amount of work needed. I think is a lot. I would guess like more than 80 hours but likely less than 200.

The internal / external naming of things is a of course a concern and probably needs some work, but the real effort is going through the 100's of places in the compiler where variables and arrays are used and writing special handling just for qb dialect; then proving that it all works.

I appreciate that, I had no idea it was so complicated. I agree it is not a high priority, but I thought it were easier to implement.
Thank you for your answer

[srvaldez]

hello coderJeff and developers of FB
in windows 11 the default console is the new terminal, while you can change the settings so that conhost will be used it would be good to have the output to the terminal work properly
the problem is that the output is not buffered, when you print many lines only the last lines are visible, you can only scroll up about 5 lines
for example the following code prints 100 lines but only the bottom portion is visible, the rest is lost.
there probably are more problems like cursor positioning, though I did not test for that

Code: Select all

for i as long=1 to 100
	? "line ";i
next

for example you can execute the Dir command of a directory with many files and you can scroll up to the beginning of the list without problem, so something is different in the terminal
[edit]
this C program does the same, and while I can scroll up to the top there's a problem

Code: Select all

#include <stdio.h>
int main(void)
{
	int i;
	for (i=1; i<=100;i++){
		printf("%s %d\n","line ",i);
	}
	return 0;
}

line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
line 12
line 13
line 14
line 15
line 16
line 17
line 18
line 19
line 20
line 21
line 22
line 23
line 24
line 25
line 26
line 27
line 28
line 29
line 30













e 44
line 45

[srvaldez]

I compiled the C code from the msys2 terminal and then launched the windows terminal to execute the program, I can scroll all the way to the top,
don't know if it's the C version or something else
[edit]
I just compile the FB program from the msys2 terminal and when run from the windows terminal I can scroll all the way to the top, my guess is that it's not a problem with FB but with certain libraries
edit2
setting Geany to use the FB compiler that's in the msys2 tool chain and then compiling the FB program does not work, I can not scroll up at all

[coderJeff]

Win10 keeps asking me to install Win11 - I haven't brought myself to pull the trigger yet ...

windows terminal is this windows terminal? : https://github.com/microsoft/terminal/issues

[srvaldez]

I think that is the same terminal, looking at all the issues reported makes me think that the terminal is beta at best, I will stick with conhost until they fix all the bugs
[edit]
the only thing remaining that puzzles me is that why an FB program compiled from the msys2 terminal and launched from the windows terminal behaves ok, but the same program compiled with the FB compiler that's in the msys2 toolchain from the windows terminal does not work as expected

[dodicat]

I thought that screen 0 was redundant in win 11.
But it has it's uses.

Code: Select all

#include "crt.bi"
screen 0
for i as long=1 to 100
    printf("%s" !"%d\n","line ",i)
next
sleep
 

...

Code: Select all

line 1
line 2
line 3
line 4
line 5
line 6
line 7
line 8
line 9
line 10
line 11
line 12
line 13
line 14
line 15
line 16
line 17
line 18
line 19
line 20
line 21
line 22
line 23
line 24
line 25
line 26
line 27
line 28
line 29
line 30
line 31
line 32
line 33
line 34
line 35
line 36
line 37
line 38
line 39
line 40
line 41
line 42
line 43
line 44
line 45
line 46
line 47
line 48
line 49
line 50
line 51
line 52
line 53
line 54
line 55
line 56
line 57
line 58
line 59
line 60
line 61
line 62
line 63
line 64
line 65
line 66
line 67
line 68
line 69
line 70
line 71
line 72
line 73
line 74
line 75
line 76
line 77
line 78
line 79
line 80
line 81
line 82
line 83
line 84
line 85
line 86
line 87
line 88
line 89
line 90
line 91
line 92
line 93
line 94
line 95
line 96
line 97
line 98
line 99
line 100
 

[srvaldez]

thanks dodicat
your code works with the new win 11 terminal but not in the legacy console, also you must use printf and not the FB native print, so there might be a problem with FB ?

[adeyblue]

Win10 keeps asking me to install Win11 - I haven't brought myself to pull the trigger yet ...

windows terminal is this windows terminal? : https://github.com/microsoft/terminal/issues

You can install it on Win10 via the store, but I think up-to-date Win10 has it installed already. You just have to purposefully run WindowsTerminal.exe to use it.
https://apps.microsoft.com/store/detail ... 0DX20HK701

Looking at the issue tracker, the four problem spots are
ReadConsoleOutput (not going to fix)
WriteConsoleOutput (has problems)
SetConsoleWindowSize /
SetConsoleBufferSize (currently no support for changing those)

rtlib uses all of those.

Perhaps the easiest way, though not the best since terminal isn't going to go away, is to do what UEZ is doing and add a check to rtlib startup to see if its an exe running under terminal and then relaunch the app under the old shell if it is. Won't fix any dlls that do problematic things but other issues seem workaroundable

[dodicat]

Even with legacy console set, -s gui switch causes a windows error message.
Is it my Norton antivirus doing this, it came with the computer, I have never used Norton before.
Before I try switching it off, could somebody test.

Code: Select all

#cmdline "-s gui"

screen 19
print "hello"
sleep 

[srvaldez]

dodicat, it works for me with no problems

[dodicat]

Thanks srvaldez.
I thought it might have been another win 11 problem, but it is probably Norton antivirus,

[shadow008]

The bug with the windows 11 terminal giving buggy output appears to have been fixed in the windows 11 terminal 1.18 version, see this bug thread:

https://github.com/microsoft/terminal/issues/14512

Consider updating your windows terminal version to 1.18 (or later, depending on when you read this). However, 1.18 is still in pre-release, so you may have to wait until the full release to upgrade without some kind of hassle. I haven't tested if this actually fixes it, I'll get around to trying it sometime in the next few days.