Microsoft promises end to 'DLL hell'

The Redmond, Wash.-based software company is hoping to end what has become known as "DLL Hell" by building into Windows Server 2003 a system to solve an incompatibility problem with the libraries, which are software modules that can be shared by different applications.

Problems typically occur when an application is installed that uses an updated version of a DLL. If that particular DLL is already being used by another application, and if the original application cannot work with the updated library, then the user gets an error message.

The Windows operating system and Windows applications have no notion of DLL version numbers, so the problem can be difficult to track down.

Historically, components were shared because disk space and memory were expensive. In the past few years, though, hard disk and memory prices have dropped dramatically, and disk space is no longer at a premium. Nevertheless, as applications have increased in size and in modularity--not so long ago, many applications were entirely self-contained in a single EXE file--the DLL-sharing issue has not been addressed, and the problem has grown.

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.

"This is a classic problem," Ivo Salmre, a manager for .Net and developer tools and technology at Microsoft, told ZDNet UK. "We have been beaten over the head about this for years now. You ship an application that uses component A. Someone else writes an application that also uses component A, but installs a newer version, and this breaks the first application."

Microsoft .Net 1.1, which will be integral to the new Windows Server 2003 operating systems, will support what the company calls "strong binding," said Salmre. "Strong binding means an application or component can bind to a specific version of another component, so you can reuse components or use them in isolation."

.Net 1.1 will provide Windows Server 2003 operating systems with what Microsoft calls a "global assembly cache." This cache is a repository for all the .Net components that are shared globally on a particular computer.

"When a .Net component is installed onto the machine, the global assembly cache looks at its version, its public key, its language information and creates a strong name for the component," said Salmre. The component is then registered in the repository and indexed by its strong name, so there is--in theory at least--no confusion between different versions of the same component, or same DLL.

Windows Server 2003 will also use rules to make sure that an application finds the right component (and version thereof). The system will first look for a local version of the component, and will then look in the cache to find an exact match for the strong name of the required component. Failing that, the system will use heuristics--calculating the probability of a match by looking at characteristics--to find the next best component. But by default, an application will always run against the component that it was built against and tested against. Administrators will be able to override these rules for exceptional cases.

Another feature of Windows Server 2003 will be that .Net components will have no registration policy. "This means it will be easy to take a .Net component on server and copy to another server," Salmre said. Microsoft is calling the feature "xcopy deploy," after a command used in DOS to copy capability files, directories and even whole drives from one destination to another.

"It is good for scaling out--it means you can copy applications instead of reinstalling them," said Salmre. "The whole process becomes much simpler."