Like many others who grew up in New Jersey in the 1960s, I listened to Shepherd spin his fictional yarns about his childhood every night on radio station WOR. I'll always regret having been too timid to jump in and ask him for a chat when I stumbled on a conversation he was having on the 40m band. I'm not certain, but I think it was that conversation in which I heard Shepherd poke fun at some gubernatorial candidate who promised to get the mafia out of New Jersey.
"Get the mafia out of New Jersey? The mafia is New Jersey!" Shepherd quipped.
That quote haunted me all week like an apparition floating between me and my computer monitor, as if to prevent me from finishing this column until I used it. And I finally figured out why.
With this new version of Windows, Microsoft has proposed a viable-sounding solution to DLL hell. Contrary to popular belief, DLL hell isn't the fact that you can break one Windows application by installing another. That's DLL limbo. You don't cross over into hell until you try to get both applications working at the same time.
Microsoft's get-out-of-hell-free card is called side-by-side assemblies. The proposed solution isn't so much a technology as it is a set of guidelines on how developers should use the Windows registry, header files and an XML-formatted manifest in order to run two or more versions of a dynamic link library at the same time without them tripping over one another. In some cases, developers must create even more registry entries than usual, and in other cases, developers must move settings they used to store in the registry to XML files. Microsoft fudged the registry in dangerous ways when it added multiuser features to Windows XP. In this case, Microsoft has just abandoned the registry in places where it wouldn't work.
If you want to see how needlessly complex these DLL guidelines are, contrast them with how Unix developers avoid ".so" hell (DLLs are called shared objects in Unix): They change the name of the library file. That's it. If an application needs version 5.2 of the "ncurses" library, it loads a file called libncurses.so.5.2. The applications that use version 4.2 won't break, because they can still load the file libncurses.so.4.2. No installation programs will overwrite the old file with the new one, because the file names are different.
There are other easy ways to avoid DLL hell. You can statically link applications to libraries or install libraries in the application's directory, and developers can always use and respect the internal version numbers in DLLs.
So if the solution is so trivial, why is Microsoft dragging the registry and XML files into the picture? It unwittingly answered that question in some leaked documents from 1998. Those documents address the threat of Linux and are known as the "Halloween files" because they were leaked on Halloween.
The documents reveal that Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms. That's what side-by-side assemblies is all about. Microsoft depends on obscurity and complexity to survive.
What customers should be asking is, if the solution really is so trivial, why have their helpdesks been struggling with DLL hell for years?
That's what Microsoft doesn't want you to ask. Because, with very few exceptions, you can trace almost every DLL conflict down to the core set of Windows system libraries, such as COMCTL32.DLL or MSVCRT.DLL. Almost all Windows applications use them. But Microsoft has exclusive control over these files. Independent software vendors that license the libraries sometimes make the mistake of overwriting files at installation time, but Microsoft routinely overwrites them when you install its applications. We've come to expect that practice as a given.
In short, the answer is that DLL hell exists only because Microsoft originated and perpetuated it. So it's ludicrous for Microsoft to boast that it has devised a way for developers to get the DLL hell out of Windows. DLL hell is Windows.
Nicholas Petreley is a computer consultant and author in California. He can be reached at firstname.lastname@example.org.