The present invention relates to dynamic link library modules in a computer system and more particularly to a system for reducing conflicts that arise in loading these modules as required by computer applications.
As described by Jeffrey Richter, "Advanced Windows" (Microsoft Press, 3d ed. 1997), Dynamic link libraries serve as the cornerstone of computer operating systems such as Microsoft Windows and IBM OS/2. A dynamic link library, or DLL, is a computer code module that contains functions to be linked with application code at run time. In contrast to a standard programming library, whose functions are linked into an application when the application's code is compiled, a DLL may be loaded and linked to an application at run time, and then unloaded when no longer needed.
A DLL usually consists of a set of autonomous functions that any application can use.
These function are typically those that the application alone could not handle, such as special dialog box controls. There is usually no support code for processing message loops or creating windows within DLLs. Rather, a DLL is simply a set of source code modules, with each module containing a set of functions. These functions are written with the expectation that an application (EXE file) or another DLL will call them.
In 32-bit Windows operating systems such as Windows NT, Windows 95 and Windows CE, for instance, all of the functions in the Win32 API (application programming interface) are contained in DLLs. These DLLs include, for example, KERNEL32.DLL, which consists of functions for managing memory, processes, and threads; USER32.DLL, which consists of functions for performing user-interface tasks such as window creation and message sending; and GD132.DLL, which consists of functions for drawing graphical images and displaying text.
In the 32-bit Windows environment, for an application or another DLL to call functions contained within a DLL, the DLL's file image must first be mapped, or copied from some data storage device such as a disk drive, into the calling process's address space, by either implicit load-time linking or explicit run-time linking, as discussed more below. Once the DLL's file image is mapped into the calling process's address space, the DLL's functions are available to all the threads running within that process. Another process running at the same time will not have access to the DLL and its functions until the DLL is also mapped into the other process's address space.
In contrast, in the 16-bit Windows environment, when a DLL is loaded, the DLL becomes part of the operating system. The DLL exists in common memory space in order to reduce memory use. Therefore, after the DLL is loaded, any and all of the applications currently running have immediate access to the DLL and its functions.
In any Windows operating system, each module loaded into a process's address space is assigned a unique instance handle or module handle used by the operating system to refer to the module. The actual value of the module handle is the base memory address where the operating system loaded the module into the calling process's address space.
A DLL's file image may be mapped into the address space of a calling thread's process in one of two ways, either implicitly linking to functions in the DLL or explicitly loading the DLL. To implicitly link DLLs, a linker embeds information into the header of the application's EXE file indicating the name of DLLs containing functions that the EXE requires. When the operating system loads an EXE file, the system examines the contents of the EXE file image, such as the header of the EXE module, to determine which DLLs must be loaded for the application to run. The system then attempts to map the required DLL file images into the process's address space. If the system cannot locate the DLL, the system displays an error message and terminates the entire process. With implicit linking, any DLL file images mapped into the process's address space are not unmapped until the process is terminated.
Alternatively, to explicitly link a DLL's file image into a process's address space, one of the process's threads must call the LoadLibrary or LoadLibraryEx function at run-time. These functions locate a file image on the user's system and attempt to map the DLLs' file image into the calling process's address space. If the DLL could not be mapped into the process's address space, the function returns a NULL or other value indicative of an error.
According to existing module load search rules in the Windows operating system, when the system receives a request to load a DLL module, the system first makes one or more preliminary determinations. In the 16-bit Windows environment, the system first determines if a DLL module having the same name as the requested DLL is already loaded into the common memory space. If so, the system completes the load process by returning the handle of the existing module, thereby preventing two modules of the same name from being open at the same time. In addition, in any Windows environment, the system determines if the requested module is fully qualified with path information. If the module is fully qualified, the system attempts to load the module from the associated path. If the module is not qualified, however, the system searches for the module in the following locations:
In the 32-bit Windows Environment:
1. The directory from which the application (EXE image) loaded PA1 2. The process's current directory PA1 3. The Windows system directory PA1 4. The 16-bit Windows system directory (for Windows NT only) PA1 5. The Windows directory PA1 6. The directories listed in the PATH environment variable PA1 1. The current directory PA1 2. The Windows directory PA1 3. The Windows system directory PA1 4. The directory from which the application (EXE image) loaded PA1 5. The directories listed in the PATH environment variable
In the 16-bit Windows Environment:
Unfortunately, this existing module search and load logic is deficient for several reasons. Principally, the existing logic searches for an unqualified module file and may therefore locate and load different versions of the same file at different times. As noted by Windows expert Brian Livingston in the Sep. 2, 9 and 16, 1996 issues of InfoWorld, Microsoft and other vendors provide a number of shared DLLs with their applications, and different versions of these DLLs may have the same name. When a user installs a new application that also uses one of these DLLs, the application may install a version of a DLL that is older or different than the one the other applications support. Because one version of a DLL may not have a programming call that a another version of the same-named DLL supports, conflicts may arise.
For example, Mr. Livingston states that the DLL called "OLE2NLS.DLL" is used by Microsoft Office 4.0, 4.2, 4.2c, 4.3, 4.3c, Microsoft Excell 5.0, 5.0c, Microsoft Word 6.0, 6.0a, 6.0c, Microsoft PowerPoint 4.0, 4.0c, Microsoft Project 4.0, and Microsoft Visual FoxPro 3.0 is Version 2.01. However, according to network analyst Michael Green of Paranet Inc., in Houston, Tex., Microsoft Office 4.3c cannot use OLE2NLS.DLL Version 2.02.
Additionally, the existing module search logic is not versatile. The existing logic may attempt to load a particular DLL module when in fact the application or the end user requires another module to be loaded instead. For example, the "OLE" (object linking and embedding) application includes hard coded DLL paths. However, when running the OLE application, a user may wish to use some other DLL version. Unfortunately, existing module search logic will not permit variance from the hard coded path. As another example, the "ODBC" (open database connectivity) application regularly loads modules twice, once based on a qualified module name and once based on an unqualified name. ODBC will then use the more recent version of the two modules. A user, however, may wish to use the older version module. Again, though, the existing module search logic will not permit this variance.
Still further, in the 16-bit Windows environment, it is often necessary to load multiple versions of the same-name DLL module, in order to enable several different applications to run at once. Therefore, an operating system that prevents two modules of the same name from being open at the same time may give rise to additional conflicts, possibly preventing one of the applications from running.
A need therefore exists for an improved system for managing DLL modules that will overcome the foregoing deficiencies.
USPTO Backgrounds
USPTO Backgrounds