Fog Creek Software
Discussion Board




A History question ... DLL Hell and Unix

Anyone know why DLL hell on Windows was not fixed using UNIX's solution of renaming the lib filenames ?

Regs

Paul

Paul Reidy
Tuesday, January 22, 2002

It's been a few years since I had to deal with this, so this is all from memory, but I think it goes something like this...

The DLL module name was/is also stored internally to the DLL itself.

So, assume you are trying to load the "Foo" module from your EXE by calling LoadLibrary("Foo").  You expect to get the "standard" Foo module from Bar.DLL, version 14, in the Windows System directory, because there is some registry or system.ini magic that tells the system that Foo = Bar.DLL.

However, someone else's app has included its own Foo module, in a Foo.DLL, and installed it into the directory that contains that app's EXE.  And that app is already running.  So, that other EXE also called LoadLibrary("Foo"), and it got the one from its own directory, which happens to be version 12...

So when your app calls LoadLibrary("Foo"), the system first checks to see whether the Foo module is loaded.  Since that other app loaded a Foo module, the system returns a handle to the already-loaded Foo module, which turns out to be not the one you want.

Result: DLL hell.

A.Nonnie Mouse
Tuesday, January 22, 2002

As noted, there are two versions of DLL Hell. The question posed was why does Windows not use different filenames for different versions of a DLL. This is not officially DLL Hell, just a bad Windows design decision.

A. Nonnie Mouse describes what is officially "DLL Hell", where Windows allows applications to share in-memory code pages for an already loaded DLL, even if that DLL is the wrong version! This problem would be solved if Windows used versioned filenames or (pessimistically) check the complete DLL file paths (instead of just base filenames) when looking for an already loaded copy of that DLL. I don't see any backwards compatibility reason that prevents Microsoft from changing their in-memory DLL check and making it more robust. sigh..

VMS solved this problem by making file versioning part of the file system. You could have multiple shared libraries with the same filename, but differentiated by a file version property. This is functionally equivalent to Linux's versioned filename convention, but I think Linux's solution seems simpler.

cop
Tuesday, January 22, 2002

You can still get DLL hell in Unix, anytime you've got a contract between your app and a shared piece of code, and then that contract changes in even a subtle fashion, breakage will occur.  The idea is that DLL versions should always be 100% backwards compatible, but in the real world this just doesn't always happen.

In Unix, usually you have a symbollic link libfoo.so, say, that points to libfoo.so.4, and then when libfoo.so.5 comes out, you can change the symbollic link back if you have breakages.  In Windows, symbollic links don't exist (well, they do in NTFS, but no one uses them), so you end up clobbering the version of the DLL you need, and need to reinstall the old software to get it.

Some windows apps do get around DLL hell by putting the version number in the filename of the DLL they need -- the runtime DLL for VB apps, for example, has gone from vbrun100.dll to vbrun60.dll.

I think in Windows-land there are just more DLLs in general, and hence a higher risk of naming conflicts.

http://www.alyosha.net/

