Microsoft Corporation is proactively seeking to put an end to the Achilles Heel of Windows reliability, "DLL hell," a problem that has faced the company since the days of Windows 3.1. Various versions of Windows, including Windows 2000 and Windows Me, have added features to combat the problem, but the release of Windows "Whistler" in 2001 should be the final piece in the puzzle. It's all due to a technology that Microsoft calls "Fusion" internally, but it's unlikely you've ever heard of such a thing, despite the fact that it's been embedded, in some form, in various versions of Windows beginning with Windows 98.
The "DLL hell" problem, as it's become known, is the number one source of fragility in Windows today: The user installs programs and, over time, the system become more fragile. This is due to the decades-old design of Windows, which relies on common shared libraries called DLL (Dynamic Link Libraries) and other shared resources, a scheme that dates back, literally, to the first days of Windows. When Windows was first created, its designers faced the problem of creating a multitasking, graphical operating system that would run on PCs with few resources. So RAM and disk space were at a premium. One of the initial goals, then, was to share as many resources as possible, so that applications wouldn't need to load duplicate copies of code into memory. Likewise, these resources could sit on the disk in one location, saving space. It was a good idea for the time. But as Windows grew in complexity, and users' computers grew into what was once the province of workstations, shared DLLs started to make less sense. And more importantly, they started to become a problem.
It's likely that everyone reading this has run into DLL hell, though you may not realize it: You install X application, which overwrites a key system DLL such as COMCTRL32.DLL, with a different version. Yet the version that was already on your system was newer, or at least different, and it contained routines needed by Y application, which suddenly refuses to work. Or, in a worse case scenario, the DLL was needed by Windows, and the version that's now on the system is incompatible with your version of Windows. This type of file replacement happens all the time, and it's a huge problem, one that Microsoft has been aware of for some time.
To its credit, Microsoft has been working on the problem for some time as well. In Windows 98 Second Edition, the company introduced its first "Fusion" technology, "side by side DLLs" (code-named "Hydrogen"), a limited solution where an application could optionally install all or some of its shared library files into a private location, so that same name DLLs could exist "side-by-side" in the system and work together, each serving particular applications. This approach, of course, required the application to implement the feature, and since it was specific to Windows 98 SE (and future releases), few software developers took advantage of it. Windows 2000 implements Windows File Protection (WFP), which protects key system files from being overwritten; this feature is also in Windows Me, where it's known as System File Protection (SFP).
Going forward, future generations of Fusion will be introduced in Visual Studio and Whistler, the point release to Windows 2000 that Microsoft will release in the first half of 2001. Fusion 2.0, as it's known, will ship with Visual Studio 7 and COM+ 2.0, both due in the first half of next year. Fusion 2.0 will focus on COM+/Web server needs. Then, in Whistler, Microsoft will introduce Fusion 2.5, which supports COM+ 2.0, COM classic (as it's known by Microsoft), and Win32 components. Fusion 2.0 is focused on consumer needs and it will provide device driver, OS install, and OS update capabilities.
I've got a lot more information about Fusion, which I'll post as a Technology Showcase on the SuperSite for Windows next week
