How is QB64 written?

[Tim]

How is QB64 written? What coding language is used? And is it always the same one?

[SpriggsySpriggs]

The backend is written in C++ but the majority of the IDE is written in QB64 itself. Galleon basically used C++ until he could create something that could write itself.

[Tim]

The backend is written in C++ but the majority of the IDE is written in QB64 itself. Galleon basically used C++ until he could create something that could write itself.

So, any and all new features are written in QB64, then?

[SpriggsySpriggs]

Well, no. Not everything. It depends on what the feature is and how it would be best implemented.

[SMcNeill]

QB64 is a multi-language software.   What QB64 and QB64PE both do, is they take BAS-code, then translate it to C-code, where a c-compiler then compiles it to a working executable.

For almost all of the BAS handling, we tend to use QB64.bas which you can find in the /source folder.  This is the code which makes our IDE and which we use to enter our program with.  It does the syntax checking, formatting, and all such things for us.  It all does the translation process for us, which processes those BAS commands that you enter, and turns them into C-commands.

libqb.cpp and all the rest of QB64 contains the c-code which holds the libraries, routines, and such that actually compiles.  They're located inside the internal/c folder, and the gcc compiler can be found one subfolder deeper than them, in the internal/c/compiler folder.

So the workflow is basically:

source/qb64pe.exe <-- enter your program here.  It translates it to C-code.

internal/c/qbx.cpp  <-- this is the actual entry point where the C-code exists (what you write is basically #INCLUDEd in it), which we compile when you hit F5 in the IDE.

internal/c/compiler <-- and here is where the compiler/linker, and all exists which compiles that completed C-code into the executable for you.

[Tim]

QB64 is a multi-language software.   What QB64 and QB64PE both do, is they take BAS-code, then translate it to C-code, where a c-compiler then compiles it to a working executable.

For almost all of the BAS handling, we tend to use QB64.bas which you can find in the /source folder.  This is the code which makes our IDE and which we use to enter our program with.  It does the syntax checking, formatting, and all such things for us.  It all does the translation process for us, which processes those BAS commands that you enter, and turns them into C-commands.

libqb.cpp and all the rest of QB64 contains the c-code which holds the libraries, routines, and such that actually compiles.  They're located inside the internal/c folder, and the gcc compiler can be found one subfolder deeper than them, in the internal/c/compiler folder.

So the workflow is basically:

source/qb64pe.exe <-- enter your program here.  It translates it to C-code.

internal/c/qbx.cpp  <-- this is the actual entry point where the C-code exists (what you write is basically #INCLUDEd in it), which we compile when you hit F5 in the IDE.

internal/c/compiler <-- and here is where the compiler/linker, and all exists which compiles that completed C-code into the executable for you.

So, would it be helpful to learn C in order to better understand and/or contribute to QB64PE?

[TDarcos]

How is QB64 written? What coding language is used? And is it always the same one?

The backend is written in C++ but the majority of the IDE is written in QB64 itself. Galleon basically used C++ until he could create something that could write itself.

This is extremely common in programming language development. This solves the "chicken and egg" problem. (How do you get the "chicken" - i.e. the compiler - to produce the "eggs" - i.e. the executable programs, when you don't have the chicken in the first place?) When you don't have a compiler to compile the language, there are four possible solutions:

1.  On a different source environment (different processor and/or operating system) that does have a compiler for that language, you write the compiler to be able to compile itself, then once it works, you transfer the executable it creates to the target computer environment. All further improvements to the compiler can now be written using that compiler. (This is how the first compiler for a brand-new language has to be written.)
   
2. On the same or a different environment, you use some other language to write the compiler. It really does not have to be complicated, it just has to have enough features to be able to compile a compiler written in the desired language, that can also compile itself. In effect, the compiler has to be written twice, once in the other language, and then itself. Given this to be the case, the first compiler written in the other language is really only intended to be used once, to compile the compiler that can compile itself. That program can be thrown away, as, in the previous example, further improvements to the new compiler can now be written using that compiler. (This was the method Nicklaus Worth used to create the first Pascal compiler, by writing it in Fortran.)
   
3. The starting compiler in the second example is the compiler, it is not rewritten in the desired language. (This is how the Gnu Pascal Compiler operates. It is a program written in C/C++ which "compiles" Pascal code into C.)
   
4. Some combination of the above. (QB64/QB64pe use this method.)
   

Before there were other programming languages, compilers were written using assembly language, using the 3rd method above. Then C and other languages were developed, and now people almost always use a high-level language to write a compiler.

So, any and all new features are written in QB64, then?

Well, no. Not everything. It depends on what the feature is and how it would be best implemented.

It also depends on the language. Some languages are capable of creating the entire executable. Others, like QB64/QB64pe are what are called "transpilers." A transpiler takes code in one language, and translates it into another language. The GNU Pascal compiler is also a transpiler. It does provide one advantage over a straight compiler: if the target language is sufficient to express every feature of the language, it becomes machine and/or operating system independent. This is why QB64(pe) can be used on Windows, Linux, and Mac.

libqb.cpp and all the rest of QB64 contains the c-code which holds the libraries, routines, and such that actually compiles.  They're located inside the internal/c folder, and the gcc compiler can be found one subfolder deeper than them, in the internal/c/compiler folder.

Actually, it's not just the C/C++ compiler, it's the entire Gnu toolchain (which parts of it the C compiler needs anyway.) It includes:

• The C/C++ compiler
  
• The Gnu assembler
  
• The Gnu linker
  
• The Gnu archiver
  
• The Gnu Fortran compiler
  
• Several tools related to object management and debugging
  
• The MinGW environment, which is duplicating many utilities already in with the C compiler.
  

The entire tool chain, libraries, include files, excluding anything related to QB64pe and its supporting files, is about 650 meg. But hey, disk space is cheap these days.

[TDarcos]

So, would it be helpful to learn C in order to better understand and/or contribute to QB64PE?

Not necessarily, unless you want QB64pe to have some other feature that is not capable of being handled by existing code and which you're unable to sweet talk, err I mean cajole, someone currently working on the program to put it in. If you want to get better as a programmer, read programs. Lots of them. I have, and I still do; there is no such thing as learning "too much." And I've been writing programs since I first learned Basic, oh, over 45 years ago. You could take a look at QB64pe.bas; it's located in the source folder in the folder where QB64pe is installed. But be advised, compilers can be very complex. Or look at some archives of Quick Basic software and examine it. My own collection of Basic language source code, mostly in zip files, is about 8.5 GB, over 60,000 files. I have a lot more reading to do...

[Tim]

Thank you, everyone, for the answers. Still learning here. But never bored.

[TDarcos]

Thank you, everyone, for the answers. Still learning here. But never bored.

As I said - or maybe just implied - I'm still learning too, and I've been writing programs for over 45 years. And I'm almost never bored, except maybe when my computer has a fault, or the operating system does, or the compiler does, or... In which case, I can't use my computer, then I'm only bored until the withdrawal symptoms kick in...