RAM has historically been an expensive commodity, so Microsoft has always designed Windows to be frugal with memory. (Well, if not frugal, at least to gobble it with something less than the conspicuous consumption of a Roman Caesar.)
One way of conserving memory is to share the image of a DLL loaded by one process with other processes. This DLL sharing can cause no end of headaches, as I'm sure you're aware. For instance, a DLL installed by an application might be a version that lacks a function used by another application. If the second application launches after the first, it links to the DLL image that's already in memory. When it makes the ill-fated call to the missing function, the result is generally not pretty. It could be a "Dr. Watson" error or a general protection fault or even a bugcheck (Blue Screen of Death).
Nowadays, memory is much less expensive and reliability is much more important, so Microsoft is trying to reverse course on DLL handling to permit loading multiple versions of the same DLL. This uses more memory and disk space but it reduces compatibility errors.
Microsoft uses the term assembly to refer to common blocks of code such as DLLs. An assembly designed to run with multiple versions is called a Side-by-Side (SxS) assembly. Only two DLLs in Windows Server 2003 and XP are SxS assemblies:
Two DLLs may not seem like much of a revolution, but these two are used by many applications and are potential sources of compatibility problems thanks to the use of themes in the new interface. By permitting a previous version of these two DLLs to run at the same time, applications are much less likely to experience compatibility issues. Look for an expansion of the number of SxS assemblies in future versions of Windows.
An earlier multiple-version DLL workaround is still supported in Windows Server 2003. This workaround lets you flag an executable so that it loads its DLLs from its own directory instead of somewhere else in the path.
Local loading is enabled by building a zero-byte file with the same name as the executable but with a .local extension. For example, an executable with the name Zanzibar.exe would have a local DLL flag file of Zanzibar.exe.local.
When the operating system sees the .local extension, it loads any linked libraries from the same folder, if they reside there. Otherwise, it links to the images of the DLLs in memory, if they are already loaded.
An XML file called a manifest defines how an executable treats an SxS assembly. The manifest file sits in the same directory as the associated executable. It has the same name as the executable with a .manifest extension. The File Migration Wizard, Migwiz.exe, is an example of an application that uses an SxS assembly. It makes calls to the Common Controls library.