Taming DLL Hell

Three problem-solving features in Windows 2000 might benefit you more than any other technology in the OS. Windows File Protection (WFP), side-by-side (S*S) components, and DLL redirection can help systems administrators fight DLL Hell, an annoying problem in Windows that prevents two or more applications that share components from operating independently of one another. Win2K's new features go a long way toward eliminating DLL Hell.

The Road to DLL Hell
DLLs and other shared components are modular, reusable code libraries that a calling application can load on the fly. However, DLLs, OLE custom controls (OCXs), and similar modules can create problems for enterprises that deploy many applications on Windows desktops. The problems' root is the shareable nature of DLLs and other Windows application components such as COM controls. When you upgrade a Win32-based DLL, an OCX, or a COM component, you expect the component to maintain backward compatibility. When you upgrade a component or library that multiple applications use, you expect all those applications to continue to operate.

This compatibility often doesn't happen. In some cases, when you upgrade a component, a dependent application fails the first time it tries to use the component's new version. The problem is exacerbated when software vendors, including Microsoft, ship new versions of shared components with their applications. When you install the new application, it upgrades the shared components. Then, other applications crash when they try to use the altered components. This situation is DLL Hell.

Keeping Track of Components
In Windows NT 4.0, DLL Hell is hard to prevent. The best strategy is to try to avoid the problem. In many cases, enterprises need to separate certain applications from one another so that the applications don't try to share .dll files and other components. However, this separation limits Windows' flexibility and adds to an NT-based infrastructure's total cost of ownership (TCO).

Win2K and NT 4.0 use reference counting (i.e., refcounts) to keep track of how many applications depend on a particular shared component. Reference counting is a fragile mechanism because it relies on each dependent application to correctly add to and subtract from a component's reference count when the application installs or uninstalls the component. Not all applications perform this operation or perform it correctly. Reference counts for shared DLLs and other components reside in the Registry under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\SharedDLLs key. If the shared component is a COM component, the component uses its globally unique ID (GUID) to register its location in HKEY_CLASSES_ROOT\CLSID and HKEY_CLASSES_ROOT\Interface. The HKEY_CLASSES_ROOT\CLSID entry specifies the COM component's location in the file system (a path to the component typically resides in the InProcServer32 Registry value). An application that calls a particular COM component looks in the Registry to locate that component. The calling application uses the component's GUID, which refers to an interface within the component or the component's programmatic identifier (ProgID), to locate the key in HKEY_CLASSES_ROOT\CLSID that describes the component in the Registry. The application then locates the DLL, EXE, or OCX component that holds the functionality the application requires.

If the component isn't COM-based (e.g., a library of Win32 functions), an application uses a different process to locate and load the file that the application needs. In many cases, applications rely on a search process that includes looking first in system memory, then in \winnt\system32, then in the application's directory, and then in any defined path on the system. In NT, applications that you purchase or develop install most shared components by default in \winnt\system32.

For example, suppose you purchase and install application A, which installs version 1.0 of comctrl32.ocx to \winntsystem32 on all your workstations. Six months later, you install application B, which includes version 2.0 of comctrl32 .ocx. The setup program for application B notices version 1.0 of the OCX and upgrades it to version 2.0, overwriting the previous version. Although you expect application A to continue to work using version 2.0 of the new component, that compatibility often doesn't happen. Frequently, application A fails and displays a message about an entry point or ordinal that the program can't find or a method that it doesn't support. When this situation occurs, you have two choices. You can decide that applica-tions A and B won't exist on the same machine, or you can upgrade application A to support component version 2.0. Such an upgrade can be difficult if you've deployed application A on 50,000 desktops or the application's developer is no longer in business and you don't have the source code. Fortunately, Microsoft recognizes the difficulty that this problem causes for enterprises and tries to correct the problem in Win2K and Windows 98 Second Edition (Win98SE).

Windows File Protection
Win2K and Win98SE include WFP, a process that runs in the background on every Win2K server and workstation. WFP monitors the system files that Win2K installs in \winnt\system32. If a user or application replaces a protected file with a different version, WFP quietly restores the overwritten file with a copy of the original that the system has held in a cache (by default, the cache is in \winnt\system32\dllcache). The protected-file cache includes several Microsoft-provided shared components (e.g., Microsoft Foundation Class Library—mfc.dll, common controls library—comctrl32.dll). For more information about utilities that operate within WFP, see the sidebars "The System File Checker," and "File Signature Verification," page 84.

To qualify for Win2K logo certification, an application must not include a protected component. This requirement prevents application developers from distributing different versions of Microsoft-provided components in a way that could break other dependent applications. However, if you have an application that relies on shared components other than those that Microsoft provides—or an application that relies on a different version of a Microsoft shared component from the one that Win2K includes—WFP doesn't provide much, if any, relief for you. You might find that S*S components and DLL redirection are helpful alternatives.

S*S Components
In Win2K, you can take several approaches to solving the DLL Hell problem. One approach involves a programming change. If you or someone in your company has written COM or Win32-based applications for your environment and you plan to deploy Win2K Professional, consider using S*S components. If you have existing applications that you need to get working immediately, DLL redirection might be the way to go.

You can use S*S components, which isolate components to a particular application, if you're a developer who is writing a new application or a set of shared components for Win2K. The isolation that S*S offers gives you the benefits of DLLs and the advantages of statically linked libraries. S*S components can exist on a Win2K system in which different versions of the component might also exist. A shared component can run at the same time that a different version of the component runs elsewhere on the same machine.

When you write Win32 or COM components that are S*S compatible, you need to recognize that some applications will require different versions of your component. All of a component's state information (i.e., information related to the component's data structures and file or other memory resources) must be private. To accomplish this privatization, you need to take specific steps with your code when you write and install it.

   Previous  [1]  2  Next