Looking for former QBasic people to visit the qb64.net site.

Cyperium · Post by **Cyperium** » May 01, 2011 13:50

I will try to adress everyone here; first let me point out that QB64 is NOT a sinking ship :) I'm sorry if I portraited it to be. It has a very active community, and even if we are only 50 active users there is plenty of discussion, the reason I speak out here is because I think we need some fresh air, some new ideas. I realise that it might sting in the eye for some that I post this in a FB forum, but the QB scene isn't that active elsewhere (so where should I go? QB45.com has about one post every two days, Network54 is a bit more active but still not by much)...

I think it's good to have a discussion about BASIC no matter what language you use, perhaps we need to create a site where any language can be discussed? I don't know, It makes little sense to have a QB64 section on FreeBasic, I realise that, it makes little sense to have a FreeBasic section on QB64 too, but I think that the communities need to get together somehow.

There are some hostility against FreeBasic on the QB64 forums, but there's also plenty of support. Most people in the QB64 community will agree that FreeBasic was a good thing for QB, many of us have also begun in FreeBasic but when it "derailed" from the QB support and divided itself into many then many of us just lost interest. From time to time I try FreeBasic, but as I have many projects that depends on accurate QB emulation then I just can't extend on them in FreeBasic.

I'll finish off by answering to the concerns of fxm.

The IDE in QB64 allows more than 25 lines and more than 80 rows, you can set the size in Options.

It can't be run in DOS but does emulate some DOS behaviour (POKE/PEEK, INP/OUT, and some interrupts), the DOS compatibility isn't finished though as it isn't judged a high priority at the moment.

Compilation time is improving with every release and two interpreters are developed that will enable testing with no compilation time.

Execution speed will also be better, Galleon haven't had speed in mind when developing QB64, but he says that there is much to do that will improve speed.

EXE files are getting smaller and Galleon will (in the future) make it only use the DLL files it actually needs.

Thanks fxm for the valid points, as you can see they are all being addressed.

I hope that this can be a starting point for mutual understanding, big brother :)

Post by **fxm** » May 01, 2011 14:11

Cyperium wrote:The IDE in QB64 allows more than 25 lines and more than 80 rows, you can set the size in Options.

Ok, I didn't see (excuse me).

Cyperium wrote:Execution speed will also be better, Galleon haven't had speed in mind when developing QB64, but he says that there is much to do that will improve speed.

From a very rustic example : factor = 2.5

Cyperium wrote:EXE files are getting smaller and Galleon will (in the future) make it only use the DLL files it actually needs.

Very small program:
- Compiled with FreeBasic => EXE: 39kb
- Compiled with QB64 => EXE: 501kb + DLLsssssss

Cyperium · Post by **Cyperium** » May 01, 2011 15:35

Very small program:
- Compiled with FreeBasic => EXE: 39kb
- Compiled with QB64 => EXE: 501kb + DLLsssssss

I know, QB64 has a big overhead (or what you call it) but as the size of the exe increases on both FreeBasic and QB64 the difference decreases. I might add that size isn't too much of a problem on modern computers.

The DLLs are needed for SDL mostly (it's cross-platform so it's a good thing in that regard), I don't know if we ever can get rid of them, or at least if we can embed them within the .exe somehow (leading to a bigger exe but being stand-alone), at least the option would be great.

I'm not trying to convey anyone that QB64 hasn't got issues, FB and QB64 are different after all, at some places QB64 is stronger and at some places FB is stronger.

rolliebollocks · Post by **rolliebollocks** » May 01, 2011 15:59

I'm not trying to convey anyone that QB64 hasn't got issues, FB and QB64 are different after all, at some places QB64 is stronger and at some places FB is stronger.

The development strategy over here has always been to be the next logical step in the evolution of QB. That is to say, by the time we have a 1.0 release, there will be full OO support including inheritance, which is already implemented, and later virtual functions and polymorphism.

The fact is that the way in which QB64 outshines FB is a way that will only appeal to ex-QB users hoping for a certain sense of "purity". This means that your only draw will be an increasingly dwindling number of ex-QB users.

FB on the other hand is a major draw for teachers teaching beginning programming to college and highschool students because you don't have to unlearn any bad habits that you would pick up in the a procedural programming language, and because of syntactical elegance and usefullness and all the other reasons aforementioned.

Post by **fxm** » May 01, 2011 16:10

Cyperium wrote:The DLLs are needed for SDL mostly (it's cross-platform so it's a good thing in that regard), I don't know if we ever can get rid of them, or at least if we can embed them within the .exe somehow (leading to a bigger exe but being stand-alone), at least the option would be great.

