Fog Creek Software
Discussion Board

More on DLL's and C++ exe's

Suppose you were releasing an C++ application. How would you release it, a monolithic .exe or with DLL's everywhere?

What's the best route for you?

Wednesday, April 28, 2004

Don't you keep asking the same question in different ways?

John Topley (
Wednesday, April 28, 2004

• If you're going to share code amongst applications, use DLLs.
• If the application contains modules that need to be updated independently, use DLLs.
• If the executable is going to be huge, use DLLs.

John Topley (
Wednesday, April 28, 2004

With DLLs, but not "with DLL's everywhere". The number of DLLs should be kept under control. Some plus points of using DLLs:

- Single monolithic exe is going to create problems while giving out patches or releasing new version (including Service Packs).
- Using DLLs, performance can be improved by using delay loading of DLLs or by using run time loading using LoadLibrary() functions (depends on usage).

PS: What exactly are you looking for? As John Topley pointed out, this is the third such post.

Wednesday, April 28, 2004

I am sorry for this. I was trying to make up my mind about what's the best route. I have 0 experience in creating apps that use DLL's and I'm trying to know which is best, a huge executable or lots of files. I am trying to get as much feedback as I can.

Once again, I am trully sorry.

Wednesday, April 28, 2004

I prefer monolithic .EXE.

This way, I don't have to worry about "Shut! The user installed some other app which overwrote my DLL with an incompatible version, and now I get strange bug reports or AV crashes".

The gain obtained by dynamically loading DLLs is minor.

Wednesday, April 28, 2004

>>The user installed some other app
>>which overwrote my DLL with an
>>incompatible version, and now I get
>>strange bug reports

the solution for this is to copy all dlls into your app folder and not into %system32%

Wednesday, April 28, 2004

And what about the disk space? In one of my other previous threads someone mentioned having lost one gig of disk space to same dll's.

Wednesday, April 28, 2004

The solution is to use a common directory unique for your set of dlls (e.g.: C:\Program Files\Common Files\Kalani\GameEngine.dll).  That way you'll only have yourself to blame for incompatibilities and name collisions (just like with namespaces).

Wednesday, April 28, 2004

1Gb? That is about 1$-15$ of storage, depending on the scenario, right?

Just me (Sir to you)
Wednesday, April 28, 2004

there are 400 million word users. if each copy waste 20 MB because of duplicate DLLs it's 7629 TB which is more than $7,000,000. not that cheap. but it's good for the hdd makers.

ok, calculating something in this way is stupid, i know

Wednesday, April 28, 2004

Ok, here's a definitive answer. It just depends.

The reason that you "hear" about Delphi executables not generally requiring DLLs for distribution is that most of Delphi's built in components are compiled directly into the executable. In most other language environments, one winds up using prebuilt binary components that you must redistribute as separate DLLs or OCXs or whatever.

As far as partitioning your application itself so that it consists of two or more modules, say a DLL and an EXE... there is NO reason to do this at the scale of shareware or a small SW company. The only reason you should ever develop a DLL is to create SIMPLE support code or SIMPLE components that you simply can't implement in the main program.

Here is what I mean by the use of caps above. I had a client that has gone hog wild with partitioning their sh*t into outboard DLLs. The owner has wet dreams about a Grand Architecture of cooperating modules and about his wunderkind products consisting of a tiny core of a "real" executable, supported by big fat rarely changing "supporting" DLLs.  He "wants" to be able to tell the customer that they only need to download a 150K application when there is a revision.

The squalid reality is that these guys are too inept to partition functionality to take advantage of this "architecture", and so they wind up debugging everything, across multiple DLLs, as one single huge ball of mud. And when ANYTHING changes, EVERY DLL has to be recompiled, because of course interfaces change even though the owner is egotistically preaching that his interfaces are perfect.

So, that is a war story. KISS!!!! (keep it simple stupid)

Bored Bystander
Wednesday, April 28, 2004

For a commercial product where your company has to do the support when the user messes up: Monilithic EXE. And they WILL mess up. Even if you put the DLLs in the application directory. Users do stuff you'd never expect.

Wednesday, April 28, 2004

DLLs are for shared code - if you're writing one program what advantage is there to pull it into 2 parts?  However, if you're writing a suite of programs that share functionality (like reading a custom file format or generating a common database interface) then it makes perferct sense to pull that code out and make it a seperate library.  Then you can upgrade your libraries without distributing new application files.

Thursday, April 29, 2004

*  Recent Topics

*  Fog Creek Home