Why must I continue to use FBC ?

[Theunis Jansen]

I have a couple of hundred programs in QB4.5. So far almost everyone gives me a duplicate definitions or other error. These programs all run perfectly in QB4.5 or compiled QB4.5 stand-alone programs.
I wrote my own Quick Library for the mouse and have WavPlay for music and don't really require anything else except maybe to play *.OGG and *.MP3 files.
FBC seems to have become more Pascal like than BASIC and a lot of extra coding is required especially when DIM is involved. The ease and simplicity of QB4.5 has vanished.
I use Randomize TIMER and then RND in a number of my programs and sometimes I have to sit and wait for the Additions or Subtraction problem to materialize. In QB4.5 they are there instantly.

So could someone please try to convince me to continue using FBC. I simply cannot rewrite portions of hundreds of files just to get a program compiled to 32-bit.

Or can I go ahead and try to modify FBC to only use the QB/Basic compatibility ?
and throw the rest out ?
Or has someone already done this ?
***********************************
EDIT 14:00 SAT. 2010-11-08 :There have been things said bordering on flames, which I expected and accept because I asked for it.
But please read all the posts to the end before responding to this initial post. Thank you
***********************************

[vdecampo]

Or can I go ahead and try to modify FBC to only use the QB/Basic compatibility ?
and throw the rest out ?
Or has someone already done this ?

Yes, it is called -lang qb. In that mode FBC is the most compatible with QB.

-Vince

[bulrush]

2 weeks ago I was using QB64 (supports Quickbasic but also has its own stuff too.) I like Freebasic much better. It has many tools that make a programmer's job much easier, like the WITH statement, and Regular expressions! As a Perl programmer, I use regex a lot when processing text files.

QB64 is good, but is not mature enough for me. QB64 minimum EXE size is 900K. FB min EXE size is 90k. A difference of 10x. In a time of cheap storage and high speed internet, this is not a big problem from those perspectives, but I still like the efficient EXE files of FB. Plus with QB64 you must distribute 7.9mb of DLL files to be held in the same dir as your EXE file. That's a lot!

Plus FB has a debugger, and QB64 does not.

[Theunis Jansen]

@Bulrush
I tried QB64 and did not like it so much because of the size of the exe and the dependencies. The *.DLL and *.SO hell is not for me and I don't have to make sure every dependency is included with the distribution.
I want my programs to be more independent of the operating systems DLL's.
I am an ancient and only use QB4.5 with a few things added from fblite as the occasion demands.

@Vince
Hi Vince I am back. I converted one or two short programs to Screen 18 and had to almost rewrite 25 to 30% when it came to screen positions apart from changing so many duplicated definitions and rewriting pieces where keywords are no longer supported. Take $. Without the suffix it is Pascal type programming with it it is QB.
I do use -lang qb and -lang fblite. Both give the same errors and of course the Screen 7/13 problems, when the latest Nvidia cards are in use, are still there hence my SCREEN 18 attempts.

I am actually talking about the compiler itself when I say throw out the - lang- FB and only retain the QB and possibly the fblite portions of the compiler and if two words mean the same thing throw out the one without the $ suffix. i.e Print$ vs Print etc.
The question is may I change the FBC source. I will probably make a mess of it but I can try, Or has somebody already done so.
With the type of programs I write it means I can still use QB4.5 to write them. Do test runs, set breakpoints, do step one line debugging, add watchpoints, continue from the last breakpoint to the next etc.

[vdecampo]

You are free to branch the source code and make any mods you like.
-Vince

[Theunis Jansen]

Thanks Vince. I will give it a try.

If it is still regarded as FBC I should be safe, because on some of the files it says it is part of the fbc compiler and may not be reused without approval. I naturally wont give it a new name if I succeed but will probably have to give it another version number which will have to include QB or Fblite. Say FBC_Lite, FBC_QBlite ?

This question is more to a moderator to see what they will say.

[bulrush]

I do use -lang qb and -lang fblite. Both give the same errors and of course the Screen 7/13 problems, when the latest Nvidia cards are in use, are still there hence my SCREEN 18 attempts.

So FB gives errors using #lang qb where Quickbasic does not? I think the actual syntax is with double quotes: #lang "qb".

So that means FB is not totally QB compatible.

[dani.user]

Programming evolves over the years.
Did you check if there actually is a duplicate definition in that code and try to fix it? QB might be just ignoring it.

[Theunis Jansen]

@Bulrush and Dani.user

