CA2162033A1 - Method and apparatus for verifying compatibility between modular components in a computer system - Google Patents

Method and apparatus for verifying compatibility between modular components in a computer system

Info

Publication number
CA2162033A1
CA2162033A1 CA002162033A CA2162033A CA2162033A1 CA 2162033 A1 CA2162033 A1 CA 2162033A1 CA 002162033 A CA002162033 A CA 002162033A CA 2162033 A CA2162033 A CA 2162033A CA 2162033 A1 CA2162033 A1 CA 2162033A1
Authority
CA
Canada
Prior art keywords
provider
component
version
client
indicator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002162033A
Other languages
French (fr)
Inventor
Alan W. Lillich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CA2162033A1 publication Critical patent/CA2162033A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44536Selecting among different versions

Abstract

The invention is a method and apparatus for verifying compatibility between components of a system which share a client-provider relationship. Briefly, according to the invention, a current version of a provider and a compatibility range are defined for each of a version of a client and a version of a provider. A version of a provider specifies an oldest implementation provider and an oldest definition provider. When a client is linked with a particular version of a provider, it stores an identification for that provider, a current indicator for that version of the provider, called a definition provider, and the oldest implementation provider. At runtime, compatibility checks are performed between a client and available versions of the provider(s), called implementation providers, with which it has been linked. For each available version of each type of provider compatibility exists with the client in three situations. First, if the definition provider and the implementation provider are the same version of that provider, then the client and provider are compatible. Second, if the definition provider, i.e. the version of the provider linked with the client, is newer than the implementation provider, then if the version of the implementation provider is no older than the oldest implementation provider specified in the client, the two are compatible, otherwise they are incompatible. Third, if the definition provider is older than the implementation provider, then if the definition provider is no older than the oldest definition provider specified in the implementation provider, then the two are compatible.

Description

~6~33 METHOD AND APPARATUS FOR VERIFYING COMPATIBILITY BETWEEN
MODULAR COMPONENTS IN A COMPUTER SYSTEM

LIMITED COPYRIGHT WAIVER
A portion of the disclosure of this patent document contains material to which the claim of copyright protecffon is made. The copyright owner has no objection to the facsimile reproduction by any person of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but reserves all other rights whatsoever.

FIELD OF THE INVENTION
This invention relates generally to compatibility between various components of a computer system and, more specifically, to checking whether interoperating components are compatible within a specified compatibility range.

BACKGROUND OF THE INVENTION
In a computer system, compatibility between various components, both hardware and software, of the system may be important. A new component or an upgrade of an existing component may be incompatible with other components in a system, rendering the entire system inaccurate or inoperative.
Thus, it is important to have a mechanism for verifying compatibility between components of a system.
Compatibility plays an important role in a client-provider relationship wherein a provider supplies services to a client because it is important that the provider be able to satisfy expectations of the client. A client-provider relationship may exist between two computer software programs, two computer hardware components or between a software program and a hardware component. An example of a client-provider relationship is a relationship between a shared library (provider), that is a collection of routines which can be accessed by other computer programs, and a computer program (client) which accesses the routines in the library.
Typically, as computer programs are modified, upgraded or otherwise improved, new versions of the computer programs are released. To differentiate between different versions of a computer program, a version 2 1 6 2 0 ~ ~ PCT I 594/04983 number is typically assigned to each release of the computer program. Usually, version numbers are assigned such that a newer version of a computer program has a higher version number than an earlier version of that computer program.
For example, if a particular version of a computer program has a version number of 2, then a subsequent version of that computer program may have a version number greater than 2.
Computer programs are typically written originally in source code in a computer language such as C or Pascal, or in an assembly language. To prepare the program for execution on a computer system, a compiler (or assembler ) converts one or more source code modules into an object code file. A compiler (or assembler) is specific to the language used and the computer system on which it will be executed. A linker routine, which is either a separate program or is part of the compiler, combines the object code files into a single output file, known as an "executable" object code file. One or more executables are then loaded together into memory by a loader program, and control is transferred to a start address to initiate program execution.
Typically, in a client-provider relationship between two software programs, it is important for compatibility to exist between the version of a provider such as a shared library linked to a client and the version of the provider (shared library) used during execution of the client. During linking ina client/provider relationship, imports (unresolved external symbols in the client) are resolved to exports from the provider (symbols in the provider that are visible to the client). At link ffme, the provider supplies definitions of symbols (the API) but not the actual implementation of routines and variables (the code). Thus, the version of the provider used at link ffme is called a "definition version".
When a client is executed, the imports in the client are connected to the associated exports in the provider. The connection could be in hardware such as a wire between the two, or in software such as an operating system, a code fragment manager, or other shared library or code manager. At runtime, the provider supplies actual implementation of routines and variables, i.e. code.
Since the API is supplied at link ffme and the code is supplied at runtime, it is important that the definitions supplied by a provider at link time are compatible with the implementation of the provider used at runtime.
In the VMS operating system by Digital Equipment Corp., Inc., typically a version of a provider is designed to be compatible with previous versions, i.e.
a version of a provider is backwards compatible. VMS is a trademark of Digital Equipment Corporation. Thus, a client can be executed using a version of the 21~33 ~ WO 94/2~918 PCTIUS94/04983 provider which is newer than the version with which it was built. However, a version of the provider which is older than the version used to build the clientmay not support features available in newer versions of the provider.
Therefore, a client cannot be executed using a version of a provider which is 5 older than the version used to build the client, because the older provider may not be compatible with the newer version.
In VMS, as shown in "VAX/VMS Internals and Data Structures", version 4.4, Lawrence J. Kenah, Ruth E. Goldberg, Simon F. Bate (Digital Press: 1988), section 21.1.1.2, a provider typically has a revision number comprising a major lO number component and a minor component, usually denoted as "major.minor"
or "major/minor". VAX is a trademark of Digital Equipment Corporation.
When a new revision of a provider contains substantial changes from a prior instance of the provider, then the major number is incremented. However, if the changes are only minor changes, then usually only the minor number is 15 incremented. At link time, the revision number of the provider supplying the definitions is stored in the executable object code. At execution time, the major number of the stored revision number in the client is compared to the major number in the revision code of the provider being accessed to implement the client. If the major number of the revision of the implementaffon provider is 20 less than the major number of the revision number stored in the client's executable object code, then the client and provider are considered incompatible, regardless of whether the two are in fact incompatible.
For example, if the client is linked with a provider having a revision number of 7.1, then it would be considered incompatible with a provider having a major number less than 7 such as 6.5, 5.0, etc.. , but it would be considered compaffble with a provider having a major number greater than or equal to 7 such as 7.5, 8.0, etc...
The backwards compatibility scheme in VMS presents several problems.
First, it discourages a developer of a provider from assigning to a current 30 version of the provider being developed a major number higher than that assigned to the prior version, even though that version may be substanffally different from prior versions of the provider.
Second, in this versioning scheme it is usually desirable to use the newest version of an operating system to utilize features or enhancements unavailable 35 in previous versions. However, the newest version of an operating system is usually compatible with the newest version of a shared library and not compatible with older versions of the shared library. Therefore, clients which were built using newer versions of the shared library on a developer's system -W O 94/2591 ~ 1 6 2 ~ ~ ~ PCT~US94/04983 cannot be executed using the older version of the shared library on an end user's system. Thus, developers are encouraged to maintain old system installations in order to link with the oldest available version of a provider, thereby increasing the number of versions of the provider with which it is 5 compatible. Moreover, older versions of the shared library might be retained just to execute clients which were built with older versions of the shared library.
These older versions occupy memory space which might otherwise be available for other purposes.
For example, consider a situation where two versions of a provider are lO available at link time, an earlier version having a version number of 2.0 and a later version having a version number of 4.2. The 4.2 version has some features which are not present in the 2.0 version and which would be advantageous to the client to use. In order to utilize the advantageous features, it is preferable to link with the 4.2 version. However, since it is unknown which version of a lS provider will be available at runtime, it is also preferable to link with theversion with the most likelihood of being compatible with a version available atrunffme. In this case, since version 2.0 is compatible with versions greater than or equal to 2.0 and 4.2 is compatible with versions greater than or equal to 4.2, version 2.0 is more likely to be compatible with an available version of a 20 provider than the 4.2 version. Thus, in this case, a client has a choice between either utilizing the advantageous features of the 4.2 version or increasing likelihood of compatibility with 2Ø By choosing to increase the likelihood of compatibility at runtime and thus, linking with the earliest version of a provider available, a client foregoes the advantageous features of later versions of that25 provider which are also available and which, may, in fact, be compatible with those earlier versions.
In other operating systems such as OS/2, as discussed in "Inside OS/2", Gordon Letwin, (Microsoft Press: 1988), section 7.11.3, and Windows, version numbers are not used for providers such as shared libraries. OS/2 is a 30 registered trademark of Internation Business Machines Corporation. In these systems, older versions are designed to be compaffble with newer versions and newer versions are designed to be compaffble with older versions. In other words, a version of a provider is designed to be backwards and upwards compaffble with other versions of that provider. This places a burden on 35 developers of the shared library to maintain compatibility even when the changes are extensive and even when the older versions ~nay only be used infrequently.