Yes, it wouldl be more convenient to embed claimed DLLs in the .exe, because for a simple program of calculation + Print, the .exe requests 8 DLLs, but one is big (libstdc++-6.dll: 5Mb), and the 8 (6.5Mb) will be repeated for each .exe!

Coolman · Post by **Coolman** » May 01, 2011 18:25

I tested qb64 There are a few times, I found many disadvantages:

- The size of the programs is too large compared to FreeBasic, or BCX ...
- it is necessary to distribute many dlls ...
- the compilation is odd, she generates C files impossible to read clearly in a temporary folder, the program source is connected and has a runtime compiled exe ...
- I think FreeBasic programs or BCX GENERATE fastest performance but I have not really tested at this level ...
- there is no gui (windows) stabilized while in FreeBasic has several ...

benefits:

- qb64 seems to be able to allow a development platform, but I have not tested the Linux version which I think is behind the windows version ...
- compatibility QuickBasic can recover old programs instead of totally rewrite in another language ...

ps: I tried for some time to convince the interest of compiling a static qb64 forum (see here):

http://www.qb64.net/forum/index.php?topic=3175.0

but I did not help at this level, it said, after my test, it is possible, in addition to gcc, the linkage is smart since the size of exe files generated by using only the functions the library, so the file size generation is much more reasonable ...
alas I do not really have time to continue my tests, it said the project deserves to be closely monitored ...

angros47 · Post by **angros47** » May 01, 2011 18:37

Maybe, we could define a "minimal common basic"; any program written in it should be able to compile under freebasic (lang qb), under qb64, and under original qb45 (if memory allows it).

So:
- first line should be "'Lang qb" (to be able to compile on freebasic)
- no scalars and arrays with the same name (fb limit)
- no oop (qbasic and qb64 limit)
- no external libraries (managed in different ways in qb64 and freebasic)

and so on.

Any program that follows these lines, could be declared "minimal common basic compliant".

Plasma · Post by **Plasma** » May 02, 2011 2:39

While we're on the subject of QB64...why is it called that?! It is not 64-bit and it does not produce 64-bit executables. It should be called QB32.

1000101 · Post by **1000101** » May 02, 2011 3:00

Considering I abandoned qb45 for vbdos and I abandoned that for several years for other languages until fb, why would I want a windows compatible version of something I stopped using over a decade ago? Maybe I can buy an ox and plow instead of a tractor if I became a farmer too.

More likely the reason I don't/won't use qb64 is that it is too busy trying to emulate deprecated hardware and too busy trying to support/re-enforce bad programming practices to be seen (in my eyes) as anything more then someones, "I did it because I could."

1000101 · Post by **1000101** » May 02, 2011 3:22

Cyperium wrote:I might add that size isn't too much of a problem on modern computers.

Data set sizes are irrelevant to execution speed except for cache misses on non-sequential data however, executable sizes are still very important. The code cache in CPU's is still very tiny and hasn't increased significantly in 15 years. This means that programs which can fit within the entire cache or can maintain large sections in the cache will run at an order of magnitude faster then programs which have multiple branches or large portions of their code which lie outside of the cache.

Microsoft and Apple lie to you. Machine code size *is* important (smaller is better).

kiyotewolf · Post by **kiyotewolf** » May 02, 2011 3:32

Get to my question!
Android phones and QB64!
Also, can FB run on an Android phone?

~Kiyote!

ME NEXT! O3O

marcov · Post by **marcov** » May 02, 2011 7:32

kiyotewolf wrote: I am VERY very VERY interested in QB64 for future development, if it can be used on Android phones.

Android is a difficult target, so if a forum search doesn't turn up anything, you can safely assume it is not supported. FB or QB.

(and I think neither do atm)

aurelVZAB · Post by **aurelVZAB** » May 02, 2011 8:04

I think that you ask on wrong place.
Im also member on qb64 forum but i simply dont know what to ask or post
on this very closed comunity forum.
(member cannot see who is online...?????)
And i must be honest im not interested for qb64 programming.

kiyotewolf · Post by **kiyotewolf** » May 02, 2011 8:18

"Android is a difficult target"

I thought that is was just another variant of Linux. ? . .. ?

~Kiyote!

marcov · Post by **marcov** » May 02, 2011 11:49

kiyotewolf wrote:"Android is a difficult target"
I thought that is was just another variant of Linux. ? . .. ?

That is both true and false, depending on how much variation you will allow :-)

Older Android will only execute Java apps. Only the more recent (and afaik largely unreleased) versions allow to directly start native apps, but that is also a not very unixy environment.

Get used to Mobile being pain. Be it Iphone, Android or whatever. These targets are essentially walled gardens.