mORMot Open Source

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Dll hell, WinSXS monster, and Delphi paradise

A funny and honest article on Dr Dobbs told the story of the "DLL hell" on windows.
http://www.drdobbs.com/windows/227300037

Writing Delphi applications, in respect to needed libraries to be redistributed along with, is just paradise.

What I like very much in this article, is the conclusion:

To avoid DLL-Hell in 2010, the best way is:
- Don't use public DLLs or assemblies at all.
- Don't use the Side-by-side manager.
- Include all DLLs privately in the applications bin-directory and use private assemblies as far as possible if assemblies can not be avoided.

And I like also this very honest notice:

It is worth noting that DLLs no longer save disk space. In fact, the opposite is the case. If you have a look into the side-by-side repository (found in Windows' WinSXS directory), you will find, that its 5 GB on Windows 7 and even 7 GB on Windows Server 2008, containing 40.000 files with numerous versions of roughly all Microsoft Libraries. That's about 50% of the disk space used by Windows in total. We were needing solution, but we created a monster.

Microsoft created a monster... WinSXS directory is indeed one big waste of disk space!

Since the beginning, Delphi executables could perhaps appear a bit bigger than plain MFC applications. 300 KB for a form with some buttons (you can have the same with only 30 KB with our LVCL units).
Delphi 2010 and XE produce bigger executables, perhaps 800 KB for the same form with buttons, due to the new RTTI content added, and some RTL rewrite.
But 800 KB is nothing nowadays, compared to the disk space needed for installing the Dot Net framework on your computer.

In all our applications, we try to avoid dll usage.
For example, the SQLite3 engine or the zlib library are linked to the exe, with tiny .obj files. No external dll required. No version to check. No manifest to write. No error message at startup. No pollution of the Windows registry.
And if it was difficult to get rid of an external dll, we found out a clean way, by embedding the .dll into the executable, as .zip resource, extracted on request. Nice and easy solution. See http://synopse.info/forum/viewtopic.php?pid=314#p314

One of our former projects (4 years ago, already!), for the French Army, included a "like-thin client", i.e. a stand-alone Delphi application, without any installation step required, running from Windows 2000 to Seven, in just a 300 KB executable (after UPX packing), with a full GIS and secure database client included. 300 KB is less than most todays AJAX application bandwidth usage... See http://bouchez.info/roc.html

I really like the fact that Delphi executables are self-contained.
Programming Delphi can be sometimes like being in paradise.

AdamWu

Member

Registered: 2010-07-22

Posts: 20

Re: Dll hell, WinSXS monster, and Delphi paradise

WinSxS is a monster, and you cannot avoid it.
It is because Windows uses it for a lot of internal libraries, such as for common controls library, which you have not license to redistribute.

Anyway, I am just commenting to share a probably not-so-well-known quirk (API bug) of WinSxS. I encountered this when I tried to programmatically switch context to load a specific version of common controls library.

The background (skip this paragraph if you don't care):
I wrote a plug-in dll for a third party exe file which is written in another language. I wanted to use an XP style common control but the main executable is not boundled with the manifest.
So, I decided to boundle the manifest in my DLL, and programmatically create an SxS activation context using the boundled DLL before trying to load commctls.

The quirk:
The CreateActCtx API has two mode of operations, in the first mode, it takes an external manifest xml file, and in the second, a resource from a loaded module.

On XP and Vista, the second mode has a bug: although the file name parameter should not be used, you cannot pass null, you have to pass some valid memory address. Otherwise the API fails.

On Win7, this bug is secretly fixed, and in a totally incompatible way. Now you must pass null in the file name when you use module resource, otherwise the API fails. So the quirk workaround I had fails again on Win7 and I have to resort to check system versions and activate workaround accordingly...

I guess they thought nobody ever used the SxS, and it is mostly just for them to make their stuff work properly...

One more note: So far, this bug presists acorss SPs -- XP SP123 and Vista SP1 all has this bug, which is GOOD. I sincerely HOPE they don't "fix" this thing in the next Vista SP, otherwise I will have to add more complicated SP detection to make my program work!

Last edited by AdamWu (2010-12-06 23:22:41)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Dll hell, WinSXS monster, and Delphi paradise

The old "bug for bug" or "is it a bug or a feature?" programming pattern.

wpostma

Member

Registered: 2011-07-22

Posts: 5

Re: Dll hell, WinSXS monster, and Delphi paradise

Microsoft fixes for problems are very often worse than the original problem.

COM/DCOM is an example.

SxS is another.

And  .Net is another. 

And winInet.  And MSXML.

:-)

I am not a Microsoft fan, can you tell?

Warren

Last edited by wpostma (2011-07-22 19:16:45)