Hi all, it has been a while since I last logged on here. Funny that the board hasn't changed much; the regulars are still regulars.
Anyway, we've all come across the limitations of QB (4.5) before. What would you like to see in a new compiler? Improved efficiency? Extended capabilities? Compiling for other (eg. win32) platforms?
Hi, welcome back.
I think the big thing that is missing from new QB like compilers is compatability. Most of the ones I've seen take the QB like formula but enhance but none have seem to have done it correctly or justice. I think the secret of QB has been its simplicity but with enough room to expand for those who wish to.
personally, i like it as it is. all i'd like to see different is...
faster
no memory limits
Quote:personally, i like it as it is. all i'd like to see different is...
faster
no memory limits
hifty: agreed
This is something I keep repeating:
No memory limits emans building a 32 bits compiler. That means that the libraries, for example, won't work. That means that you won't have a compiler ready to use to plug yoru QB program and compile it faster and with unlimited memory. That's impossible. New libraries would have to be developed for the new compiler.
Plus, if you wanna escape the dying DOS and get into Windows and/or portable code (Linux, etc...) then the whole programming philosophy has to change. If you wanna code for Windows you need GUI stuff and DLL support, and that will make the language even more different.
So a 100% compatible with QB compiler with the features you demand is not possible.
Why would it be impossible to use the libraries?
The format is known, and last time I checked you could run 16bit apps on a 32bit system.
Well, I'm not too worried about the memory, it can be worked around, but speed, speed, speed.
Why is QB so darn slow? Even compiled.
Quote:No memory limits emans building a 32 bits compiler. That means that the libraries, for example, won't work. That means that you won't have a compiler ready to use to plug yoru QB program and compile it faster and with unlimited memory. That's impossible. New libraries would have to be developed for the new compiler
Not neccesarily. I thought about it, and thought about the qcc covertor, and figured that you could probably just write a qb-c covertor, and instead of trying to covert the libraries write a header for each well known library so instead of trying to use the function included with the library, you simply swith the call over to your other library, like say allegro.
Althought thats not truly a compiler. You could use the same idea(build a library, write a simple header to convert blast/dqb/whatever to it) Downside is youll need to write a header for each lib, and uh, your not truly recompiling the program, so its not 100% compatible, but as long as the program doesnt use inline ASM or anything like that, you can make porting easier.
Quote:Why would it be impossible to use the libraries?
The format is known, and last time I checked you could run 16bit apps on a 32bit system.
In 16bit mode. With the same limitations that you dont want to have, so your back where you started.
16 bit mode is a different art... I like that because programmers have to work carefully. Not like some mads working in 32 bit mode and eating up 100 megs of memory (When they need only 10Mb in reality...).
QB's speed - I can live with it. But that would be very good to have something faster.
I only can not stand one thing: When QB merges all of my DEFINT A-Z with my FUNCTIONs!!!. Before every execution in certain programs i have to rewrite my functions' first lines to work.
If you mean it automatically puts the DEFINT at the top of all your functions, when you want it only in the main procedure...then it's easy to fix. Use QB4MED.
Quote:Not neccesarily. I thought about it, and thought about the qcc covertor, and figured that you could probably just write a qb-c covertor, and instead of trying to covert the libraries write a header for each well known library so instead of trying to use the function included with the library, you simply swith the call over to your other library, like say allegro.
Althought thats not truly a compiler. You could use the same idea(build a library, write a simple header to convert blast/dqb/whatever to it) Downside is youll need to write a header for each lib, and uh, your not truly recompiling the program, so its not 100% compatible, but as long as the program doesnt use inline ASM or anything like that, you can make porting easier.
Sure, but think about it: in 16 bits mode there is no protection, for example. If you get 16 bits C code you can compile it for 32 bits 'cause the compiler takes care not to screw things up. But if you take, for example, DirectQB, a precompiled 16 bits library (binary object code) you'll run into problems.
Plus, to access the VGA video memory you have to get into real mode for a while and then return to PMode. This takes very much time. And I am talking about DOS, in Windows you simply can't access the hardware in that way, you have to use the Window's API or DirectX, so no way you can get RELLIB or DirectQB and run a converter and have them ready for the new compiler.
What I say is that you can write a QB compatible compiler as far as the language is concerned, but you won't get 100% compatibility 'cause the libraries won't work (you can recompile them for windows, but imagine the amount of changes you would have to do in the code).
The best bet is, obviously, have a compiler that uses the same BASIC dialect and provides access to the Windows API. We already have it: VB.