Support Forums > WinFBE - Code Editor and Visual Designer

fumbling first questions

(1/6) > >>

dcouzin:
Hello Forum: I turned to FreeBASIC just two days ago, when my move to 64-bit Windows meant no more NTVDM to run my old QuickBASIC programs.  They're optical design programs written 25 years ago in QB version 3.00, and still useful. What a delight to find the programs could run 5 times faster using the FB compiler instead of QB's, and no more NTVDM and BRUN. 

My two goals:
1. to run the programs as fast as possible.
2. to not have to significantly rewrite the programs.
Do the goals conflict?
 
Paul Squires' latest suite with FreeBASIC-1.06.0 and WinFBE-1.8.7 worked straightaway.  The '-lang qb' option allowed most of my programs to compile after modest changes.  In QB I could name a variable 'X' and also name an array 'X()'.  I could express ≥ interchangeably with '>=' and '=>'.  Etc.  Etc. FreeBASIC-1.06.0 freaks out at these liberties and its error messages barely hint what's wrong.  Traces of guilt helped me to find them.

Without speaking for real programmers, I learned much of QuickBASIC v.3.00 syntax by trial and error.  Whatever the compiler allowed, I kept doing.  With time I should learn the new syntax allowed by the '-lang qb' option, but I fear that the new compiler will react to some deeper abuses/liberties in my programs that I won't fathom.

First question: do the earlier FreeBASIC compilers have a more tolerant '-lang qb' option than later FreeBASIC compilers?  Has the FreeBASIC principle of supporting QuickBASIC coding softened over time?

Second question: will the later FreeBASIC compilers provide a speed advantage for my programs?  The programs are just piles of arithmetic and trigonometry, running on a normal Lenovo T480s with Windows 10.

Besides those general questions, I'm mystified by specifics in the FreeBASIC-1.06.0 and WinFBE-1.8.7 combination.  One of my programs compiles and runs fine with build configuration 'Win32 GUI (Release)' and option '-lang qb', but with build configuration 'Win64 GUI (Release)' and option '-lang qb' it compiles only to crash after 2 seconds running.  How can this happen?

Will this forum suit someone who programs, but is not a programmer?

Dennis

Klaas Holland:
Yes Dennis, this forum is a good place for you, because Paul and Jose are experts in helping you.

I'am not a programmer too and did switch from QuickBasic --> PowerBasic --> FireFly/PB --> FireFly/FB,
and I'am still using the same basics.

Paul Squires:

--- Quote from: dcouzin on December 18, 2018, 10:30:06 PM ---Hello Forum: I turned to FreeBASIC just two days ago, when my move to 64-bit Windows meant no more NTVDM to run my old QuickBASIC programs.  They're optical design programs written 25 years ago in QB version 3.00, and still useful. What a delight to find the programs could run 5 times faster using the FB compiler instead of QB's, and no more NTVDM and BRUN. 

--- End quote ---
Hi Dennis - welcome aboard! :)


--- Quote ---My two goals:
1. to run the programs as fast as possible.
2. to not have to significantly rewrite the programs.
Do the goals conflict?

--- End quote ---
As you've noticed, you have had to do some tweaking of your programs. I NEVER use '-lang qb' ever and have dropped any of my old QuickBasic habits long ago (after I switched to PowerBasic). Personally, I would try compiling using '-lang fb' as that is the future of the compiler. Legacy QB compatibility should be frozen at FB 1.05 and stripped out of the compiler for versions after that(but that's my opinion and not widely shared by the greater FB community who have a lot of old QB code). If you ever decide to start using WinFBE's visual designer then it will only create code using -lang fb.
 

--- Quote ---First question: do the earlier FreeBASIC compilers have a more tolerant '-lang qb' option than later FreeBASIC compilers?  Has the FreeBASIC principle of supporting QuickBASIC coding softened over time?

--- End quote ---
If anything, QB support got better with the compilers as time went on. Bugs fixed and quirks in the syntax fixed. My "feeling" is QB support will remain in the compiler but development in the FB syntax has taken over and always be the main area of future development.


--- Quote ---Second question: will the later FreeBASIC compilers provide a speed advantage for my programs?  The programs are just piles of arithmetic and trigonometry, running on a normal Lenovo T480s with Windows 10.

--- End quote ---
Most likely they will especially the 64 bit versions that uses GCC for the compiling backend. Whenever GCC is updated we normally see speed improvements and optimizations. There is an experimental LLVM backend that one day may prove to be even a little faster.


--- Quote ---Besides those general questions, I'm mystified by specifics in the FreeBASIC-1.06.0 and WinFBE-1.8.7 combination.  One of my programs compiles and runs fine with build configuration 'Win32 GUI (Release)' and option '-lang qb', but with build configuration 'Win64 GUI (Release)' and option '-lang qb' it compiles only to crash after 2 seconds running.  How can this happen?

--- End quote ---
32 bit code and 64 bit code can sometimes be a problematic. The most damning area would be if you use the INTEGER variable (I always use LONG just to avoid issues). An INTEGER is 32 bit on 32 bit systems, but is 64 bits on 64 bit operating systems.


--- Quote ---Will this forum suit someone who programs, but is not a programmer?

--- End quote ---
Definitely. I venture to say that the vast majority of us here are not professional programmers. :-)

Johan Klassen:
also, if you decide to convert your QB code to FB, be mindful of the integer type differences
QB Integer ( number% ) – Integer variables are 2 bytes long, FB32 Integer is 4 bytes long - FB64 Integer is 8 bytes long
QB Long Integer ( number& ) -Long Integer variables are 4 bytes long
in FB you can declare an integer like so
Dim as Integer n ' 4 or 8 bytes long
or
Dim as Integer<16> n '2 bytes long, valid sizes are 8, 16, 32 and 64 bits

raymw:
Hi Dennis,

It depends if it is worth the effort for you, but I would consider trying to work out what your largest numbers are likely to be, and chose integers that will just about hold them. e.g, if your largest value is going to be in the hundreds range, then no point in doing calculations with 64 bit integers. If rounding errors are unacceptable, do not use floating point numbers, and so forth. Take this as an opportunity to rewrite your code in freebasic, as Paul suggested. If it is software you developed yourself, and you have the documentation ;-) it may be as easy to rewrite it anyway, from your original specification, instead of trying to convert your existing qb code line for line.

Best wishes,

Ray

Navigation

[0] Message Index

[#] Next page

Go to full version