Why creating DLLs instead of compiling everything to a one big executable?

Question

I saw and done myself a lot of small products where a same piece of software is separated into one executable and several DLLs, and those DLLs are not just shared libraries done by somebody else, but libraries which are done exclusively for this software, by the same developer team. (I'm not talking here about big scale products which just require hundreds of DLLs and share them extensively with other products.)

I understand that separating code into several parts, each one compiling into a separate DLL, is good from the point of view of a developer. It means that:

• If a developer changes one project, he has to recompile only this one, and dependent ones, which can be much faster.
• A project can be done by a single developer in a team, while other developers will just use provided interfaces, without stepping into the code.
• Auto updates of the software may sometimes be faster, with lower server impact.

But what about the end user? Isn't it just bad to deliver a piece of software composed of one EXE & several DLLs, when everything could be grouped together? After all:

• The user may not even understand what are those files and why they fill memory on his hard disk,
• The user may want to move a program, for example save it on an USB flash drive. Having one big executable makes things easier,
• Most anti-virus software will check each DLL. Checking one executable will be much faster than the smaller executable and dozens of libraries.
• Using DLLs makes some things slower (for example, in .NET Framework, a "good" library must be found and checked if it is signed),
• What happens if a DLL is removed or replaced by a bad version? Does every program handle this? Or does it crash without even explaining what's wrong with it?
• Having one big executable has some other advantages.

So isn't it better from end users point of view, for small/medium size programs, to deliver one big executable? If so, why there are no tools allowing to do it easily (for example a magic tool integrated in common IDEs which compiles the whole solution into one executable, not each time, of course, but on-demand or during deployment).

---

This is someway similar to putting all CSS or all JavaScript files into one big file for the user. Having several files is much smarter for the developer and easier to maintain, but linking each page of a website to two files instead of dozens optimizes performance. In the same manner, CSS sprites are awful for the designers, because they require much more work, but are better from users point of view.

Answer 1

I think your general point about considering carefully the final packaging of deliverables is well made. In the case of JavaScript such packaging is indeed possible, and with compression makes a significant difference.

Answer 2

Yes, it is better IMHO - and I always use static linking for exactly the reasons you give, wherever possible. Lots of the reasons that dynamic linkage was invented for (saving memory, for example) no longer really apply. OTOH, there are architectural reasons, for example plugin architectures, why dynamic linking may be preferable to static.

Answer 3

Done lots of projects, never met an end-user which has any problem with some dll files residing on his box.

As a developer I would say yes it could matter. As an end-user who cares...

Answer 4

Yes, it may often be better from the end user's point of view. However, the benefits to the developer (and the development process) that you mention often mean that a business will prefer the cost-effective option.

It's a feature that too few users will appreciate, and that will cost a non-trivial amount to deliver.

Remember that we on StackOverflow are "above average" users. How many (non-geek) family members and friends do you have that would really value the ability to install their software to a USB stick?

Answer 5

It's a tradeoff
(You figured that out yourself already ;))
For most projects, the customer doesn't care about how many files get installed, but he cares how many features are completed in time. Making life easier for developers benefits the user, too.

Some more reasons for DLL's

Some libraries don't play well together in the same build, but can be made to behave in a DLL (e.g. one DLL may use WTL3, the other requires WTL8).

Some of the DLL's may contain components to be loaded into other executables (global hooks, shell extensions, browser addons).

Some of the DLL's might be 3rd party, only available as DLL.

There may be reuse within the company - even if you see only one "public" product, it might be used in a dozen of internal projects using that DLL.

Some of the DLL's might have been built with a different environment thats not available for all developers in the company.

Standalone EXE vs. Installed product
Many products won't work as standalone executable anyway. They require installation, and the user not touching things he's not supposed to touch. Having one or more binaries doesn't matter.

Build Time Impact
Maybe you underestimate the impact of build times, and maintaining a stable build for large projects. If a build takes even 5 minutes, you could ephemistically call that "make developers think ahead, instead of tinker until it seems to work ok". But it's a serious time eater, and creates a serious distraction.

Build time of a single project is hard to improve. Working on VC9, build parallelization within one project is shaky, as is the incremental linker. Link times are especially hard to "optimize away" by faster machines.

Developer Independence
Another thing you might underestimate.
To use a DLL, you need a .dll and a .h. To compile and link source code, you usually need to set up include directories, output directories, install 3rd party libraries, etc. It's a pain, really.