Compatible version module loading

Details Compatible version module loading Compatible version module loading

1999-12-16

2003-12-02

Dam, Tuan Q. (Department: 2122)

Data processing: software development, installation, and managem

Software upgrading or updating

Plural version management

C717S168000, C717S166000, C717S169000, C717S174000, C717S177000, C707S793000

Reexamination Certificate

active

06658659

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to systems and methods for loading software. More specifically, the invention relates to systems and methods that are used by a program loader to manage the compatibility of software programs by detecting and processing version information.
BACKGROUND OF THE INVENTION
In a computer system, software programs are frequently loaded into memory for subsequent execution. The loading process is typically performed by a program loader and may be initiated from different locations in the system including internal API calls or from applications or command line programs. Typically, a given program specifies the name of the program to be loaded. From this point, the loading process can be divided into two parts. The first is locating the program file to be loaded and the second is loading the program. To locate the program file, the loader searches through the file system according to a search path.
The search path is a consistent searching mechanism for finding one or more program files to be loaded. The search path may be defined according to the names of the directories to be searched when the loader retrieves a program. For efficiency, the search path may limit the amount of searching to a subset of the entire file system. In one conventional approach, the loader limits the search path to one or more eligibility lists. The eligibility lists are typically defined in terms of the file names and the order in which the entries within the directories are listed.
FIG. 1
illustrates a search path
100
suitable for illustrating a common searching methodology of conventional loading mechanisms. The path
100
includes libraries
102
,
104
and
106
. The libraries
102
,
104
and
106
may represent separate directories, partitioned data sets or disk drives, for example. The libraries
102
,
104
and
106
each contain a different version of program P and program Q. More specifically, the libraries
102
,
104
and
106
contain versions P 1.3 108, P 1.2 112 and P 1.1 116 respectively. Similarly, the libraries
102
,
104
and
106
contain versions Q 2.1
110
, Q 2.2
114
and Q 2.3
118
respectively.
The loader would typically search down the search path
100
in the order in which the directories and entries were listed. The loader would select the first program of the correct name that it found. When two programs of the same name exist in the search path, the loader would select the first program of the correct name that it encountered. For example, in a search for program P where the loader searches from left to right through the search path
100
, the loader would always select P 1.3 (
108
) for loading. Thus, in this example, the most recent version of the program would be loaded. Similarly, when looking to load program Q, the loader would always load Q 2.1 (
110
), which corresponds to the oldest version of the program. In this case, copies of the programs P and Q residing in the center
104
and rightmost libraries
106
, or any other libraries located subsequent to
108
and
110
in the search path
100
, would be ignored by the loader.
Many operating systems are developed and designed independently of the software applications running on them. In addition, a given software application is typically developed independently from other software applications running on the operating system, including those which it interacts with. Further, many operating systems and applications contain numerous subparts, which may be characterized as separate modules or programs. Together the modules or programs comprise the operating system or application. In the case of very large operating systems or applications, these modules should be developed somewhat independently of one another, by different groups of software engineers and programmers, for example. Software operating systems or applications are continually updated and released as new specific versions. As new versions of software operating systems and applications are released, they are loaded onto computer systems and are expected to be compatible with other software installed on the computer. In many cases, the new software requires particular versions of other programs that it interacts with. The loading and searching strategy of
FIG. 1
is often inadequate since it always loads the first program according to name, regardless of compatibility with newly released software.
Modem computer systems typically run many different software applications. Accordingly, it is common for different versions of a program to be required by multiple software applications (e.g., clients) developed at varying dates. In an environment where different versions of a program are required, the above loading and searching strategy is also inadequate. This is because it will always locate the first program in the search path having desired name, regardless of version requirements for the different software applications.
Other searching methodologies may vary the searching order. This may be done by overriding the system wide eligibility lists. By way of example, the user may change the left to right order of the libraries
102
,
104
and
106
. Alternatively, the user may specify one or more substitute libraries to be used in place of the system wide eligibility lists. Despite these changes in the order in which the programs are encountered by the loader during searching, the changes do not address the inability to load anything but the first named program in the list encountered, regardless of version appropriateness to the software application being loaded. In addition, changing the system wide eligibility lists is not always possible or desirable to other functions requiring use of the eligibility lists. Further, the resulting override is often cumbersome, error prone and thus undesirable for support personnel.
Current searching methodology may include refining the eligibility lists in which the search progresses. More specifically, a search may be refined by a searching criteria. For example, in conventional UNIX loading, the eligibility lists are determined by one or more environment variables, i.e. PATH and LD_LIBRARY_PATH. While increasing searching efficiency, this searching methodology is still inadequate since it will retrieve the first version of the program encountered, regardless of version adequacy. In other words, alternate, and potentially better suited, versions of the program down the search path
100
are not selected.
The loading process may be invoked at run time or at any time prior to execution. In one conventional approach, an application is loaded at run time together with code that is shared between multiple applications. For example, a dynamic linked library (DLL) may be used. The DLL provides code for common resources and functions to be shared between multiple applications. The shared code may be responsible for common actions such as open, disconnect, etc. During loading, memory addresses for DLLs are established. Typically, accessing the shared code of the DLL requires an application to provide an established set of arguments. Once the proper arguments are entered, an address for the functions that the shared code is to perform is returned to the application.
Often there is no mechanism to check whether the proper arguments are being sent to the DLL. A new version of an application may supply different arguments than a previous version (e.g., a new version supplies two arguments for a particular function, while the previous version supplied four arguments in a particular order). As a result, the DLL may not be able to handle the new version; e.g., it may treat improper arguments as proper arguments. Regardless, the application will not receive the desired result from the DLL. In addition, because the problem is encountered at run time, the error is usually not detected until the application is executed, after considerable resources have already been expended.
Some large and complex software products such as network router operating systems have minor bugs that only show u

Affiliated with

Also associated with

Rating

Compatible version module loading does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Compatible version module loading, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Compatible version module loading will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3125171