previousupnext

9 Configuration Management

This section outlines the dependencies of LeapHeap on other products, and points out the events that require a reinstallation of LeapHeap.

LeapHeap's major dependency is, obviously, on the Microsoft heap functions API. It also relies on several other system functions, some of them undocumented. Strangely, those low-level features seem less subject to change than certain higher-level technologies which are specified. As a result, a single version of LeapHeap serves for all versions of Microsoft Windows between NT 4.0 Service Pack 1 and Windows Server 2003.

If the software build of a computer is changed, the effect on LeapHeap is able to be deduced from the information in other sections of this guide. The most common events are described next:

Whenever a new application is loaded onto the machine, or an existing application upgraded, replacement of system DLLs (i.e. any DLL in the Windows system directory) should be monitored. If a system DLL is overwritten, LeapHeap should be reinstalled, regardless of whether there is a copy of the DLL in the LeapHeap directory (the modified DLL may have changed from one that doesn't make raw heap calls into one that does). The LeapHeap registry installer does not need to be used. First remove the active files (all DLL files except leapheap.dll) from the LeapHeap directory; this must be done in case a DLL has been changed from one that makes raw heap calls to one that doesn't. Then run the LeapHeap file installer. This procedure may not be strictly necessary if the new application is not going to run with LeapHeap, but it is desirable to keep the LeapHeap directory consistent with the system directory. If application DLLs are configured on the new 'side-by-side' basis, a different approach is needed, outlined later.

The same considerations apply to an update of Windows NT itself, which may be assumed to involve the alteration of system files. The LeapHeap registry installer should be applied in this event, as the update may have altered the KnownDLLs registry key. In either case it does no harm. The installer will report that it has not created a registry restoration file; this is good, the original 'RestoreRegistry.reg' in the LeapHeap directory is the one to keep.

When the application of interest is managed on a side-by-side basis, with old versions of system DLLs held privately in the directory of the application, a written plan should be made before installing LeapHeap. The goal is to copy DLLs in and out of the system directory until the set that the application is configured for is achieved. Then LeapHeap is installed, to derive a compatible set of system DLL copies. The system directory is restored to its original state and the application executable copied to the LeapHeap directory. Each such application requires a separate LeapHeap directory.

For bulk installation of LeapHeap over a network, it is necessary for all machines to have the same software build. If that condition holds, then once the active files have been created on one machine they can be distributed universally.