File .exe

[Ryster]

Do dear developers from QB64 intend to improve the program so that the output file .exe is much smaller?. Compilation of the same code with another program gives the result file a few times smaller.

[Raven_Singularity]

What compiler did you try using with better results?

If you want small executable size, I recommend running it through UPX after compilation.

Have you tried adding -O2 to the compile parameters in QB64?

That makes the executable more efficient, not sure if it reduces the executable size much, though.

[FilipeEstima]

Not to complain, as I very much prefer QB64, but is there in the wiki some explanation as to why executables made by QB64 are so much bigger that the ones made by FreeBASIC?

One thing to notice is, although QB64 makes bigger EXEs, they are also much faster than EXEs compiled by FB. I made a very simple program that loads 2 text files, then searches if file 2 (539 KB) contains certain strings that are in file 1 (221 KB). Typically the EXE made by QB64 finishes the job in 2 min 8 sec (1.4 MB) while FreeBASIC-generated EXE takes more than 4 HOURS (103 KB). It's exactly the same program, I only had to add #lang "qb" on the beginning to compile on FB. Is that FB's fault or #lang "qb" is to blame?

[Raven_Singularity]

Reminds me of QuickBASIC v4.5, which was so painfully slow back on my 286, yet had the name "Quick" in the title, lol.  Microsoft loves to miss-name applications.  Microsoft Works (hah!).    After one of my games became too slow to add more features to, I learned Turbo Pascal for DOS and converted my game to it... wow!  I think it ran more than 100 times more quickly.  I had to implement a timer based system to slow it down, at first I just had a loop run between each screen update, but it was counting into the hundreds of millions every screen update and seemed silly.  It blew my mind how inefficient QuickBASIC was compared to Turbo Pascal.

Another prime example would be Unix shell scripting (like DOS batch files) versus a programming language like Python, Perl, or PHP.  After my shell script was taking minutes to finish, I rewrote it with PHP and suddenly it was processing those multi-MB text files in under 0.2 seconds (after the first run with data files cached in RAM; the shell script was always painfully slow).

As for your question of why QB64 EXEs are larger than FreeBASIC's, it is most likely a difference in which libraries are being included in the EXE file.  I know that QB64 1.3 includes several libraries in every EXE file, FreeBASIC probably uses smaller libraries (graphics, sounds, etc.).  Do the FreeBASIC EXEs have any external dependencies?  QB64 EXEs no longer have any.

[Pete]

Development priorities. Rob wanted to advance the capabilities of QB64 over telling the compile what libraries to install, based on the keywords in the code.  The results are the worlds largest print Hello World app! I'm OK with that, because technology has advanced to such a great degree that size just doesn't matter the way it used to. In the old days, you could use switches to tell QuickBasic which libraries to include with a manual compilation. My favorites were O/S/E/X. Wow, I wonder why I still remember that? Anyway, no switches with QB64, either, but seriously, if anyone were so picky as to need the leanest meanest exe then ask yourself, what the hell are you doing programming in a hobby language in the first place?

Pete

[Raven_Singularity]

I would really like to see UPX used automatically on EXE files produced by QB64, or have a checkbox in the settings to enable it.  It reduces the size to 1/4 on my Hello World test.


Example:

Hello_World.bas (0.02 KB)
Hello_World.exe (2031 KB)
Hello_World_UPX.exe (540 KB)

[Ryster]

The code compiled in:

QB64x64 - 1.99 MB
Turbo Pascal - 45.5 kB

This is a chasm.

[SMcNeill]

The code compiled in:

QB64x64 - 1.99 MB
Turbo Pascal - 45.5 kB

This is a chasm.

Why?  We don’t use 1.44 floppies anymore.   When you have GB USB flash drives, a 2MB .exe is nothing.  Most games and program I download and use are hundreds of MBs in size.

[Petr]

I assume that the EXE file in QB64 also includes support for images, sound, and 3D graphics, that is, OpenGL background for graphic and next 2rd party support for sound, even if the compiled program contains just the BEEP command. Because it is so a long time, I assume that it is very difficult to select the necessary pieces and then build an EXE. This is due to the interconnectedness of different subroutines.