~ WO 94/25918 216 ~ ~ ~ 3 PCT/US94/04983 SUMMARY OF THE INVENTION
The invention is a method and apparatus for controlling and verifying compaffbility between modular components of a computer system wherein such components share a client-provider relaffonship and a version of a provider used to build the system may be different than a version of the provider used toexecute or run the system. Briefly, according to the invenffon, a provider indicator, a current indicator of a provider and a compatibility range are defined for each of a client and a provider. A provider indicator idenfffies a particular type of provider. A current indicator of a provider specifies that version of the provider. When a client is linked with a version of a provider the current indicator of that provider is stored in the executable client produced, thereby identifying the version of the provider, herein called a "definition provider", used to build the client.
The compaffbility range for the client identifies the range of versions of the provider which can be used to execute the client, i.e. which have an implementaffon which is compatible with the definitions supplied by the definiffon provider. Preferably, the compaffbility range for the client specifies the oldest version of the provider which can be used to execute the client. The compaffbility range for the provider idenfffies the range of versions of the provider which could be used to build a client capable of operaffng with the current version of the provider. Preferably, the compatibility range for the provider specifies the oldest version of the provider which could have been used to build a compaffble client. Preferably, the versions within each of the two compaffbility ranges are older than or equal in age to the current version.
The invention also includes a connector for connecting at runffme the client and the provider which will be used to execute the client, herein called an "implementation provider" to determine compatibility between the client and the implementaffon provider. Compatibility checks are performed between a client and available versions of the provider(s), implementation providers, withwhich it has been linked. For each available version of each type of provider compaffbility with a client exists in three situations. First, if the definitionprovider specified in the client and the implementation provider are the same version of that provider, then the client and provider are compatible. Second, if the definition provider specified in the client is newer than the implementationprovider, then if the version of the implementaffon provider is no older than the oldest implementation provider specified in the client, the two are compatible, otherwise they are incompatible. Third, if the definiffon provider specified in the client is older than the implementation provider, then if the definition WO 94/25918 21~ 2 0 3 ~ PCT/U594/04983 ~

provider specified in the client is no older than the oldest definition providerspecified in the implementation provider, then the two are compatible.
The invention can be used in systems having multiple clients and providers. In that case, for each ciient a list of providers is maintained. For 5 each provider in the list, a current version and a compaffbility range are defined. At runtime, the list can be searched to find a compatible provider, if any exists. Preferably, if more than one compatible provider is found, the "best" is chosen. For example, the best provider may be the most current version of the provider which is compatible, or it may be the version of the 10 provider which is closest to the version of the definition provider.
By defining compatibility ranges for a client and for a provider, the invention provides several advantages. First, the invention permits a client to run with versions of a provider which are older than the definition version of the provider used to build the client. Thus, a client does not have to build only 15 with the oldest version of the provider that it will ever be used with. This provides a developer of a client with flexibility in determining the version of the provider with which to build the client. Additionally since a client may be linked with a version which is newer than the oldest version of the providèr, the client may be able to utilize features or enhancements, in the newer provider 20 which may not exist in the oldest provider. Features or enhancements may be explicitly different from previous versions, e.g. the feature was not available in any form in the previous versions or a new mechanism is used to utilize the feature, or they may be implicitly different, e.g. the performance of an existing feature is enhanced in the newer version. Preferably, a client verifies the 25 availability of explicit features and enhancements.
Second, the invention permits a client to be executed with a provider which is newer than the client, i.e. a provider which is newer than the version of the provider which was used to build the client. Thus, developers of a provider can freely change version numbers of the provider and not affect the 30 compatibility of the client and the provider unless the changes to the provider render it incompatible with older versions of the client. In that case, the compatibility range of the provider changes to reflect the changes in compatibility.

BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

wo 94/25918 216 ~ 0 3 ~ PCT/US94/04983 FIGURE 1 is a symbolic, simplified block diagram of a system which may incorporate the invention;
FIGURE 2 is a symbolic, simplified block diagram of a computer system which may incorporate the invention;
FIGURE 3 illustrates contents of a disk drive of the computer system of FIG. 2;
FIGURES 4A and 4B illustrate contents at the start and end, respectively, of link time of a memory of the computer system of FIG. 2;
FIGURE 5 depicts contents at execution time of a memory of the computer system of FIG. 2;
FIGURE 6 is a flow chart depicting in general the steps of the invention;
FIGURE 7 is a more detailed flow chart depicffng the steps of block 100 of FIG. 6;
FIGURE 8 is a more detailed flow chart depicting the steps of block 102 of FIG. 6;
FIGURE 9 is a more detailed flow chart depicting the steps of block 104 of FIG. 6;
FIGURE 10 is a detailed flow chart depicting steps of block 162 of FIG 9;
FIGURE 11 is a more detailed flow chart of steps performed at block 162 of FIG. 9;
FIGURE 12 shows a provider list which is used when a client is linked with multiple types of providers;
FIGURE 13 is a flowchart of steps of block 102 of FIG. 6 when a client is linked with mulffple types of providers;
FIGURE 14 shows an implementation provider list which is used when multiple versions of a provider are available at execution of a client;
FIGURE 15 is a flowchart depicting preferable steps for determining compatibility at block 104 of FIG 6 when multiple versions of a provider are available at execution of a client;
FIGURE 16 is a simplified block diagram of a primarily hardware type system of FIG 1 incorporating the invention; and FIGURE 17 is a flowchart generally depicffng steps of the invention in a system of FIG. 16.
DETAILED DESCRIPTION OF THE DRAWINGS
Numeral 30 in FIG. 1 generally indicates a system incorporating the invention.
System 30 may be hardware, software, or a combination thereof, and includes a WO 94/25918 216 2 0 ~ 3 PCT/US94/04983 ., --client 32 and a provider 34 connected by a connector 36 such that information from the client and provider can be compared.
FIG. 2 illustrates a computer system 40, comprised of hardware and software, which may be used to implement the invention. Computer system 40 5 comprises a bus 42 interconnecting a processor 44 such as a central processing unit ("CPU"), a memory 46 and a disk drive 48. Many types of computer systems may be used, but in the present embodiment, computer software is usually stored on the disk drive 48 and brought into mernory 46 over bus 42 by the processor 44.
As shown in FIG. 3, prior to linking a client with a provider, this computer software typically includes an operating system 50 such as, for example, Macintosh System 7 or AIX, a compiler 52 such as an IBM xlc or xlC
compiler and a linker 54 such as IBM ld linker. ~acintosh System 7 and AIX are both commercially available. Background information on the Macintosh System 7 operating system can be found in "Inside Macintosh", Vol. VI, Addison-Wesley Publishing Co., Inc., 1991, and background information on the AIX
operating system can be found in "Calls and Subroutines, AIX Version 3 for RISC System/6000", Vols. I - VI, IBM, 1990, 1991. The IBM xlc compiler is described in "XL C User's Guide, AIX Version 3 for RISC System/6000", chapters 2-4, IBM Corporation, 1990, the disclosure of which is hereby incorporated by reference. AIX and RISC System/6000 are trademarks of International Business Machines Corporation. The ld linker is discussed in an article entitled "ld Command" published in IBM, "R6000 InfoExplorer", (CD-ROM 1991), the disclosure of which is herein incorporated by reference.
Compiler 52 and linker 54 may also be part of the same computer program, rather than separate programs. Moreover, the compiler 52 and the linker 54 may be on a different computer system 40 than the client 32 and providers 34.
The computer software also includes one or more client programs 60 and one or more provider programs 62. For example, a client program 60 may be an application program that accesses routines in a shared library (a provider 62).
This software may also be located in memory 46. A client program 60 is typically in object code format produced by passing source code for the client through a compiler which generates object code as its output. A provider program 62 may be in executable object code format or it may be a definition file which is specially built to provide definitions to use when linking. For example, object code modules of a shared library may be linked together to form a provider program 62 which is executable object code that is then linked with wo 94/25918 21 fi 2 0 3 ~ PCTIUS94/04983 client program object code 60 to form executable object code 64 of the client program.
In addiffon, the computer software may include source code (not shown) for the client programs 60 and the provider programs 62. The source code for the client is converted into object code 60 by a compiler. The source code for aprovider, if it is not a definiffon file, is converted into executable object code by a combinaffon of a compiler 52 and linker 54.
There are numerous formats for executable object code files. One format for executable object code files is known as XCOFF. XCOFF is described in the following articles published in IBM, "R6000 Explorer" (CD-ROM 1991):
"a.out File Format", "Optional Auxiliary Header for the a.out File", "Section Headers for the a.out File", "Raw Data Secffons for the a.out File", lS "Special Data Secffons for the a.out File", "Relocation Information for the a.out File", "xcoff.h", "filehdr.h", "scnhdr.h", "loader.h", all herein incorporated by reference.
Another format for executable object code files is used in the GEM disk operating system for Atari ST Computers. See K. Peel, "The Concise Atari ST
68000 Programmer's Reference Guide", Glentop Publishers, 1986, particularly pp. 2-21 through 2-24. The entire Peel guide is herein incorporated by reference.
Another format for executable object code files is called PEF. PEF is described in a copending and commonly assigned patent application enfftled "Load Time Relocaffon Engine" filed on March 23, 1993, the disclosure of which is herein incorporated by reference.
FIGS. 4A and 4B illustrate the contents of memory 46 before and after, respectively, a client program 60 is linked with one or more providers 62. As shown in FIG. 4A, before linking, memory 46 contains possibly in addition to the operating system, compiler and linker, object code 60 for the client programand object code 62, perhaps executable object code, for each provider being linked with the client. During linking, a linker routine uses the object codes 60 and 62 as input and produces executable object code 64 (FIG. 4B) as output.

WO 94/25918 21 G 2 ~ 3 3 PCTIUS94/04983 , - 10 The object code 62 of each provider specifies at least a provider indicator 68, a current indicator 70 for identifying a version of that provider, also known as a "definition provider", and an oldest implementation indicator ("OII") 72 for identifying the oldest version of the provider with which a client can operate after being linked with that provider. In other words, OII 72 indicates the oldest version of the provider having an implementation which is compatible with the definitions supplied by the version of the provider being used at link ffme.
The provider indicator 68 uniquely identifies or distinguishes a provider from other providers. For example, a provider indicator 68 may be a null-terminated character string, an integer or an alphanumeric value.
Versions may be specified or otherwise denoted in any form which allows comparisons to be made based on some type of sorting criteria. For example, versions may be specified by character strings, numeric values or alphanumeric values. A possible format for the version information which is used in Macintosh operating systems is described in "Inside Macintosh", Vol. VI, pages 9-23 and 9-24, Addison-Wesley Publishing Co., Inc., 1991, the disclosure of which is herein incorporated by reference. As described therein, a version is indicated in a four-byte numeric value.
The provider indicator 68, current indicator 70 and OII 72 are preferably stored in a header which contains overall information about the provider. For example, in PEF format, executable object code, otherwise called a container, includes a container header which among other informaffon contains a provider indicator 68, a current indicator 70 and an OII 72. For more information on a header in XCOFF see articles entitled "Optional Auxiliary Header for the a.out File" and"filehdr.h".
During linking, the values specified by the provider indicator 68, the current indicator 70 and OII 72 are copied and stored in, or otherwise incorporated into, the executable object code 64, as shown in FIG. 4B. The valueof the provider indicator 68 is stored in provider indicator 74. The value of current indicator 70 is stored in current indicator 76 and the value of OII 72 is stored in OII 78.
In PEF format the provider indicator 74, the current indicator 76 and the OII 78 are preferably stored in an import container id table within the executable object code 64 of the client. In XCOFF format those values are preferably stored in an appropriately modified import file ID table.
A client can change the version indicated by the OII 78 as long as it verifies compatibility with versions which are no older than the version it ~ WO 94/25918 PCT/US94/04983 -- 216~03~ 11 specifies. For example, a version 3.0 of a provider may have an OII which specifies version 2Ø Version 2.0 is essentially version 1.0 with addiffonal explicit features. A client which does not use those additional explicit features may be compatible with version 1.0 as well. In that case, the client which is 5 linked with version 3 can change the OII 78 to indicate version 1.0 rather than 2Ø When a client changes the value of the OII 78, the value of the current indicator 76 is unchanged and still indicates the version of the provider with which the client was built.
FIG. 5 illustrates the contents of memory 46 when a client program 60 is l0 executed. At that time, memory 46 contains, in addition to an operaffng system, executable object code 64 for the client 32 and executable object code 80 for each provider 34. The executable object code 80 for each provider, also known as an "implementation provider" (a provider may be both a definition provider and an implementation provider), specifies, preferably in a header, at least a 15 provider indicator 68, a current indicator 70 and an oldest definition indicator 84 ("ODI") for identifying the oldest version of the provider having definitionswhich are compatible with the implementations provided by the version of the provider specified by current indicator 70.
Optionally, when definitions and implementations of a provider are 20 packaged into a single program, ODI 84 may be defined in the object code 62 (FIGS. 4A and 4B) of the provider. In that case, ODI 84 identifies the oldest version of the provider which has definitions which are compatible with the version of the provider specified by current indicator 70.
FIG. 6 is a flowchart generally illustrating broad steps of the invention.
25 At block 100, when a version of a provider program is developed, a current version and compatibility ranges are defined for that version of the provider.
At block 102, when a client program is linked with a provider, information about the version and compatibility ranges of that provider is stored in the executable code of the client produced by the linking process. At block 104, 30 when a client is executed, compatibility is determined between that client and available versions of implementation providers. Preferably, when more than one compatible version of an implementation provider is available, the "best" ofthose compatible versions is used to execute the client. Criteria and steps usedto determine the "best" compatible version are discussed later in conjunction 35 with FIGS. 14 and 15.
At decision block 106, if there is a compatible version available for the provider(s), then at block 108 the client is executed or compatibility is otherwise indicated. However, if at block 106, there is no compatible version of a WO 94/25918 ~ PCTIUS94/04983 provider, then incompatibility is indicated at block 110 and, depending on the severity of the incompatibility, the client may or may not be executed. In some situations, even though an incompatibility exists, a client may be able to execute at a sufficient, although not maximum, level. There are numerous ways to indicate this incompatibility and the advantages of the invention do not depend on the manner used.
FIG. 7 is a flowchart detailing a preferable embodiment of steps of block 100 of FIG. 6. At block 120 a current indicator 70 (FIGS. 4A, 4B and 5) is defined for the provider. Preferably, a current indicator 70 of a provider is defined such that the value is greater than the value of current indicators of prior versions of that provider. At block 122 an oldest implementation indicator (OII 72 of FIG.
4A) is defined for the provider and at block 124 an oldest definition indicator (ODI 84 of FIG. 5) is defined for the provider. Blocks 120, 122 and 124 may be performed in any order. Preferably, OII 72 and ODI 84 are each less than or equal to the current indicator 70.
FIG. 8 is a flowchart detailing a preferable embodiment of steps of block 102 of FIG. 6. At blocks 138 and 140, values specified by the provider indicator68 and the current indicator 70, respectively, of the provider being linked withthe client are copied and stored within, or otherwise transferred, to the client, i.e. placed in the executable object code 64 of the client (FIG. 5). At block 142, the OII 72 from the provider being linked with the client is copied and stored within, or otherwise transferred, to the client. Blocks 138, 140 and 142 may be performed in any order.
FIG. 9 is a flowchart detailing a preferable embodiment of steps of block 104 of FIG. 6. At block 158 available providers are determined. At block 160 a connector 36 (FIG. 1) connects a client and an implementation version of a provider. The connector 36 may be software such as an operating system or other code fragment manager which provides communication between the client and the provider to perform comparisons of values supplied by each.
Alternatively, connector 36 may be hardware such as a wire which permits an exchange of signals between the client and the provider and permits comparisons of those signals.
At block 162, compatibility is determined by comparing values supplied by the client with values supplied by the implementation provider. FIG. 10 is a flowchart which generally describes the comparisons performed at block 162.
At decision block 180, if the version of the provider linked with the client is the same version of the provider which is available at execution, then at block 182,it is determined that compatibility exists. Otherwise, at decision block 184, if WO 94/2~;918 ~ L ~ 2 ~ 3 3 PCT/IJS94/04983 the version of the provider specified by values stored in the client, in other words the definiffon provider, is newer than the implementation provider, then if at decision block 186 the implementation provider is too old for the client, incompaffbility is exists at block 188, otherwise compaffbility exists at block 182.
If at block 184, the implementation provider is newer than the definition provider, then at decision block 190 if the client is too old for the implementaffon provider, then at block 188 incompaffbility exists, otherwise at block 182 compatibility exists.
FIG. 11 is a more detailed flowchart of steps performed at block 162 of FIG. 9. At decision block 200 if the current indicator of the client specifies the same version as the current indicator of the implementation provider, then at block 202, it is determined that compatibility exists. Otherwise, if at decisionblock 204 a value (or absolute value) of the client's current indicator 76 is greater than a value (or absolute value, if compared to the absolute value of the lS client) of the implementation provider's current indicator 70, then a further comparison is performed at block 206. Otherwise, further comparison is performed at block 208. If at decision block 206, the value (or absolute value) of the OII 78 of the client is less than or equal to the value (or absolute value, if compared to the absolute value of the client's OII) of the current indicator 70 of the implementaffon provider, then at block 202 compaffbility exists. Otherwise, at block 210 compatibility does not exist.
At block 208 if the value (or absolute value) of the ODI 84 of the implementation provider is less than or equal to the value (or absolute value, if being compared to the absolute value of the provider's ODI) of the current indicator 76 of the client, then at block 202 compatibility exists. Otherwise, at block 212 compatibility does not exist.
In the situation where the provider is a shared library, the comparisons at block 206 and 208 essenffally check whether the implementation library and definiffons provided by a library at link time are compatible. At block 206, a check is performed to determine whether the version of the implementation library is no older than the oldest version of the library with which the clientcan operate. If so, then the implementation library presumably has an implementation which is compatible with the definitions provided by the version of the provider being used to build the client. At block 208, a check isperformed to determine whether the version of the provider used at link time supplied definitions to the client which are compatible with the implementation of the implementation provider. The two are compatible when the version of the provider used at link time is no older than the oldest version of the provider WO 94/25918 216 2 ~ 3 3 PCT/US9~/01983 ~

which has definitions which are compatible with the implementation of the implementation provider.
The invention provides a versioning systeIn which permits a developer of a provider to freely assign a new version number to a release of a provider 5 without necessarily rendering it incompatible with clients that were linked with prior versions of that provider. When a new version of a provider is incompaffble with a prior version the provider, the ODI and/or OII in the new version is set accordingly, i.e. to indicate the earliest version of the provider which is compatible with the new version of the provider.
The invention also provides a versioning system which does not encourage clients to link with the oldest available version of a provider to increase the number of versions of the provider with which it is compatible. A
client can link with a newer version of a provider which is available and benefit from the advantages and features in that version which may not be available in 15 earlier versions and still be able to execute with earlier compatible versions of the provider. For example, consider the situation where two versions of a provider are available at link time, an earlier version having a version number of 1.0 and a later version having a version number of 2Ø The 1.0 and 2.0 versions are compatible and version 2.0 has several advantageous features or 20 enhancements which are not present in version 1Ø The OII in the 2.0 versionspecifies version 1.0, indicating that a client linked with the 2.0 version can run with the 1.0 version. The client may also change the version indicated by the OII to specify a version earlier to 1.0 if the client verifies that its use of the earlier version is compatible with versions 1.0 and later. At runtime, the client 25 will be able to execute as long as a version of the provider which is no older than the version specified by the OII stored in the client is available and the ODI
of the available version specifies a version less than or equal to 2Ø Thus, the invention permits a client to utilize advantages of later versions of a provideravailable at link time without necessarily decreasing the likelihood of 30 compatibility at runtime.
As shown in FIG. 12, a client can be linked to multiple types of providers.
FIG. 12 illustrates a provider list 230 which is preferably formed when a client is linked with multiple types of providers. For example, a client may be linked with different kinds of shared libraries, a shared library A, a shared library B35 and a shared library C. In that case, provider list 230 is formed and stored in the client. The provider list 230 can be any list data structure, i.e. array, linked list, which can be searched for A particular item.

~ wo 94esgl8 2 1 ~ ~ ~ 3 3 PCT/U594/04983 The provider list 230 contains one or more provider fields 232, one field per provider that is linked with the client. Each field 232 has a provider indicator 234, a current indicator 236, and an OII 238. A provider indicator 234uniquely identifies a provider and allows the locating of a provider at runtime.Provider indicator 234 is the same as the provider indicator 68 and 74, - previously described. Current indicator 236 and OII 238 correspond to current indicator 70 and OII 72(FIG. 4A), respectively, and their values are derived therefrom.
The general steps provided in FIG. 6 still apply when a client is linked with multiple providers, however, some of the details change, as shown in FIG.
13. FIG. 13 is a flowchart of steps of block 102 of FIG. 6 used in this situation.
For each type of provider, information about the version of the provider and thecompatibility ranges of the provider are stored in a field 232 in the provider list 230.
At block 240, a new field 232 is added to the provider list 230. At block 242, the provider indicator 234 in the new field 232 is set to a unique identification for that provider being linked. At block 244, the current indicator 236 in the new field 232 is set to the value indicated by the current indicator 70 of the provider being linked (FIG. 4A). At block 246, the OII 238 in the new field 232 is set to the value indicated by the OII 72 of the provider being linked.
Blocks 242, 244 and 246 can be performed in any order.
Compatibility between the client and a provider is determined in substantially the same way as in FIGS. 9-11, except that the field 232 corresponding to the provider is first located in the provider list 230 and any reference in FIGS. 9-11 to the current indicator stored in the client and to the OII
stored in the client is actually a reference to those values in the located field.
The provider indicator stored in the client references the provider from which the current indicator and ODI of the provider are obtained.
Preferably, when more than one implementation version of a provider is available at runtime of the client, the invention provides for determining the "best" compatible version to use. In this case, an implementation provider list 260, as shown in FIG. 14, can be formed, preferably by the connector 36, at runtime. Implementation provider list 260 has a provider indicator 261 similar to the provider indicator 234 and one or more provider fields 262, preferably one for each available version of an implementation provider. Each provider field 262 has a provider location 263, a current indicator 266, similar to current indicator 236, and an ODI 268 . The provider location 263 specifies a physical 216203~
WO 94/2~918 PCT/US94/04983 location, while the current indicator and the ODI are derived from the current indicator 70 and the ODI 84, respectively, of the provider (FIG. 5).
The implementation provider list 260 is searched for versions of the implementation provider which are compatible with the client and, preferably, the "best" compatible version is selected. Compatibility is determined according to the steps described with FIG. 15. Numerous kinds of criteria can be used to determine the "best" compatible version. For example, the "besr version may be the most recent version which is compatible with the client or itmay be the version which is closest to the version specified to the version of the provider which was used at link time. In other words, the indicator value of theprovider specifies a version numerically closest to the version specified by theindicator value of the client.
Preferably, a compatibility indicator 270 (FIG. 14) is maintained during the search. At any point during the search, the compatibility indicator specifies the version, if any, or the field 262, within the implementation provider list 260 specifying that version which is the "best" of the versions identified by the fields searched. The compatibility indicator 270 may be, for example, a pointer into the provider list or it may be a data structure having the same structure and information as a field 262 in the implementation provider list 260.
FIG. 15 shows the steps performed at block 104 of FIG. 6 when more than one version of an implementation provider is available at runtime of a client. At block 278, an implementation provider list is formed. The logical name of each provider is retrieved from the client and memory and the disk are searched to locate each provider. At block 280, the compatibility indicator 270 is initialized.
At block 282, if there are one or more unsearched fields 262 in the implementation provider list 260, then at block 284 an unsearched field is selected as the current field being examined. Otherwise, the search ends and control returns to block 106 of FIG. 6, indicating whether compaffbility exists and, if so, which version should be used.
At decision block 286, compatibility between the client and the version of a provider specified by the provider location 263 of the current field is determined according to the steps of FIGS. 10 and 11. If compatibility is found then at block 288 it is determined whether the version specified in the current field is "better" than the version specified by the compatibility indicator. If compatibility is not found at block 286, then control returns to block 282.
If at block 288, the current field's version is the "better" version, then the compatibility indicator is updated to specify the current field or the version indicated by the current field. In either case, control then returns to block 282.

~ WO 94/2~918 17 21~ Z ~ :~3 PCT/lJS94/04983 By providing a mechanism for determining compatibility between a client and a multiple of available implementation providers the invention provides several advantages. First, a finding of incompatibility between available versions of a provider will not prevent a client from execuffng as long as at least 5 one compatible version is found. Second, by searching through a list of available versions of a provider, the invention provides a mechanism for findinga "best" or most suitable version. Depending on the criteria used to determine which version is best, this may allow clients to benefit from advantages of later versions of a provider which they might not otherwise have been able to access.
10 Third, the invention allows more clients to execute because it provides more choices of providers than prior versioning schemes. Older clients can execute with newer providers and newer clients can execute with older providers.
Fourth, the invention allows a version of a provider to be incompatible with past providers, i.e. backward compatibility is not required. Thus the invention 15 provides more flexibility than prior versioning schemes because a provider can choose whether to be backward or frontward compatible, both or neither.
The attached appendix contains a Macintosh Programmer's Workshop ("MPW") text file which contains source code implementing the invention on a Macintosh computer having a mechanism such as a software manager for 20 connecting together client and provider programs. MPW is a registered trademark of Apple Computer, Inc.
FIG. 16 illustrates an example of hardware which can incorporate the invention. Numeral 300 refers generally to a system for connecting external devices to a bus. Common examples of such systems include Small Computer 25 Standard Interhce ("SCSr) and Apple Desktop Bus ("ADB") both of which involve standards for connecting compliant devices 320 via a specified set of cables 322 and connectors 324 and exchanging a specified set of electrical signals over the cable. Apple Desktop Bus is a trademark of Apple Computer, Inc. The cable typically includes one or more wires 326A dedicated to carrying data 30 values and one or more wires 326B dedicated to carrying control signals.
Typically, there is a fixed interface or dedicated wires to indicate versioning of devices. For example, later versions of devices often add control wires that areleft"floating", i.e. unconnected, by earlier devices. These added control wires are set to a defined voltage by new devices. Thus, two devices can detect the 35 version of a shndard supported by the other, given a pair of wires, one in each direction. Or the standard may have specified rules for the connection of a specific pair of devices in a specific direction, allowing for the use of a single WO 94/25918 216 2 ~ 3 ~ PCT/US91/04983 "version" wire. The device in control of a wire signals its version to the otherdevice. The other device then determines whether compatibility exists.
FIG. 17 is a flowchart describing steps of the invention incorporated into a system shown in FIG. 16 wherein devices may be idenfffied as a "sender"
5 (client) or a "receiver" (provider). At block 348, a current indicator and an oldest implementation indicator, analogous to those previously described, are built into a sender and a current indicator and an oldest definition indicator, analogous to those previously described, are built into a receiver. These version checking signals can be defined externally by the standard of the hardware. As l0 shown at block 350 when a device is connected to the system, signals are exchanged to connect a sender and a receiver. At block 352, a sender transmits its current indicator to a receiver.
If at block 354, the current indicator from the sender and the current indicator of the receiver specify the same version, then the receiver signals the lS sender that they are compatible at block 356. Otherwise, if at block 358 the current indicator of the receiver specifies a version which is newer than the version specified by the current indicator from the sender, then control is passed to block 360, otherwise control is passed to block 362.
At block 360, if the version specified by the current indicator from the 20 sender is older than the oldest definition indicator of the receiver, then at block 364, the receiver signals incompatibility to the sender. Otherwise, at block 374, the receiver signals compatibility to the sender.
At block 362, the receiver signals the sender that the sender should determine compaffbility and at block 368 the receiver sends its current indicator 25 to the sender. At block 370, if the version specified by the current indicator from the receiver is older than the version specified by the oldest implementation indicator of the sender, then the sender signals incompaffbility to the receiver at block 364. Otherwise, at block 374, the sender signals compatibility to the receiver.

Claims (9)

1. A method for verifying compatibility between modular components in a system (30) having at least one client component (60) and at least one provider component (62), a provider component (62) having one or more versions, the at least one client (60) being linked to a version of a provider component (62) during the building of the at least one client (60) and the at least one client (60), during execution, using a version of the provider component (62) which is available in the system at the time of execution, wherein the provider component (62) used duringexecution may be a different version than the provider component (62) to which the client (60) was linked, said method comprising the steps of:
specifying a provider indicator (68) for each provider component (62), said provider indicator (68) identifying a provider component's type and uniquely identifying the provider component (62) in a manner that distinguishes the provider component (62) from other provider components (62);
specifying a current indicator (70) for each version of each provider component (62), said current indicator (70) having a value identifying a version of the provider component (62) in a manner which distinguishes the version from other versions of the provider component (62);
specifying for each version of each provider component (62) a compatibility range, the compatibility range for a version of a provider component (62) identifying a range of versions of the provider component which are compatible with that version of the provider component such that during execution of a client that version of the provider can be used as long as the client was built using aversion of the provider component identified in that version's compatibility range;
specifying for each client (60) component a compatibility range for each provider component (62) to which it is linked, each compatibility range identifying a range of versions of a provider component (62) which can be used to execute the client component;
linking the at least one client (60) to a provider component (62) to construct an executable client component;
associating the at least one client (60) with the current indicator (70) of the linked provider component (62);
when a client component (60) is executed, determining which of the at least one provider component (62) and versions thereof are available on the system andconnecting the client component (60) and the available at least one provider component (62) such that information such as the current indicator (70) and compatibility range of the provider component (62), the current indicator of a provider component associated with the client component during linking, and the compatibility range of the client can be exchanged;
determining compatibility between the client component (60) and the connected at least one provider component (62), the determination being based onthe current indicator (70) of the at least one provider component, the current indicator of a provider component associated with the client component during linking, the compatibility range of the at least one provider component and the compatibility range of the client component; and indicating whether compatibility exists.
2. A method defined in claim 1 wherein the steps of determining compatibility and indicating whether compatibility exists includes the steps of:
comparing the value of the current indicator (70) of the connected provider component to the value of the current indicator (76) associated with the client component (60) during linking and if the two values indicate substantially the same versions, then indicating compatibility, and if the two versions are not substantially the same, then if the value of the current indicator (76) associated with the client component (60) indicates a version which is newer than the version indicated by the value of the current indicator (70) of the provider component (62), then if the version specified by the value of the current indicator (70) of the provider component is within the compatibility range of the client component (60), then indicating compatibility,otherwise indicating incompatibility, and if the value of the current indicator (70) of the provider component (62) indicates a version which is newer than the version indicated by the value of the current indicator (76) stored in the client component (60), then if the version specified by the value of the current indicator (76) associated with the client component (60) is within the compatibility range of the connected provider component (62), indicating compatibility, otherwise indicating incompatibility.
3. A method for verifying compatibility between modular components in a system having at least one client component (60) and at least one provider component (62), a provider component (62) having one or more versions, the at least one client (60) being linked to a version of a provider component (62) during the building of the at least one client (60) and the at least one client (60), during execution, using a version of the provider component (62) which is available in the system at the time of execution, wherein the provider component (62) used duringexecution may be a different version than the provider component (62) to which the client (60) was linked, the linked provider component (62) supplying definitions to the client component (60), said provider component (62) capable of supplying definitions, implementation or both, said method comprising the steps of:
specifying a provider indicator (70) for each provider component (62), said provider indicator (68) identifying a provider component's type and uniquely identifying the provider component (62) in a manner that distinguishes the provider component (62) from other provider components (62);
specifying a current indicator (70) for each version of a provider component (62), said current indicator (70) having a value identifying a version of the provider component (62) in a manner which distinguishes the version from other versions of the provider component (62);
specifying for each version of a provider component (62) an oldest implementation indicator (72), the oldest implementation indicator (72) indicating an oldest version of that provider component (62) having an implementation whichis compatible with definitions supplied by the each version of the provider component (62);
specifying for each version of a provider (62) an oldest definition indicator (84), the oldest definition indicator (84) indicating an oldest version of that provider component (62) which supplies definitions that are compatible with the implementation of the each version of the provider component (62);

when a client component (60) is being linked with a version of a provider component (62), associating with the client component (60) the provider indicator (68), the current indicator (70) and the oldest implementation indicator (72) of that version of the provider component (62) being linked;
when a client component (60) is executed, determining which of the at least one provider component (62) and versions thereof are available on the system andconnecting the client component (60) and the available at least one provider component (62) such that information such as the provider indicator (68), the current indicator (70) of the connected provider component, the current indicator (76) of a provider component (62) associated with the client component (60) during linking, oldest implementation indicator (72) and oldest definition indicator (84) can be exchanged;
determining compatibility between the client component (60) and the connected at least one provider component (62), the determination being based onthe values of the provider indicator (68), the current indicator (70) of the connected provider component (62), the current indicator (76) of a provider component (62) associated with the client component (60) during linking, the oldest implementation indicator (72) and the oldest definition indicator (84); and indicating whether compatibility exists.
4. A method defined in claim 3 wherein the steps of determining compatibility and indicating whether compatibility exists includes the steps of:
comparing the value of the current indicator (70) of the connected provider component (62) to the value of the current indicator (76) associated with the client component (60) and if the two values indicate substantially the same version, then indicating compatibility, and if the two versions are not substantially the same, then if the value of the current indicator (76) associated with the client (60) indicates a version which is more recent than the version indicated by the value of the current indicator (70) of the connected provider component (62), then if the oldest implementation indicator (72) associated with the client component (60) specifies a version which is older or the same as the version indicated by the value of the current indicator (70) of the provider, then indicating compatibility, otherwiseindicating incompatibility, and if the value of the current indicator (70) of the provider component (62) indicates a version which is more recent than the version indicated by the value of the current indicator (76) associated with the client component (60), then if the version specified by the value of the oldest implementation indicator (72) of the provider component (60) is older than or the same as the version indicated by the value of the current indicator (76) associated the client (60), then indicating compatibility, otherwise indicating incompatibility.
5. A method defined in claim 3 wherein the steps of determining compatibility and indicating whether compatibility exists includes the steps of:
forming a list (260) of available versions of one or more provider components (62), the list (260) having an element (262) for each version of a provider component (62), each element specifying the provider indicator (68), the current indicator (70) and the oldest definition implementation (84) for the version of the provider component (62) specified by the element (262);
initializing a compatibility indicator (270) which specifies a best compatible version, if any exists, among the versions specified by version indicators in elements in the list;
searching fields of the list for a best compatible version of the provider component (62) by determining for each element (262) compatibility between a version of the provider component (62) specified by the current indicator (70) of that element (262) and the client component (60) and, if compatible, comparing the version specified by the current indicator (70) of the element (262) to a version specified by the compatibility indicator (270) to determine which is better and if the version specified by the current indicator (70) of the element (262) is better, then setting the compatibility indicator (270) to indicate the version specified by the current indicator (70); and indicating whether a compatible version is found and, if so, indicating which version is the best compatible version.
6. An apparatus for verifying compatibility between components in a system having at least one client component and at least one provider component which supplies definitions to the client component, said system having a memory (46) and a disk drive (48), said apparatus comprising:
one or more client components (60) stored on said disk drive;

one or more provider components (62), each provider component (62) being stored on said disk drive (48), each of said provider components (62) having oneor more versions;
a linker (54) for linking a client component (60) to one or more provider components (62), said linker (54) stored on said disk drive (48);
a processor (44) capable of loading into memory (46) and executing a linker (54), one or more client components (60) and one or more provider components (62);
means for specifying a provider indicator (68) for each provider component (60), said provider indicator (68) identifying a provider component's type and uniquely identifying the provider component (62) in a manner which distinguishesthe provider component (62) from other provider components, said provider indicator (68) being associated with a client component (60) when the client component (60) is linked to the provider component (62);
means for specifying a current indicator (70) for each version of each provider (62), said current indicator (70) having a value identifying a version of the provider component (62) in a manner which distinguishes the version from other versions of the provider component (62), said current indicator (70) being associated with a client component (60) when the client component (60) is linkedto the provider component (62);
means for specifying a compatibility range for each version of each provider component (62) and for each client component (60) linked with that provider component (62), said compatibility range being associated with a client component (60) when the client component (60) is linked to the provider component (62);
a connector (322) for determining at execution of a client component (60) available provider component (62)s and for connecting a client component (60) toone or more available provider components (62) such that information such as theprovider indictor (68), current indicator (70) and compatibility ranges can be exchanged;
means for determining compatibility based on the values of the current indicator (70) of the connected provider component (62), the current indicator (76) associated with the client component (60) and the compatibility ranges of the provider and client component (60)s; and means for indicating compatibility.
7. A method for defining compatibility between components in a system having at least one client component (60) and at least one provider component (62), a provider component (62) having one or more versions, the at least one client (60), said method comprising the steps of:
specifying a provider indicator (68) for each provider component (62), said provider indicator (68) identifying a provider component's type and uniquely identifying the provider component (62) in a manner that allows the provider component (62) to be distinguished from other provider components (62);
specifying a current indicator (70) for each version of each provider (62), said current indicator (70) having a value identifying a version of the providercomponent (62) in a manner which distinguishes it from other versions of the provider component (62); and specifying compatibility ranges for each version of each provider component (62), a compatibility range for a particular version identifying a range of versions of the provider component (62) which are compatible and interoperable with the particular version.
8. A method for defining compatibility between components in a system having at least one client component (60) and at least one provider component (62), each provider component (62) having one or more versions, said client component (60) being linked to a version of a provider component (62) which supplies definitions to the client component (60) and executing with a version of a provider component (62) which may be the same or different than the version of the provider component (62) that supplied the definitions to the client component (60) duringlinking, said method comprising the steps of:
specifying a provider indicator (68) for each provider component (62), said provider indicator (68) identifying a provider component's type and uniquely identifying the provider component (62) in a manner that allows the provider component (62) to be distinguished from other provider components (62);
specifying a current indicator (70) for each version of each provider, said current indicator (70) having a value identifying a version of the provider component (62) in a manner which distinguishes it from other versions of the provider component (62);
specifying an oldest implementation indicator (72) for each version of each provider (62), the oldest implementation indicator (72) indicating an oldest version of that provider component (62) having an implementation which is compatible with definitions supplied by the each version of the provider component (62); and specifying for each version of a provider an oldest definition indicator (84), the oldest definition indicator (84) indicating an oldest version of that provider component (62) which supplies definitions that are compatible with the implementation of the each version of the provider component (62).
9. A method as defined in claim 8, said method further comprising the steps of:
linking a client component (60) with a version of a provider component (62);
and associating with the client program the provider indicator (68), current indicator (70) and oldest implementation indicator (72) of the version of the provider (62) being linked with the client component (60).
CA002162033A 1993-05-05 1994-05-03 Method and apparatus for verifying compatibility between modular components in a computer system Abandoned CA2162033A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5834593A 1993-05-05 1993-05-05
US058,345 1993-05-05

Publications (1)

Publication Number Publication Date
CA2162033A1 true CA2162033A1 (en) 1994-11-10

Family

ID=22016251

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002162033A Abandoned CA2162033A1 (en) 1993-05-05 1994-05-03 Method and apparatus for verifying compatibility between modular components in a computer system

Country Status (8)

Country Link
US (1) US5613101A (en)
EP (1) EP0698238B1 (en)
JP (1) JP3343354B2 (en)
AT (1) ATE160032T1 (en)
AU (1) AU6783394A (en)
CA (1) CA2162033A1 (en)
DE (1) DE69406660D1 (en)
WO (1) WO1994025918A1 (en)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5805899A (en) * 1995-07-06 1998-09-08 Sun Microsystems, Inc. Method and apparatus for internal versioning of objects using a mapfile
US7330870B1 (en) 1997-02-11 2008-02-12 International Business Machines Corporation Streaming computer system and method with multi-version protocol compatibility
US6092147A (en) * 1997-04-15 2000-07-18 Sun Microsystems, Inc. Virtual machine with securely distributed bytecode verification
US7080371B1 (en) * 1998-03-03 2006-07-18 Siebel Systems, Inc. Method, system, apparatus and program product for distribution and instantiation of software upgrades
US6154878A (en) * 1998-07-21 2000-11-28 Hewlett-Packard Company System and method for on-line replacement of software
US6202205B1 (en) * 1998-07-21 2001-03-13 Hewlett-Packard Company System and method for profile-based, on-the-fly optimization of library code
US6185734B1 (en) * 1998-07-21 2001-02-06 Hewlett-Packard Company Hierarchical registry structure for managing multiple versions of software components
US6880155B2 (en) * 1999-02-02 2005-04-12 Sun Microsystems, Inc. Token-based linking
US6868425B1 (en) * 1999-03-05 2005-03-15 Microsoft Corporation Versions and workspaces in an object repository
US7158993B1 (en) 1999-11-12 2007-01-02 Sun Microsystems, Inc. API representation enabling submerged hierarchy
DE10008245A1 (en) * 2000-02-23 2001-09-06 Siemens Ag Method for ensuring compatibility and method for data backup within a distributed computer system having several sub-computer systems
US6651186B1 (en) * 2000-04-28 2003-11-18 Sun Microsystems, Inc. Remote incremental program verification using API definitions
US6986132B1 (en) 2000-04-28 2006-01-10 Sun Microsytems, Inc. Remote incremental program binary compatibility verification using API definitions
US6883163B1 (en) 2000-04-28 2005-04-19 Sun Microsystems, Inc. Populating resource-constrained devices with content verified using API definitions
US6981245B1 (en) 2000-09-14 2005-12-27 Sun Microsystems, Inc. Populating binary compatible resource-constrained devices with content verified using API definitions
AU9084201A (en) * 2000-09-14 2002-03-26 Sun Microsystems Inc Remote incremental program binary compatibility verification using api definitions
EP1202168A3 (en) * 2000-10-30 2006-08-23 Microsoft Corporation System and method for dynamically veryfying the compatibility of a user interface resource
JP2002318704A (en) * 2001-04-24 2002-10-31 Sony Corp Electronic equipment
US20030191870A1 (en) * 2002-04-02 2003-10-09 Dominic Duggan Method and apparatus for updating software libraries
US6898768B1 (en) * 2002-05-17 2005-05-24 Cisco Technology, Inc. Method and system for component compatibility verification
JP5036770B2 (en) * 2002-07-19 2012-09-26 株式会社リコー Apparatus, wrapping processing method, and program
EP1387268A3 (en) * 2002-07-31 2005-03-02 Ricoh Company Image forming apparatus, information processing apparatus and version check method
JP4026456B2 (en) * 2002-09-13 2007-12-26 日本電気株式会社 Computer system and information collection method
US7055147B2 (en) * 2003-02-28 2006-05-30 Sun Microsystems, Inc. Supporting interactions between different versions of software for accessing remote objects
ATE366912T1 (en) * 2003-05-07 2007-08-15 Harman Becker Automotive Sys METHOD AND DEVICE FOR VOICE OUTPUT, DATA CARRIER WITH VOICE DATA
JP4411344B2 (en) * 2004-04-01 2010-02-10 バイエリッシェ モートーレン ウエルケ アクチエンゲゼルシャフト A method for recognizing incompatibility in a bus system with multiple control devices
US20060179430A1 (en) 2004-11-18 2006-08-10 Besbris David G Service grouping
US20060161910A1 (en) * 2005-01-14 2006-07-20 International Business Machines Corporation Method, system and program product for automatically ensuring compatability of a code module loaded into a program-code environment
EP1739552A1 (en) * 2005-06-21 2007-01-03 Hewlett-Packard Development Company, L.P. Software installation method and computer system
US7802252B2 (en) * 2007-01-09 2010-09-21 International Business Machines Corporation Method and apparatus for selecting the architecture level to which a processor appears to conform
US8146109B2 (en) * 2007-02-15 2012-03-27 Microsoft Corporation Version resiliency for a host application and custom code
US8181188B2 (en) * 2007-02-15 2012-05-15 Microsoft Corporation Version resiliency for a host application and managed code
US20150207757A1 (en) * 2009-03-25 2015-07-23 Hewlett-Packard Development Company, L.P. Shared resource allocation control
US8694981B2 (en) 2010-11-17 2014-04-08 Apple Inc. Shared resource dependencies
US9064134B1 (en) * 2010-12-06 2015-06-23 Adobe Systems Incorporated Method and apparatus for mitigating software vulnerabilities
US8930901B2 (en) * 2011-08-15 2015-01-06 International Business Machines Corporation Automatic selection of lowest configuration feature level by functionality exploited
US9489184B2 (en) * 2011-12-30 2016-11-08 Oracle International Corporation Adaptive selection of programming language versions for compilation of software programs
US8949824B2 (en) 2012-09-28 2015-02-03 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9128792B2 (en) 2012-09-28 2015-09-08 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9317269B2 (en) 2012-09-28 2016-04-19 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US9235491B2 (en) 2012-09-28 2016-01-12 Wal-Mart Stores, Inc. Systems and methods for installing, managing, and provisioning applications
US10338907B2 (en) * 2016-12-04 2019-07-02 Sap Se Cloud service framework for toolkit deployment
US10572495B2 (en) * 2018-02-06 2020-02-25 Cisco Technology Inc. Network assurance database version compatibility

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
JPS6276954A (en) * 1985-09-30 1987-04-09 Toshiba Corp Communication controller
CA2048306A1 (en) * 1990-10-02 1992-04-03 Steven P. Miller Distributed configuration profile for computing system
US5579509A (en) * 1991-02-08 1996-11-26 International Business Machines Corporation Apparatus and method for verifying compatibility of system components

Also Published As

Publication number Publication date
EP0698238A1 (en) 1996-02-28
DE69406660D1 (en) 1997-12-11
JPH08509830A (en) 1996-10-15
WO1994025918A1 (en) 1994-11-10
EP0698238B1 (en) 1997-11-05
AU6783394A (en) 1994-11-21
ATE160032T1 (en) 1997-11-15
US5613101A (en) 1997-03-18
JP3343354B2 (en) 2002-11-11

Similar Documents

Publication Publication Date Title
US5613101A (en) Method and apparatus for determining at execution compatibility among client and provider components where provider version linked with client may differ from provider version available at execution
US6637025B1 (en) Dynamic selection/definition of which class/methods should or should not be jit'ed using information stored in a jar file
US7757225B2 (en) Linktime recognition of alternative implementations of programmed functionality
CN100478888C (en) Method and system for installing and updating interpreted programming language applications
US6345382B1 (en) Run-time customization in object-oriented design
US7873958B2 (en) System and methods for providing versioning of software components in a computer programming language
US6295638B1 (en) Method and apparatus for loading native object code in data processing system
EP1019803B1 (en) Method and apparatus for assessing compatibility between platforms and applications
US6415435B1 (en) Method and apparatus for determining compatibility of parent classes in an object oriented environment using versioning
US5615400A (en) System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers
US5761510A (en) Method for error identification in a program interface
US6826750B1 (en) Method of automatically selecting program and data updates based upon versions
US9417931B2 (en) Unified metadata for external components
US7669184B2 (en) Introspection support for local and anonymous classes
US7926047B2 (en) Methods and systems for optimization in a run-time environment
WO2000029927A2 (en) A method and system for loading instructions into an executing process
US6233725B1 (en) Method and apparatus to coordinate and control the simultaneous use of multiple just in time compilers with a java virtual machine
EP1261913A1 (en) Method, system, and article of manufacture for limiting access to program files in a shared library file
US20090235284A1 (en) Cross-platform compatibility framework for computer applications
KR20020085872A (en) Translating and Executing Object-Oriented Computer Programs
US6324688B1 (en) Method and apparatus for optimizing execution of Java programs
US6321377B1 (en) Method and apparatus automatic service of JIT compiler generated errors
US8291401B2 (en) Processing symbols associated with shared assemblies
EP0950947B1 (en) Static binding of dynamically dispatched calls in the presence of dynamic linking and loading
US7526752B1 (en) Introspection support for generic types

Legal Events

Date Code Title Description
FZDE Discontinued