- 1 Pivotal Container Service Packs Plenty of New Features in PKS 1.1 Update
- 2 Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years
- 3 OpenStack Open Infrastructure Pilot Projects from A to Z
- 4 U.S. Supercomputers Lead Latest Top500 Performance Ranking
- 5 Dell EMC Enhances VxBlock, VxRail Hyperconverged Infrastructure
The Way Out of Your Private (DLL) Hell
The concept of dynamic linking between shared software components in Windows was supposed to provide significant benefits by saving disk space and precious memory (since only single instance of software component was needed by many applications) and by simplifying software fixes and maintenance (problems could be easier isolated and fixed, since a number of factors in a troubleshooting process was limited ). However, as the real life proved, these advantages were frequently outweighed by additional problems, introduced by numerous copies of DLLs, many of them incompatible with each other, loaded by multiple programs into their own separate directories or overwriting ones existing in system folders during installations. And finally, Microsoft came up with the design which minimizes impact of so called "DLL Hell" (although it does not eliminate it - check http://www.swynk.com/friends/rice/DLL1.asp) which was one of the leading reasons of developing smoking habits and high coffee consumption among Windows system administrators, developers, and users alike.
In general, DLL related problems can be divided into two categories - first one caused by overwriting shared libraries stored in the system area with incompatible versions, second one by installing multiple copies and versions of DLLs within each program owns directory. Applications by default attempted to use shared DLLs, which made them dependent on the sequence in which programs were run.
The solution to the first problem is based on Windows File Protection, which prevents the update of system DLLs by non-signed versions. These protected DLLs (approximately 2,800 in Windows 2000) are residing in winnt\System32 folder, and if overwritten, are replaced back almost immediately (via directory change notification event) by the original ones, backed up in winnt\System32\dllcache folder. This however, does not apply to replacements with signed components, such as ones provided with service packs.
The second problem can be resolved in one of two ways. The first one has to be applied during development stage - a developer is required to register a DLL with the reference to a directory, where its copy should reside. This way, the application will load its own private copy.
The second solution is more practical from Windows 2000 administrator point of view, who typically does not have any input in the development process. If an application requires its own set of DLLs, first they have to be loaded in the same directory as the application executable. Next step, involves creating an empty file which has the same name as the executable, plus the extension ".local" (e.g. appname.exe.local). The mere presence of this file will force the application to search for required libraries in the local directory, before following the path set by environment variable. This method works even if the DLLs path is hardcoded within an application. Unfortunately, this cannot be done with all DLLs, those listed under HKLM\ SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs are always pulled from the system32 folder.
IT Solutions Builder TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD
Which topic are you interested in?
What is your company size?
What is your job title?
What is your job function?
Searching our resource database to find your matches...