[FellippeHeitor]

I assume that the EXE file in QB64 also includes support for images, sound, and 3D graphics, that is, OpenGL background for graphic and next 2rd party support for sound, even if the compiled program contains just the BEEP command. Because it is so a long time, I assume that it is very difficult to select the necessary pieces and then build an EXE. This is due to the interconnectedness of different subroutines.

Development priorities. Rob wanted to advance the capabilities of QB64 over telling the compile what libraries to install, based on the keywords in the code.  The results are the worlds largest print Hello World app! I'm OK with that, because technology has advanced to such a great degree that size just doesn't matter the way it used to. In the old days, you could use switches to tell QuickBasic which libraries to include with a manual compilation. My favorites were O/S/E/X. Wow, I wonder why I still remember that? Anyway, no switches with QB64, either, but seriously, if anyone were so picky as to need the leanest meanest exe then ask yourself, what the hell are you doing programming in a hobby language in the first place?

Pete

Even though our binaries are indeed quite large, they do not pack *all* of the available libraries we ship. QB64 does indeed selectively choose what to add based on what code is compiled (Rob added that ability when switching from SDL - tens of .DLLs to add - to OpenGL - single binary).

You won't get the sound library included if no sound commands are used. Same for fonts. Even some of the graphic overhead can be minimised by creating $CONSOLE:ONLY applications.

You can check how it's done by looking into internal\c\libqb\os\win (lnx, osx - depending on your OS). Depending on your usage, you will find several different files in that folder whose names begin with libqb_1_...

Each of these is a combination of the available libraries packed according to what your programs use. Right now on my folder I have files with these endings: 000000000000.o, 000001000000.o, 100000010100.o - these have been used to compile (i) a program with no dependencies (ii) a program with only *one* dependency and (iii) a program with *three* dependencies. That's how it's done selectively.

If you happen to compile a program that uses all of the available libraries, you'd end up with QB64 generating a file called libqb_1_111111111111.o.

That's how QB64 does it so only the required code is compiled.

Why then huge binaries for a single PRINT "Hello, World?"

What seems like a SCREEN 0 application is actually an OpenGL canvas that renders a DOS-like font and is capable of displaying colors. That's no easy feat, you can imagine the effort Rob put into it.

All of that justifies file size, I believe.

[GTC]

I am not fussed about QB64's EXE file sizes for the same reasons given by others above. Does the OP have a particular reason for highly optimized EXE file sizes, or is he making a general observation?

Personally, I am just happy to have QB64 at all. (On my XP machine my go-to language for knocking out quick stuff was VB for DOS. I still have the diskettes.)

[FilipeEstima]

I am not fussed about QB64's EXE file sizes for the same reasons given by others above. Does the OP have a particular reason for highly optimized EXE file sizes, or is he making a general observation?

I am not the OP, but for me it's a general observation that sparks curiosity. Executables generated by QB64 are at least 10x bigger than other compilers can output. Once I was speaking with a PHP programmer about a project I want done. Since I can't code in PHP, I did a simple version in QB64 and sent him the EXE to give a general idea about what I had in mind. Guy was all suspicious about how come a simple code of no more than 2 KB could generate 1.5 MB executable. He thought there might be some hidden malware in that EXE. Scanned via lots of antivirus, used virusscan.jotti.org and got nothing, so he ran the program. It was a bit hard to convince him it was safe.

[Petr]

Thank you for the explanation, Fellippe.

[Pete]

I can't say I blame the guy for being suspicious. I would have just shipped him the source code and told him to download QB64 and compile it himself.

It's a shame we can no longer access [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there], as now that Fell brought it up, I do recall a discussion there addressing selective compile libraries. My apologies.

I also wonder just how un-optimized the C++ code translation is. That woud also produce larger than necessary exe files.

Pete

[FilipeEstima]

I can't say I blame the guy for being suspicious. I would have just shipped him the source code and told him to download QB64 and compile it himself.

Well, I did that, but he said he didn't want to install something that would be used just once, so there you go. I'm glad I convinced him after all LOL.