I set the language, processor and etc in the FBide and not in the program, it does not matter where you set it unless you compile from the IDE (DOS prompt in the old language)
FBC is about 98-99% compatible with QB, but that 1-2% is where some critical things were changed or left out.
If you write a new program there are normally no problems if you follow the FB conventions.

The problem with Screen 7 and 13 is also found with QB4.5. These screens sizes are no longer supported by the new nVidia cards. You can check it up on previous posts about them. (The easiest way to find them is click on my profile and then say show all posts by me.) Although using SEARCH may be a better option.

If you check the Help file in FBide you will see the differences. With SHELL in QB you could pass variables to program being SHELLed. This cannot be done in FBC.
QB allows you to use DIM NIN$(50) and DIM NIN() but in FBC it says it is a duplicate definition. Even if you use REDIM NIN$(100) to redimension the NIN$() it gives an error. You cannot use NIN$ and NIN in one program it gets thrown out as an error.

There are absolutely no duplicate definitions in my QB4.5 programs, but because of FBC conventions some definitions are regarded as duplicated. QB4.5 will if you make one, point it out when you try to run in. It does not ignore errors.

Since 1988 I wrote and rewrote all of my programs using QB4.5. Before that I used Basic, BasicA, Sharp Basic and GWBasic. I still have the original QB4.5 floppy disks. Which I backed up on CD's.

Screen 7 and 13 are older programs and if a new program is written I do not recommend their use. Screen 18 to 21 seems the best choice.

QB64 overcomes the Screen 7 and 13 problems of tiny screens that cannot be maximized, but I would rather use DOSBOX than compile my programs with QB64. My previous post says why.

[vdecampo]

QB allows you to use DIM NIN$(50) and DIM NIN() but in FBC it says it is a duplicate definition.

Can't a simple Search-and-Replace fix that problem?

-Vince

[rolliebollocks]

There's even an option in the IDE to do it. And the correct syntax then would be REDIM.

[Theunis Jansen]

I have quite a number of variables to rename and some of my programs are two to three *.bas programs. Search and replace it's easier with qb4.5. But as I indicated it is just part of my problem I use screen 0 and a number of screen 7 programs. So it is a lot of rewriting to do because of the Screen 7 and 13 problem. Rollie you and Vince will recall I cried crocodile tears because of all the changes with regard to LOCATE, DRAW strings positions etc I had to make and will have to make because of screen 7 and 13 which is not supported by the newer nVidia cards. Then I have the SHELL bit which I have to change in a number of programs to write globals to a file and then read them in by the SHELLed program - Globals are bad - discussion. My earlier programs weren't written like that. With all the changes to my programs it will probably take six to twelve months at the rate I am now going. Rollie you may recall that I said I am going to do some reading and investigations of my own and will be gone for about a month.
This past month with virtual rewrites of programs has totally frustrated me. I have tried to speed up the RND in FBC but to no avail to look at a screen for five seconds before the addition etc exercise appears gives me the runs. I define keys but now must replace them with the kludge that Daniel (my cousin) gave me. Remember my post about KEY. These definitions are not in most cases the same so I can't use it as an INCLUDE file. I do use it as Merge where I want it but it only saves a bit of typing. I use GOSUB very sparingly but I have had to change a few to a SUB. It is not really necessary but it is neater and more structured. Search and replace then takes care of the change to replace GOSUB xxx with the new SUB's name. All time consuming and not very productive.

I think I have now reached the stage where I am going to sit and play old games, Build some shockwave Ion guns, High frequency generators and combine them with the ion guns to switch off humans. (Knock them out) Further investigate my thoughts on using a 7000 rpm crashed hard drive motor to drive a permanent magnet alternator. Install an alternator onto my exercise bike to charge batteries for standby lighting, Start using my HAM equipment again, I have so many other things to do, even practice some hypnosis again. Which just means give up programming. and return to one of my other hobbies which I have neglected, I may even start writing poems again.
Sorry Counting Pine I am now rambling and this is a FBC help forum not a shoulder to cry on. Just say edit and I will remove my ramblings.

[voodooattack]

Stop whining and rewrite your code.

[rolliebollocks]

@Voodooattack

Good to see you back. And agreed.

[Theunis Jansen]

@Voodooattack and Rolliebollocks

Sis on you.
You should be helping not beating me with a stick.

So are you going to give me some pointers about the FBC source code to make an offshoot to get it closer to the ease and simplicity of QB4.5 BASIC again.
Progress is supposed to make things easier and less time wasting
not more difficult and to me more convoluted extra coding.