Dynamic link library version negotiation

1

DYNAMIC LINK LIBRARY VERSION
NEGOTIATION

BACKGROUND OF THE INVENTION

(1) Related Application

This application is a continuation-in-part of Ser. No. 154,269, filed Nov. 18, 1993, now abandoned which has been assigned to the assignee of this application.

(2) Field of the Invention

The present invention relates to the field of computer systems and computer software applications. Specifically, the present invention relates to the field of computer program development and execution.

(3) Background

Some programs executed by computer systems are constructed using a particular set of development tools and are translated from a high level programming language to an executable format according to a particular process. For instance, in order to develop a program written in a high level language, such as the C language, a program is first entered into an editor using the C instruction format and the "C program" is then compiled by a compiler program. The compiler program transfers the C instructions into assembly instructions represented as assembly code (often called machine code). The resultant output from the compiler program is called the ".obj file" or object code.

There may be several different object files stored on a disk drive or in a computer's memory and each may represent a different section of the high level program. Therefore, a given C program may reference several object files. Such is well known in the prior art. As the high level program is compiled, object files that are referenced by the program do not have to be compiled again each time. This saves development time.

Several object files may be combined together into a library file or ".lib file." Often used and rarely changed subroutines are compiled into object files and then placed into an object code library file so that they do not have to be compiled each and every time the C program is compiled. This is done in an effort to reduce the compile time of the high level program. If a subroutine is not going to change from one version of the high level program to the next, there is essentially no need to recompile the subroutine for each version of the high level program and therefore the object code library provides the compiled result when needed. In effect, the predefined object code files are "canned" subroutines that have been previously written and compiled and are not expected to change readily.

A linker program is used to link the various object files together and to create a resultant executable file or ".exe file." Therefore, a high level program is compiled then combined with previously compiled files that are referenced by the high level program (if any) and the total is linked to together to create an executable version of the program or "application." The executable file is the file that will be executed by the computer system to perform the instructions that were originally developed in the high level language (i.e., of the C program). The executable file may be referred to as the "executable application."

Also included in the above procedure is a file called the header file or ".h file." The header file contains, among other things, variable definitions and procedure and function definitions that may be incorporated into the high level program by reference. This purpose of the header file is to provide a readily available method of incorporating often used deft

2

nitions into the high level program without requiring the high level program (i.e., the C program) to recite each definition individually. In other words, a group of variable definitions and or procedure or function definitions (that are 5 expected to used by many applications) may be given a common name, such as "<myfiles.h>." Then, where ever the high level program includes a statement, such as the one listed below:

# include <myfiles.h>,

10

the compiler will read the header file for the <myfiles.h> definitions and will incorporate these definitions and/or instructions into the high level program at that point. The result is that the definitions and/or instructions within the

15 <myfiles.h> group will be compiled by the compiler program as if they appeared in the high level program originally at the location where the include statement appears. Use of a header file in the above configuration is also well known in the prior art. In the manner as described above a header

20 file may be viewed as a development tool for the application. Developments have lead to the introduction of Dynamic Link Library files (DLL files or DLLs) which are files that contain executable program code that corresponds to particular subroutines and program sections. Similar to the

25 notion of providing "canned" object files, Dynamic Link Library files provide "canned" subroutines in executable code format that can be called by other applications to perform certain, known functions.

At run time, these subroutines can be directly called by

30 the executable application in order to perform various tasks. Therefore, the DLL must be resident in memory when the application is executed. In other words, at execution time, the resultant executable code that is produced by the linker program from the high level instructions will call certain

35 subroutines for execution that exist within the DLL file. This requires that the DLL be loaded into the computer system's memory (or available for loading) before the executable program is executed. Therefore, before an executable program (created by the high level language) is executed, the

40 DLL is loaded into the computer's memory.

However, as is often the case, the DLL file that is loaded into memory may or may not be completely compatible with the current executable application that calls subroutines located within the DLL file. This problem arises because the

45 DLL file called by the executable file can be updated and altered after the executable program is developed. Therefore, the DLL resident in memory may not be the DLL expected by the application file even though the subroutine names (of the DLL) are the same. Further, the executable

50 program can be altered and developed after the creation of the DLL file that is called by the executable program.

It is important that the DLL file accept and supply the exact data and control interface expected by the executable file or serious errors will develop in the execution of the

55 executable file. Therefore, it would be advantageous to provide a mechanism to insure that the data interfaces between a DLL file and an executable program are compatible. It is further advantageous to provide a system and method for insuring that the DLL resident in memory is that

