Dll Hell

A form of DependencyHell related to Windows DLL files.

Don't blame MicroSoft. Nobody in their right mind is still using version 6.00.8168.0. Didn't you get the MSDN update?

"The system in Windows Server 2003 is designed to stop updated DLLs installed by new applications from overwriting older versions of the same DLLs that may still be used by existing applications." Read more here http://news.com.com/2100-1012-991466.html

Does that include MicroSoft? They must be the primary offender in this regard. I am always amazed at MicroSoft's ability to introduce "features" that merely compensate for problems caused by their own software.

There is some debate about whether MS used such approach to reduce code duplication or simply to be able to package complex software into the small spaces required back then by eliminating redundancy.

A million System Registry entries, all for want of a functioning symlink in the file system...

DllHell tends to back IfItAintBrokeDontFixIt. Updating a component without a testing and reversal system of some kind in place is asking for problems.

Even though MS doesn't do it anymore for update purposes alone, their security updates often do break things, and so the ghost of DLL-hell still lives. Our office had a printer brand that stopped working due to a security update, and another time MicrosoftAccess had a "blank list" problem due to a security update.

Version Substitution

I'd say the biggest lesson learned is don't assume module version N + 1 is a sufficient replacement for N. If an app has been tested and vetted with version N, then try to use version N only, not N+1 or N-1. I suspect back when disk-space was expensive, "shared libraries" looked like a great way to cut down on disk space. However, from a software maintenance perspective, it created versioning problems when application B would overwrite version N of foo.dll with version N+1 of foo.dll in the shared area(s). However, version N+1 doesn't work with application A, which also uses foo.dll.

A "fix" would be to name the DLL's with a version number, such as foo_3_12.dll (foo version 3.12). All files named foo_3_12.dll that are shipped with different apps should in theory be the same. If another app drops in file foo_3_13.dll, then things would be fine because the old apps would still use foo_3_12.dll. (The "8.3" file-size naming limit of the time would complicate this a bit.)

If a DLL is by chance missing and all we have are other versions, then create some kind of substitution convention, such as a file named "foo_3_12.alt" which would contain a list of DLL's to try to use instead, such as foo_3_13.dll.

Extra insurance could be had by running a hash/checksum on the file to make sure it's the one expected. The downside is that early Windows would be bloated with multiple versions of similar things.......kind of like modern Windows is :-)

--top

Compare RpmHell, ClasspathHell