Alyosha`
Tuesday, January 22, 2002

What A. Nonnie Mouse  is describing was a problem with 16 bit Windows but has been fixed since 1995 :)

Joel Spolsky
Tuesday, January 22, 2002

It's fixed in Windows XP.  See http://msdn.microsoft.com/library/en-us/dnwxp/html/sidexsidewinxp.asp

From the introduction:

Dynamic Link Libraries (DLLs) versioning conflicts have presented a complex and often frustrating set of problems (DLL hell) for Microsoft® Windows® application developers. Microsoft® Windows® XP addresses this problem by allowing application developers to build isolated applications and side-by-side assemblies. These help eliminate the effects of DLL versioning conflicts on the development, deployment, and maintenance of applications.

Nona Myous
Wednesday, January 23, 2002

There's two important verbs in that description which waters down the actual 'fixedness'.

'allows'  Developers can build isolated applications but they don't have to, and unless products are going to deliver their own copy of standard DLLs just to make sure they get their own version all that will happen is that the same 'hope this DLL is there and its the right one' decision will have to be made. 

Its true that versioning will, and here comes the second word, 'help' in fixing this but it won't eliminate it.

Simon Lucy
Wednesday, January 23, 2002

All this seems like another really good reason not to rely on 3rd party libraries, even (maybe particularly) if they come from the operating system developer.

Tony E
Wednesday, January 23, 2002

<B>'allows' Developers can build isolated applications but they don't have to, and unless products are going to deliver their own copy of standard DLLs just to make sure they get their own version </B><HR>

Hmm ... Wasn't one of the _huge_ features of DLL's the diskspace argument?  Meaning: If you keep having to statically link to Stdio.h in every application, you are wasting a lot of disk space.  Better to have one DLL for all your EXE's. 

  Of course, the first time I read this argument was in 1997, by which time disk space was cheap enough to make this argument rediculous.  Data and Multimedia are my disk hogs, not Object Code.

  Still, I _believe_ it's one of the arguments in Chapter 1 of "Essential COM" by Box.

  so, now we "Get the Benfit" of shipping our own DLLs in our own directory?  Why not just link them statically?  (I don't buy the "Applications Load Faster" argument either, but I do admit it is _more_ valid than the "Save Disk Space" argument for DLLs.)

  Then again, YMMV.  Just my $0.02,

Matthew Heusser
Wednesday, January 23, 2002

The question I intended to ask was ..

Was there a reason (technical or business) that Microsoft did not include a version num in the file names of DLL's making lib versioning easier to manage. That is what UNIX does, you can still have conflicts, but things are easier to manage.
It puzzles me why MS never did this ?

Paul Reidy
Wednesday, January 23, 2002

A. Nonnie Mouse was replying to the "History question" that was posed...

A.Nonnie Mouse
Wednesday, January 23, 2002

Here is a great Dr. Dobb's article that dismisses the supposed advantages of DLLs and recommends static linking. As noted above, I think static linking is especially important when using third-party libraries, including/especially Microsoft's MSVCRT and MFC DLLs. When you statically link, you don't have to worry whether the user has those DLLs or installing those DLLs or if the user has the wrong version.

"Windows DLLs: Threat or Menace?"
http://www.ddj.com/documents/s=909/ddj9875i/9875i.htm

cop
Wednesday, January 23, 2002

What have Microsoft ever done for us?... DLLs, the Registry... thanks guys :-)

(thankfully "fixed" now with strong-named assemblies, config files...)

Duncan Smart
Wednesday, January 23, 2002

What have Microsoft ever done for us?...

Shades of Reg in "Life of Brian" - "All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"

Andrew Simmons
Wednesday, January 23, 2002

Very to the point...

Frederik Slijkerman
Thursday, January 24, 2002

As to the benefit of DLL over static linking:

There may be very little advantage for application specific linkages, except perhaps load on demand and memory heap optimisations, though in reality DLLs rarely get unloaded once addressed.

For system level linkage it does have a benefit, application to system services should be as disconnected as possible but remaining within the application space to minimise the task switch problem.  Many applications will use the same system level service but it won't be exactly the same subset for all applications, that tends to argue for a DLL linkage. 

Although a well defined interface linkage which is statically managed and which then calls a core API feels (to me at least), more efficient.

Simon Lucy
Thursday, January 24, 2002

It's very good to use DLLs (instead of static linking), when you write the DLLs. You control DLL versions and names, and decide how many must be upgraded when you install a patch or a new feature.

You must be using DLLs when you talk to O/S system code ... because the O/S is delivered as DLLs, nobody has ever (except in an embedded system) suggested you can static-link to it.

If you'd like to depend on a specific version of someone else's DLL, then install it into your application directory (not into a shared system directory).

Christopher Wells
Thursday, January 24, 2002

The Unix solution?  What about the NeXT solution?  (Okay, now "Apple")

http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Frameworks/The_Framewo_ary_Package.html

It continues for 3 pages after the URL above, or try the entire documents (in evil framed pages) here:

http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/

John
Thursday, January 24, 2002

The original poster, Paul, asks:

"Was there a reason (technical or business) that Microsoft did not include a version num in the file names of DLL's making lib versioning easier to manage. That is what UNIX does, you can still have conflicts, but things are easier to manage. "

The Windows team was not customer focused. DLL hell was not a problem for the Windows team, therefore they did not take time to address the problem.

After years of customer complaints, they finally implemented the "Assembly" thing.  As a side note, the work on Assemblies started outside of the core Windows team at Microsoft.

anon
Thursday, January 24, 2002

So is the "Assembly" solution as good or better than what UNIX does, from the little I know of it, it seems a lot more complicated.
I believe COM was once expected to solve this problem, and although COM has enabled much more software reuse than ever happenned on UNIX, it did not cure DLL hell.

Paul Reidy
Thursday, January 24, 2002

To my experience using assemblies and manifests have worked well in .NET.  Unlike COM, however, you don't get the "benefit" of upgrading application functionality just by installing a new component.  On the other hand, the benefit is also a huge hassle.  Yeah, it was nice when I did game programming to install a DirectX update and get faster rendering performance, but it was also extremely terrifing after the game shipped. 

Also, I like having the manifest option so that I can QA the app with the updated components and then release a manifest update, rather than letting the poor users discover the incompatibilities in the field.  Philosophically, Microsoft has finally realized that "interface != contract" and subsequently slightly lowered the stress of people everywhere.  Which, statistically probably means they are saving lives.  (Try that morality on for size. ;->)

Whew!

Grant BlahaErath
Friday, February 01, 2002

Aloha!

I think I experience .dll hell on my laptop. It got Win98 on it. After I deleted a .dll file, it got worst.

Do you guys have any specific information for me?

Best wishes;

Steve

Steve Miller
Friday, June 25, 2004

*  Recent Topics

*  Fog Creek Home