60 DLL anticipated by the executable application. The present invention provides such capability.

It is further advantageous to be able to insure that a given subroutine within a DLL file and called by an executable file is the same subroutine that is expected by the executable file.

65 The present invention provides such advantageous functionality. It is further advantageous to be able to negotiate which version or revision level of a given subroutine within a DLL 3

file will be used when called by an executable file in the case where there is not an exact match between the preferred version or revision levels but where there is compatibility between the executable and the DLL file in the sense that there is at least one version or revision level in common that each can operate with correctly. The present invention provides such advantageous functionality.

SUMMARY OF THE INVENTION

A mechanism and method of providing version negotiation between a Dynamic Link Library file (DLL file) and an executable application is described. The present invention provides a version identification which is attributed both to a particular DLL file and to a particular executable program. During execution of the application program, it calls subroutines of the DLL. Initially, the executable program calls the DLL to specify the version number of the DLL preferred by the application program. If the DLL can support this preferred version, then execution continues. If not, then a negotiation process occurs in which the DLL provides the application with a list of the version numbers that the DLL can support. The application looks at each version on the supported list until it finds one with which it can execute. If none of the versions match, then the application program executes an error trap operation and halts normal execution immediately.

The present invention advantageously utilizes version tables both within the application program and within the DLL to verify compatibility of the preferred version as well as to negotiate compatibly if the preferred version is not supported. The application program makes an initial call to the DLL to specify the DLL version with which it prefers to operate. The DLL compares this preferred version number to the version numbers that it supports, which are in a table within the DLL. This table is called the supported DLL version table. In the case where the preferred version matches one of the entries in this table, then the DLL returns an "preferred version OK" flag to the application program. In this case, the application program goes on with its normal execution. However, if the preferred version is not supported (i.e. its version number is not found in the supported version table), then the DLL returns to the application program a "preferred version not supported" flag and a list of versions that it does support. This list of versions returned comes from the table of supported versions within the DLL. In response, the application program compares this list with the versions with which it is compatible—that is, it looks up each version on this list in a table of version numbers contained within the application program. This table is called the compatible version table.

The present invention preferably advantageously utilizes the header file in order to designate a DLL version identification and a version identification within the application program In addition to the designation of the current version, the header file may contain some or all of the entries for the supported version table within the DLL and for the compatible version table within the application. Any modifications made to the DLL file after the development of the application program will be detected by the present invention, thus preventing run-time errors within the application program caused by such unexpected modifications.

Thus, the present invention insures that there will always be an expected data interface between the DLL and the executable program which relies on the DLL. Further, the present invention prevents a later modified application program from calling an earlier version of the DLL.

4

Further, the present invention supports negotiation of which version or revision level of a given subroutine within a DLL file will be used when called by an executable file in the case where there is not an exact match between the 5 preferred version or revision levels but where there is compatibility between the executable and the DLL file in the sense that there is at least one version or revision level in common with which each can operate correctly.

10 BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the process used to create the application executable file and the DLL executable file from the application source code file, the header file and the DLL source code file.

15

FIG. 2 illustrates the time sequence of the steps used by the present invention in ensuring that the DLL version preferred by the application program is supported by the DLL program.

20 FIG. 3 illustrates the time sequence of the steps used by the present invention in negotiating to see if there is a match between any of the DLL versions supported by the DLL and any of the DLL versions compatible with the application program in the case where the DLL version preferred by the

25 application program is not supported by the DLL program FIG. 4 is a flow chart illustrating the steps used by the present invention to construct a new DLL.

FIG. 5 is a flow chart illustrating the steps used by the present invention to create an application program.

30

FIG. 6 is a logical block diagram of a general purpose computer system suitable for executing the present invention.

DETAILED DESCRIPTION OF THE 35 INVENTION

The present invention includes an apparatus and method for providing a version negotiation capability between a Dynamic Link Library ("DLL") and an associated applica

40 tion program. Within the discussions herein, the "application program" refers to the executable code program that is compiled and linked and is used to execute an application. In the course of its execution, the application program calls subroutines within the DLL. The present invention can

45 operate effectively on a desktop or general purpose computer system. An exemplary computer system is described herein.

In the following detailed description of the present invention numerous specific details are set forth in order to

50 provide a thorough understanding of the present invention. However, it will be obvious to one skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, procedures, components, and circuits have not been described in detail

55 so as not to unnecessarily obscure the present invention. Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations

60 are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring

65 physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored,