Ideal size of EXE for VB6

[George1111]

My application currently compiles to about 12MB

I have split a section of it into a second EXE of about 5MB, but now regret doing so as a number of routines are common and therefore have to maintained separately

I want to bring them back into one "larger" EXE which will probably be around 16MB - 18MB

Is there a point I should start worrying about the size of the EXE ?

What is the ideal size recommended ? (if there is one)

I'm also interested in the standards recommended for VB.Net also, if anyone knows

[javajawa]

Surely tihs depends on what you're doing with the EXE. Out of interest, how much of that is machine code, and how much is embedded graphics?
Also, I thinl, given the current technology, unless you can think of a reason otherwise, that the size on disk is considerably less important that the displacement of RAM

[TheCPUWizard]

Unless measured otherwise, size is not even a consideration when taking into account accepted design principles.

Even a couple of hundred megs as a running requirement is usually insignificant.

[WoF]

I don't know about a maximum exe size.
If my app starts growing above 64MB I should start wondering if I have taken the right line of program developement, and propably would have started putting common things into dlls or to use other program splitting methods.

I also know not about an "ideal program size". How should this optimum be calculated, from what should it depend?
Maybe you say, (like I do), well I have to send customers an update frequently, which mostly consists of a freshly compiled exe. If you send these update by email you will find there's a limit in attachment size. But there is FTP to handle larger files as well.

Memory size is no consideration anymore nowadays. Storage capacity is no limit.

As long as things work, I wouldn't care about exe size at all.

[dee-u]

The only thing that you should worry about is the speed of which your app loads with such size. Could you not put in a separate DLL those common routines that you mentioned?

[WizBang]

I'd think an ideal size depends on what the program does. The suggestion of one or more DLLs sounds good, but unless it cuts down on total code, the total bytes probably wouldn't change much if at all.

What happens when you zip it? Do you plan to have users download it?

As was mentioned, load time can be important, and I'd expect improvements there if the exe itself was smaller, even if it means DLLs, if they can be loaded after the interface is showing.

[George1111]

I also have a significant number of other EXE files which complement my package

They have been written as separate EXE's as they are programs like

a) My Reporting System
b) My Import / Export System
c) My Document handling System
d) Utility Programs

I pass parameters to these and launch them using SHELL ..... which all works very well

I have never implemented DLL's

I presume a DLL is equivalent to an EXE (or a collection of classes) , and still requires you pass parameters to it - is this right ?

eg,

Microsoft Visual Basic

Option Explicit
Declare Function AddNumbers Lib "Example.dll" _ 
(ByVal a As Double, ByVal b As Double) As Double
 
Sub Main()
	Dim Result As Double
	Result = AddNumbers(1, 2)
	Debug.Print "The result was: " & Result
End Sub

If so, a DLL will achieve very little for me as I am already launching an EXE and passing parameters to the EXE (not quite as elegant as a DLL but functionally equivalent)

I've heard of "DLL Hell" and have therefore never knocked on its door (I presume this is all about getting the parameters wrong)

[TheCPUWizard]

I've heard of "DLL Hell" and have therefore never knocked on its door (I presume this is all about getting the parameters wrong)

Not directly. "DLL Hell" is when two vendors decide to name their DLL with the same name (or produce multiple versions with the same name) AND the installation of the DLL is attempted into the same directory (kind of hard to have two files with the same name in the same directory....)

[DataMiser]

IMO The ideal size is as small as possible while getting the desired functionality. With the addition of more and more ram and larger and even larger Hds many programsers have gotten sloppy and do not care how big thier programs get. With the faster CPUS many are not coded for speed anymore either.

This is a pet peeve of mine as it seems that there is a lot of garbage in a lot of recent programs causing them to load slow and run slow the only reason they are acceptable is due to super fast CPUs and lots of ram but one must consider that the user might want to run other programs on the PC as well and if your program hogs up all the memory other programs will have to fight for it and everything will be slow even on a fast system.

Dot net is a prime example of an extremely over inflated program as is Vista. They are huge, load extremely slowly and take forever to install even on a fast system.

Yesterday I tried to uninstall VS2005 from a XP2400+ system with 512m ram. I started the process as the football game came on and about half time it told me that it could not find the required resources. 2 Hours setting there collecting system information before it figured out that the DVD was not in the drive.

I ended up reformatting the drive and reinstalling the OS as this was faster than the uninstall.

Not that a 12 meg exe would cause this kind of issue but smaller is usually better in every way. If there are a lot of embedded objects I would look at removing them from the exe and loading them as needed. If there are a lot of declrations and functions which are not actually used by the program I would remove those as well.

[dglienna]

The app I'm currently working on ships at about 25mb. I can't even think of deploying with VB6 anymore. Click-Once is great.

I publish it to their server, and each time they start the program, it downloads the updates automatically. As long as they have db access, anyone in the office can run the app.

I can deploy remotely, check that it runs on one pc, and then rest assured that there won't be any problems the next day.

[George1111]

I probably have almost answered my own question, now that I am thinking about it

During the running of my application, I load the main EXE (12MB) then later launch another EXE (5MB). A duplication in memory resources takes place in that both EXE share a lot of Global Variables (which need to be reloaded when I load the second EXE)

So combining the 2 will actually reduce the overall data storage requirements in RAM

I also use the methodolgy of of NOT loading programs from the Client

I load them across the network from the Server, so that I only need maintain one up to date copy of apps. on the network

Is this considered sensible ? (I think it is)

[TheCPUWizard]

I load them across the network from the Server, so that I only need maintain one up to date copy of apps. on the network

Is this considered sensible ? (I think it is)

Almost definately NOT. There are multiple technologies where you automatically check from a network location and download if an update is required, but downloading from the net on each run is usually NOT a god idea...

[dglienna]

Almost definately NOT. There are multiple technologies where you automatically check from a network location and download if an update is required, but downloading from the net on each run is usually NOT a god idea...

I have to tell them to restart the app. It stays open until something forces a reboot. I can also schedule whether it checks, and even have it run online from an online share (although I don't think they'd like that idea)

[George1111]

Originally Posted by TheCPUWizard
Almost definately NOT. There are multiple technologies where you automatically check from a network location and download if an update is required, but downloading from the net on each run is usually NOT a good idea...

The application is run from the Local Server

eg,  \\server\programs\myapp\myapp.exe

My biggest concern is that a window pops up and asks something like "Do you want to RUN this application" Wish I could hide it.

Using your method (running app. from client), do you recommend the client application loads something from the server to check if it is running the up to date application - if it is up to date, then run the application from the client local hard drive. If the client app. needs updating then you must run some sort of update procedure to load the up to date app. from the server.

Do you load the latest version into a special folder on the server, ready to update each client computer.

What do you feel is the gain by doing it this way ?

(Even if I need to update several EXE's it all happens on the server

The other methodology I employ is to embed any Database upgrades in the application.

So when the Client runs a version, the system checks the registry of the client to see what the latest Database Version was updated, and it upgrades any steps required, logically, not requiring individual updates to be run independantly to achieve the latest database format - the client sees nothing and the system just carries on.

This model works when the app. is run from either the Server, or the client.

[dee-u]

I have never implemented DLL's

I presume a DLL is equivalent to an EXE (or a collection of classes) , and still requires you pass parameters to it - is this right ?

Component Tools Guide should be a good read.