Share via

DotLocal (.local) Dll Redirection

  • Article

If you are developing software on Microsoft Windows platform, you probably have heard of the term “Dll Hell”.

 

“Dll Hell” happens when two applications install two incompatible versions of a shared dll. Since there is no versioning control for dll in Windows, the second copy may overwrite the first copy. As a result, the first application will not function any more.

 

Since LoadLibrary will search the application directory first, among other things, a workaround for the “Dll Hell” is to carry the “shared” dll with the application, which effectively makes the “shared” dll private.

 

But there is another kind of “Dll Hell” which can not be easily worked around. And this is COM.

 

If two incompatible versions of a COM server is installed and registered, even the two COM servers may reside physically in different location, there is only one place to register the COM server. Hence only the latest registered COM server will be activated. This is essentially another manifest of the “Dll Hell” problem.

 

To workaround this problem, a “ Dll redirection ” mechanism is introduced in Windows 2000.

 

For an application foo.exe, if there is a file foo.exe.local exists, Windows will first look at foo.exe’s application directory, before start the regular dll search. To mitigate the COM problem, the redirection applies both to full path dll loading, as well as partial name loading.

 

In Windows XP and Windows Server 2003, the behavior of DotLocal(.local) is altered a little bit. If foo.exe.local is a file, Windows will keep the same behavior as Windows 2000. But if foo.exe.local is a directory, Windows will search foo.exe.local directory for the dll, instead of the application directory.

 

In Windows XP and above, Windows (via fusion team) introduced a new side by side programming model for application isolation. This model essentially is the same model introduced in .Net framework (with no surprise, as both models are designed by the same team, with small variances based on the need of the specific product). In Windows the metadata is stored in a XML file (typically called a manifest file), as opposite to the assembly binary in .Net framework.

 

Since the side by side isolation model is a logic evolution of the DotLocal(.local) dll redirect, in Windows XP  and Windows Server 2003, when there is an application manifest (foo.exe.manifest, or a Win32 resource of ID RT_MANIFEST, Type 1), the DotLocal dll redirection is disabled.

 

It turns out the DotLocal(.local) dll redirection has a huge value in private testing. When developing a new version of the COM server, you don’t really want to mess up with the one in system. If you can redirect the dll to a private version for a set of specified applications, and let other applications use the system one, it will be the best of all the world. And DotLocal(.local) provides exactly that, with the exception that if the application has a manifest, DotLocal(.local) dll redirect is disabled.

 

Realizing the value of DotLocal(.local) dll redirection in private testing, a change is made in Windows Vista, that when the registry HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options!DevOverrideEnable:REG_DWORD is set to 1, DotLocal(.local) dll redirection will be enabled, even if the application has a manifest.

 

This change is in Windows Vista Beta1 and beyond. It will require a machine reboot to make the change take effect.

Comments