The Old Joel on Software Forum: Part 4 (of 5)

Uber Cool

I heard here that Delphi produces self-contained executables without the need for DLL's. Can I do this with VC++? Produce my app in one single executable?

If not in VC++, is there any other C++ compiler for Windows that does this?

RP
Tuesday, April 27, 2004

I'm not 100% sure, but as a guess Borland C++ Builder would compile into a single executable as well.

PDF
Tuesday, April 27, 2004

Yes, any C++ compiler allows you to create self-contained executables.

Paulo Caetano
Tuesday, April 27, 2004

>>"Yes, any C++ compiler allows you to create self-contained executables."

Then why is it that every program I see that is written in C++ contains a massive mess of DLLs?

Programmer stupidity?

My Cousin Vinniwashtharam
Tuesday, April 27, 2004

Yes, e.g. this program was written in VC++ http://www.jacksondj.com/downloads.html

"Installing Jackson is easy: you don't. Just unzip the downloaded file somewhere (like on your desktop) and double-click on the executable."

Personally I would prefer every program to use the standard installer, with entry into the add-remove programs etc. With these standalone .exe's you never know the uninstall routine and you get left with junk in the registry etc.

Just me (Sir to you)
Tuesday, April 27, 2004

"Then why is it that every program I see that is written in C++ contains a massive mess of DLLs?"

The framwork code (e.g. MFC and CRT) can be very large. Including it in the binary means you get a separate copy of it for every application that needs it. It's more efficient to have one copy of it in a central place that can then be used by anyone.

SteveM
Tuesday, April 27, 2004

Alas the dll hell...

Marc
Tuesday, April 27, 2004

"It's more efficient to have one copy of it in a central place that can then be used by anyone."

That sounds so nice in theory.

Jan Derk
Tuesday, April 27, 2004

"Then why is it that every program I see that is written in C++ contains a massive mess of DLLs?

Programmer stupidity?"

Probably dynamic linking, i.e., you're not linking statically.

Depending on my choice, Delphi can also require that I distribute its libraries with the .EXE (they're basically DLLs, despite their .BPL (I think) extension).

Sometimes, you don't have a choice. If you use a library, and its developer only gives you a DLL, there's not much you can do.

BTW, "programmer ignorance" sounds a lot better than "programmer stupidity", and describes the problem more accurately. E.g., the first time someone mentioned "Delphi's runtime", I jumped on his throat, asserting beyond any doubt that Delphi didn't have a runtime. A few days later, I swallowed those words, and became a little less ignorant :)

Paulo Caetano
Tuesday, April 27, 2004

"Probably dynamic linking, i.e., you're not linking statically."

Sorry, should be "they're not linking statically".

Paulo Caetano
Tuesday, April 27, 2004

>>"The framwork code (e.g. MFC and CRT) can be very large. Including it in the binary means you get a separate copy of it for every application that needs it."

No....I mean DLLs that are specific to one program and not used by any others.

My Cousin Vinniwashtharam
Tuesday, April 27, 2004

"DLL hell" is not a problem with DLL's but how they are managed.

In many cases, the "hell" results from different versions of DLL's with incompatible interfaces or behavior that had the same name. This is a mistake: for DLL's and static libraries.

People (including MSFT) should have given the DLL's different names.

njkayaker
Tuesday, April 27, 2004

The DLL hell, with all their different versions with incompatibilities have led companies to install their specific MFC DLL in the application directory. Lately I downloaded a littl application that searched for duplicated files (based on file hash), and I came to the conclusion that this has cost me over 1 Gb on my disk...

so for for a nice solution

Mark Tetrode
Tuesday, April 27, 2004

I think VC++ can produce self-contained EXEs only if the libraries that you want to link to are static libraries. E.g. all the MFC libraries are available as normal libraries as well as static libraries. In the Project Settings, you can control whether you want to use MFC as Static Library or as Shared DLL. If you choose Static Library, all the relevant functions are brought into the EXE itself thereby increasing the size of the EXE but removing run time dependencies.

If you are creating your own library, you can choose whether to create a static library or a normal (shared) library. If you create a static library, on building the project, only a LIB file will be produced. No corresponding DLL files are produced. And the client modules do not have any option. If they use your LIB file, during linking, the functions are included in the EXE itself (again increasing the size of the EXE bug removing any DLL dependencies).

T-90
Tuesday, April 27, 2004

"No....I mean DLLs that are specific to one program and not used by any others."

The only reason for this I can think of is to aid deployment. If you fix a bug or improve a feature you just need to upgrade a single DLL instead of the full system. A customer doesn't want to pay for a specific feature, you just don't give them that DLL.

Easy.

Hahahaha.

SteveM
Tuesday, April 27, 2004

Programs often ship with what appears to be a DLL unique to that application because the programmer only has a dynamic library available. Dynamic libraries are much easier to distribute than static libraries, since most development environments ship with a way to import DLLs. Static libraries are typically incompatible between compilers.

Clay Dowling
Tuesday, April 27, 2004

DLLs also provide a mechanism to ensure that your different modules are truly self-contained, and that no compilation dependencies are introduced.

Gustavo W
Tuesday, April 27, 2004