VB6 - executable size

[Structural Integrity]

What is the most important factor of the size of a VB6 executable. I'm asking because the exe I have here is steadilly growing. When I started working here it was around 6 MB, now I'm over 7 MB.
It's not that I really care about bringing back the exe size, I'm just curious, because 7 MB is a WHOLE LOT in the eyes of a simple C++ programmer.

[Cyp]

No idea... What happens if you check the size in bytes, add something, save it, compile it, remove it, then save it again and compile it again, and check the size in bytes again?

Do you have large pictures in there, or is the code on the order of a million lines..?

[pablissimo]

I'd imagine that a debug build would be significantly larger than a release build, is there much of a difference between the two? I say this only because I don't remember VB making PDB files way back when in the days of VB 4 though this has feasibly changed.

[JetLinus]

Hmmm...
You know there is a option in the compile dialog, "optimize for size". Default is "optimize for speed", and I'd strongly recommend to leave it that way. Speed is most important (especially for VB ^^).
But you were probably aware of that option. I've never tried it anyway.


So, well, MOST important for filesize in VB are resources and graphics. The contents of every picture and image control will be included into the exe file. If you're unlucky, everything is stored in uncompressed 24bit BMP, i.e. huuuuuge.
You COULD try to convert the images to JPEG, dunno if that reduces filesize. Defenitely working is 8bit RLE bitmaps.
So you open the image / picture control, extract the picture, convert it, save it, and re-load it to the image control.


Other things are -- of course -- strings. I used to include a 100kb module of DirectX-Error-Descriptions, which made the exe-size increase by about 200kb (if I remember correctly). Probably because of unicode...

Also I've got an "engine" (just a collection of useful functions) I very often include in my files. About 60kb sourcecode, about 200kb more exe-filesize maybe?
Hmmm...



So, since code and API declarations and even strings cannot make THAT big of a difference, check your forms for suspicious controls and or bitmaps.

[meglamaniac]

If it's anything like MS Visual C++ then debug builds are bigger IF you use static linking.
However, the VC++ default is to use the runtime DLLs so none of the standard C++ library is included in the exe. Thus you get an exe that can do a hell of a lot while being only 50kb or so.

I don't know if VB has a similar option, but it's worth a look.

[Caesar2]

Using gif's and jpg's instead of bmp's will decrease the size of the executable with the same amount of size decrease of the pictures.

[JetLinus]

Visual Basic does NOT have the option to include debug information into exe files!


Why would you need that anyway? It's still an interpreter after all. And the "debug mode" (i.e. play and stop the program) is still one of the best. Hover about a variable in the sourcecode to get its current content shown via tooltip. And then you can resume the program line by line.

Originally Posted by Caesar2

Using gif's and jpg's instead of bmp's will decrease the size of the executable with the same amount of size decrease of the pictures.

Well, I wasn't totally sure, it depends on both the control and the VB version. It actually SHOULD do that, but I had cases (can't remember if that was very old VB3 though) where the image would be saved in BMP, no matter what the source format was...

[meglamaniac]

Originally Posted by JetLinus

Visual Basic does NOT have the option to include debug information into exe files!
Why would you need that anyway? It's still an interpreter after all. And the "debug mode" (i.e. play and stop the program) is still one of the best. Hover about a variable in the sourcecode to get its current content shown via tooltip. And then you can resume the program line by line.

As you can in VC++ - it's not a feature exclusive to VB, the entire Visual Studio suite can do it. You can even change the contents of variables while the program is executing if you feel so inclinded.
Building a debug release is still useful when testing on systems without the development environment installed, as it gives more helpful errors than "whoops, general protection fault which could have been caused by any one of a few hundred things".

But we digress.
If there is no equivilant of VC++'s dynamic runtime library linking then I don't really have any other suggestions.
You must be using a hell of a lot of images. Is there no way to seperate them out and load them dynamically instead?

[Structural Integrity]

There aren't many images in here, only one that I know of, the rest are seperate files. And over the months I haven't added a single image, still the exe grew by a megabyte.
What I DO have a lot are forms. Around 120.
What I also find peculiar is that the entire source code is about as big as the exe itself. But then again, the exe grew by a meg, and I haven't made many new forms, but one. I've been mostly altering forms, rewriting sections, adding classes. But that hardly makes up for a megabyte of changes.
Does VB6 keep some version information in the exe perhaps? Like store the changes made?

Anyway, I just added one line of code (if statement with single compare breaking from a loop) and recompiled, the new filesize did not change one byte (I just WTF-ed).
I also tried removing dead lines of code yesterday, but that didn't have any effect either.

[Structural Integrity]

Oh, and about the debuggers, the VC++ debugger > VB debugger
The VB debugger is lacking in the watch part where it doesn't allow you to just type in a variable name but you have to take a detour with the right mouse button.

[queball]

.exes tend to use pages, so the size will be page-aligned rather than being tightly tied to the exact amount of code. Though of course pages are something like 512B (I think) so that doesn't account for 1MB leaps. Perhaps your changes triggered the inclusion of some extra code, you used some set of controls or functions you hadn't before.

You could do some investigation into what makes up the binary. Last time I checked you could use quickview to inspect exe headers.

[Structural Integrity]

Originally Posted by queball

.exes tend to use pages, so the size will be page-aligned rather than being tightly tied to the exact amount of code. Though of course pages are something like 512B (I think) so that doesn't account for 1MB leaps. Perhaps your changes triggered the inclusion of some extra code, you used some set of controls or functions you hadn't before.

You could do some investigation into what makes up the binary. Last time I checked you could use quickview to inspect exe headers.

Hey, you're right, I just recompiled again after making some more changes and the filesize increased with 4kB (4096b).

[meglamaniac]

That's more likely to be your disk cluster size... unless you're talking about the exact filesize which windows reports in the properties page.

[Structural Integrity]

Originally Posted by meglamaniac

That's more likely to be your disk cluster size... unless you're talking about the exact filesize which windows reports in the properties page.

That's the one, yeah. In the properties page.

[JetLinus]

Ok, well.

To search for dead code, I can recommend VB Project Analyzer. The free version can load up to 10 modules -- won't be enough for you maybe, but at least, you could check the biggest files.


And YES, I just found the option to "Generate debug information for symbolic debugger" in the compile options. You guys were right. It was always there, my fault, I just never used it :-/



So how does S/I get his exe smaller? Hmmm. There is somerwhere the option to "remove references to unused ActiveX-components", maybe that's it? Edit: I just checked, it's on by default anyway.

Apart from that, even SIX MB is huuuuuuuuge. I mean, 120 forms are ok, how can they produce SUCH a big exe?


Have yout though about using MS Dependency Walker on the produced exe file? Or Resource Hacker? You know, just something to get more information about the exe...


So, out of curiousity, your project IS a "standard-exe", isn't it?
Uh, and how long does it take to compile?

[Structural Integrity]

Yes, it's a standard exe, so it says in the dropdown of the project settings. And in the compilation tab it compiles to native code.

I just checked to "optimise for small code" and I got about half a megabyte off. Still quite a chunk.

I'm going to check the dependency walker and resource hacker you mentioned.

Oh, and compiling the thing takes just over a minute (on a machine with too little memory so it's paging like a madman). This I can not explain either. Half-decent C++ projects usually take longer.

[edit]
resource hacker shows two icons and one version info block.
[/edit]

[edit2]
I'm not sure how to use the dependency walker, but I can not spot anything unusual in the treeview.
At the top level there's only MSVBVM60.DLL, under which a number of standard system DLL's are placed.
I find this rather odd BTW because I know for a fact that the app uses a number of home brew DLLs.
[/edit2]