Patent Description:
When an operating system executes an application, the application will make function calls to functions that are provided by a function library. An application is a computer program that is compiled and linked to execute under a particular operating system (OS). The OS is software that starts up a computer or other data processing system and manages the functions and/or resources of the computer or other data processing system. A function library is a collection of functions that provides services to the application. Libraries can be statically linked or dynamically linked at runtime. A statically linked library is linked at compile time and is part of the application. A dynamically linked library is loaded into or used by the application when the application is executing. Examples of dynamically linked libraries are runtime libraries, Dynamic-Link Libraries (DLL), and operating system (OS) services. Runtime libraries, DLL, and OS services are collectively referred to herein as systems libraries. In one embodiment, a runtime library is a computer program library used by a compiler to implement functions built into a programming language during execution of an application. A DLL is a function library that is loaded into the application at runtime. DLL functions can be operating system specific, application specific, etc. In one embodiment, OS services are services used by an application during runtime and are specific to a particular OS. OS services can be services to manage system resources such as memory, filesystem resources, power states, graphical user interfaces, other resources, perform inter-application communications, etc.
Document <CIT> concerns a method, system and device embodiments for interfacing a program. Document <CIT> concerns a utility program for software development that generates a synchronized set of translation modules for application program interfaces in a emulated platform.

<FIG> (prior art) is a block diagram of an application <NUM> executing in an operating system environment. In <FIG>, application <NUM> executes in OS environment <NUM> using runtime library <NUM>, OS services <NUM>, and/or DLL <NUM>. In <FIG>, application <NUM> was specifically generated to execute in OS environment <NUM>. Nonetheless, this application can be run in different OS environments. <FIG> (prior art) is a block diagram of an application <NUM> executing in one operating system environment <NUM> (OS2), which is also executing in another operating system environment <NUM> (OS1). OS2 may be a different operating system from a different vendor than OS1. Alternatively, OS2 maybe a different version of OS1. In <FIG>, OS2-based application <NUM> runs in OS1 environment <NUM> by using OS2 service environment <NUM>. In one embodiment, OS2 service environment <NUM> is an actual version of the OS2 executing as a virtual machine in the OS1 Environment <NUM>. Examples of this embodiment known in the art are VMWARE, PARALLELS, and VIRTUALPC. In this embodiment, OS2 application <NUM> runs in operating system OS2 using OS2 services, DLLs, and/or runtime libraries <NUM>.

Alternatively, OS2 service environment <NUM> provides a set of application programming interfaces (APIs) for application <NUM> without the need for a version of OS2 executing in the OS2 service environment. In this embodiment, OS2 service environment <NUM> loads and executes an OS2-based application using OS2 library <NUM> in the OS1 environment. The phrase "OS2-based application" means that this application is compiled for and intended to execute under the OS2 operating system. In addition, OS2 service environment <NUM> can also use OS2 libraries <NUM>, such as OS2 services, DLLs, and/or runtime libraries. An example of this embodiment known in the art is WINE (see, for example, http://www.

The invention provides a method, an apparatus and a machine readable medium as set out in the appended set of claims.

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

Methods and apparatus to define and generate library functions from a function specification are described herein. <FIG> illustrates an embodiment of a method to generate libraries from a function specification file. At least in certain embodiments, these libraries may be referred to as interposing libraries that are used to support the operation/execution of an application, designed for a first OS on a system co-executing a second OS without requiring an executing copy of the first OS. Furthermore, the method generates header information and function code from the function specification file. <FIG> further illustrates one embodiment of a method to generate header information and function code in which the method preprocesses the function specification file. <FIG> illustrates one embodiment of a method to log calls to function libraries using interposing libraries generated from the function specification file. <FIG> illustrates one embodiment of a method to generate and compare logs from an application executing on two different operating systems. <FIG> illustrate one embodiment of application and execution system that implement <FIG>, <FIG>, <FIG>, and/or <NUM>.

<FIG> is a block diagram of an application, compiled for one operating system environment, executing in another operating system environment. In <FIG>, OS2-based application <NUM> executes in the OS1 environment <NUM> without the presence of operating system OS2. OS2-based application <NUM> executes in this environment because OS1 environment <NUM> uses an OS1-based loader (not shown) that can load and execute applications that are either OS1 or OS2-based applications. In addition, OS2-based application <NUM> uses libraries <NUM>, <NUM>, and/or <NUM> to perform OS2-based library function calls that would normally be handled by operating system OS2 (or an OS2 environment) as described in <FIG> and <FIG>. These libraries interpose between the calling application and the actual libraries these libraries interpose for, and hence these libraries <NUM>, <NUM>, and <NUM> may be referred to as interposing libraries. In one embodiment, interposing libraries <NUM>, <NUM>, and <NUM> are libraries that translate the call for an OS2-based function in a runtime library, DLL, and/or OS2 service to a corresponding OS1-based function call to a function in an OS1-based runtime library, DLL, and/or OS1-based service. For example and by way of illustration, RTL interposing library <NUM> translates a call to an OS2-based function in a runtime library to a corresponding call to a function in runtime library <NUM>. RTL interposing library <NUM> can translate one, some, many, or all function calls in runtime library <NUM>. Alternatively, there can be multiple RTL interposing libraries <NUM> that each translates one or more function calls to one or more runtime libraries <NUM>.

In one embodiment, interposing library <NUM> translates calls to functions for OS2 services to corresponding functions that support those OS2 services in OS1 services library <NUM>. In one embodiment, there is one interposing library <NUM> that translates the functions calls to OS1 service library <NUM>. Alternatively, there are several libraries <NUM> that each translates one or more functions calls to one or more OS1 service libraries <NUM>.

In one embodiment, DLL interposing library <NUM> translates calls to functions contained in DLLs to corresponding functions that support the corresponding function in DLL <NUM> for application <NUM>. A DLL can be a DLL compiled for OS1, OS2 or some other operating system. In one embodiment, DLL interposing library <NUM> exports the symbols of the functions in DLL <NUM>. In one embodiment, there is one DLL interposing library <NUM> that translates the functions calls to corresponding functions in DLL library <NUM>. Alternatively, there are DLL interposing libraries <NUM> that each translate one or more functions calls to one or more DLL libraries <NUM>.

<FIG> is a flow diagram of one embodiment of a method <NUM> to generate interposing or other libraries for executing applications from a function specification file. In one embodiment, OS1 environment <NUM> executes method <NUM> to generate these libraries including, but not limited to, runtime interposing libraries <NUM>, OS1 service interposing libraries <NUM>, and/or DLL interposing libraries <NUM>. In one embodiment, a software developer uses a developer's toolkit to develop applications, operating system components, libraries, etc. A developer's toolkit is an assembly of tools a developer would use to develop software. The toolkit can include an editor, a compiler, a linker, a file preprocessor, etc. An example of a developer's toolkit incorporating an embodiment of the invention is described herein in <FIG>.

In <FIG>, at block <NUM>, method <NUM> creates the function specification file. In one embodiment, the function specification file comprises function definition data that indicates to method <NUM> to generate software to perform a function call translation for a library function associated with operating system OS2. In one embodiment, the function definition data comprises data for each function that defines the function call to be translated. For each function, the function definition data can comprise one or more of a function prototype, a keyword, a library name, optional parameters, and other information used to support interposing library generation. In one embodiment, the function prototype is a programming language prototype known in the art that defines the function name, the function parameter list, and the return value type. Examples of programming language prototypes supported are C, C++, JAVA, PASCAL, etc. The keyword is a word or phrase in the function definition data that is used by method <NUM> to modify the function headers and code generated by method <NUM>. A keyword can be used to indicate to method <NUM> to add stack checking code, symbol export code, etc. Method <NUM> uses stack checking code to enforce a particular stack variable management scheme used by OS1 or OS2. This code is useful for generating libraries used in one operating system for applications based on or written for another operating system. Different operating systems can have different conventions for when to put function parameters onto the call stack and when to take these parameters off the stack. Using stack checking specifies a common action to be taken for call stack manipulation. Method <NUM> uses a symbol export keyword to generate a function code to support exporting of the function name and other function symbols in order to make these symbols available to the calling application. Function definitions are further described with reference to <FIG>, at blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> below.

In addition, the function definition data can include optional parameters. In one embodiment, these parameters can include parameters to modify function template generation. Method <NUM> can use some of these parameters to assist in generating many functions from one function definition. For example, method <NUM> can generate multiple string functions from a single function definition to handle different type of strings parameters and return values (e.g., ASCII, Unicode, etc.). Function call template generation is further described in <FIG>, at block <NUM> below.

At block <NUM>, method <NUM> stores the function specification file. Method <NUM> can stores this file on a hard disk, in memory, in flash storage, etc. on a computer, other storage device, or other data processing system that is local or remote to the processor executing method <NUM>.

At block <NUM>, method <NUM> preprocesses the function specification file to generate function code and header information based on the function definition data in the function specification file. Preprocessing is the action of processing input data to produce an output that is used by anther program. In one embodiment, method <NUM> generates the header information using the function definition data. As in known in the art, header information is a forward declaration of a function, a variable, and/or other identifiers. This information can be stored in a file, in memory, etc. Compilers use header information to compile function code to produce libraries, executables, applications, etc..

In addition, method <NUM> generates function code using the function definition data. In one embodiment, the function code is a complete implementation of that function, which includes the function call definition, parameter definition, logging framework, debugging framework, and other function software that allows a developer to compile and use the function code without further editing. In one embodiment, this generated function code supports call translation. Function call translation is translating a call to a function from an application to a call to function in a library that is part of the operating system executing that application. For example, a function in a system library with the same name and parameter list as in the function definition data can be generated in this embodiment. Alternatively, method <NUM> can generate function code that is a partial implementation of the function. In this embodiment, the developer edits the generated function code to fully implement the function. In another embodiment, method <NUM> generates code that instantiates objects described in the function definition at runtime.

At block <NUM>, method <NUM> compiles the function code and header information into libraries. For example, method <NUM> can generate interposing runtime libraries <NUM>, OS1 services <NUM>, and/or DLLs <NUM> as described with reference to <FIG>. As is known in the art, method <NUM> uses a compiler to generate the library. Method <NUM> uses these interposing libraries to execute an application at block <NUM>. In one embodiment, method <NUM> executes an application with an interposing library in the same operation system used to compile the application. In this embodiment, the interposing library can be used to generate a detailed trace of the system library use by the executing application. Alternatively, method <NUM> executes an application with the interposing library in a different operating system than the operating system used to compile the application. The different operating system can be the same type, but a different version, of the operating system used to generate the interposing library. For example, the operating system executing the application can be the MAC OS X <NUM>. <NUM> operating system provided by APPLE INCORPORATED, whereas the application is compiled for MAC OS X <NUM>. Alternatively, the different operating system can be a different type of operating system from the same or different vendor. For example, the operating system executing the application can be the MACINTOSH OS <NUM>. <NUM> and the application is compiled for WINDOWS XP operating system provided by MICROSOFT CORPORATION. Examples of different OS are, but not limited to, MAC OS <NUM>, MAC OS X <NUM>. x, WINDOWS <NUM>, WINDOWS <NUM>, WINDOWS XP, WINDOWS VISTA, the many different types of LINUX and UNIX known in the art, etc..

In <FIG>, method <NUM> uses the function specification file to generate interposing libraries that can be used by one or more applications, such as application <NUM> in <FIG>, to make and log calls to corresponding functions in OS Service, runtime, and/or DLL libraries. In this Figure, at block <NUM>, method <NUM> preprocessed the function specification to generate header information and function code to support generation of the interposing libraries. This preprocessing function is typically one of a set of developer tools. <FIG> is a flow diagram of one embodiment of a method <NUM> to generate function code and header information from a function specification file. Method <NUM> can be used to generate header information and function code to support execution of applications that are compiled for the same or different operation system that method <NUM> runs under. In the discussion of <FIG> and other Figures herein, examples are given with reference to the "C" programming language. This invention is not limited to this programming language, because as one of skill in the art would recognize, this invention can be used with other programming languages known in the art, such as C++, JAVA, PASCAL, etc..

In <FIG>, at block <NUM>, method <NUM> receives the function specification file definitions. In one embodiment, method <NUM> receives the function specification file definitions by retrieving the definitions from the function specification file stored in disk, memory, etc. as described in <FIG>, block <NUM>. Method <NUM> can receive one or more function definitions.

Method <NUM> executes a processing loop at blocks <NUM> to <NUM> to generate the function code and header information for each function definition received. At block <NUM>, method <NUM> parses the function definition using one of the parsing schemes known in the art. By parsing, method <NUM> determines the function prototype, the keyword, the library name, optional parameters, and/or other information associated with each function definition.

At block <NUM>, method <NUM> determines if the function definition is a runtime library function call definition. In one embodiment, method <NUM> determines if the function prototype of the function definition is the same prototype as a function in the named library. If it is, method <NUM> generates the function code and header information for the runtime definition, at block <NUM>. For example, method <NUM> receives the function definition:
stdcall void function2(void) libc;
In this definition, stdcall is a keyword, void is the type of parameter returned from a call to function2, function2(void) is the function prototype for function2, and libc is the library name. In this example, method <NUM> checks if function2 is defined in the runtime library libc with a return parameter type of void and arguments void. If there does exists another function with the same prototype, method <NUM> generates the header information and function code for function2.

As described above, at block <NUM>, method <NUM> generates the header information and function code for the runtime library function call definition determined at block <NUM>. In one embodiment and using the example function definition from above, method <NUM> generates header information for function2 as:
void STDCALL pe_function2(void)_force_align_arg_pointer;
This header information comprises the return type ("void"), function name ("pe_function2") and the function parameter list ("void"). In addition, method <NUM> adds to header information the STDCALL and the "_force_align_arg_pointer" parameters. The STDCALL parameter indicates to the compiler to use the stdcall calling convention. In this calling convention, the callee is responsible for cleaning up the stack before returning to the caller. The "_force_align_arg_pointer" parameter is used for stack checking. In one embodiment, the compiler uses the "_force_align_arg_pointer" parameter to generate code at the beginning of the function to align the stack. In this embodiment, method <NUM> renames the function from "function2" to "pe_function2. " This is done to avoid namespace conflicts because libc has a function named "function2" that is called by the function pe_function2. In another embodiment, method <NUM> does not rename function2. Alternatively, method <NUM> generates header information appropriate for the programming language used by the developer.

In addition, method <NUM> generates the function information for the interposing runtime library function defined in the function definition. In one embodiment, and using the example function definition from above, method <NUM> generates the function code with the structure comprising:
<IMG>
<IMG>
In this embodiment, Function Preamble is a set of code that is used to define header file imports, global variables, DLL definitions, etc. as is known in the art. Define Variables is set of code that defines variables that is used to support the RTL function code call, logging code, debugging code, and other variables used in pe_function2. Initial Logging Code is a set of code used to define the initial logging used to log information before the call to runtime library function. In one embodiment, initial logging code logs the function name, the parameters names and values passed, the time the function was called, etc. Initial Debugging Code is a set of code used to output debugging information before the call to the runtime library function. RTL Function Code is the code used to call the runtime library function. Additional Debugging Code is a set of code used to output debugging information after the call to the runtime library function. Additional Logging Code is a set of code used to define the additional logging used to log information after the call to runtime library function. Function Return is a set of code to set the value of the return parameter and return that parameter to the calling application. While this embodiment illustrates generating function code with all of the above structures listed, in alternate embodiments, method <NUM> can generate function code with one or some of the structures listed. Execution proceeds to block <NUM> below.

If the function definition is not a runtime library function call definition, method <NUM> determines if the function definition is a DLL function call definition at block <NUM>. In one embodiment, method <NUM> determines if the function definition is a function call to a DLL function by the presence of the keyword "reexport". This keyword indicates to export the symbol of the function call used in the DLL to calling application. If the function definition is such a function call, method <NUM> generates the function code and header information at block <NUM>. For example, method <NUM> receives the function definition:
reexport function1 libraryb;
In this definition, reexport is the keyword indicating a DLL function call definition, function1 is the name, and libraryb is the DLL that includes function2. In response to the reexport keyword, method <NUM> generates the header information and function code for function2 at block <NUM>.

As described above, at block <NUM>, method <NUM> generates the header information and function code for the DLL function call definition determined at block <NUM>. In one embodiment and using the DLL function definition above, method <NUM> generates header information:
extern "C" void pe_function1();
This header information comprises the extern keyword, a void return type, and the function name ("pe_function1"). While in this example, there are no parameters for pe_function1, in alternate embodiments, method <NUM> could generate a parameter list in the header information as needed. Furthermore, method renames function1 to "pe_function1" to avoid namespace conflicts as described above with reference to block <NUM>.

In addition, method <NUM> generates the function code for the DLL function call definition. In one embodiment, and using the example function definition from above, method <NUM> generates the function code with the structure comprising:
<IMG>
<IMG>
The function code generated by method <NUM> for the DLL function call is similar to the runtime library function described in block <NUM>. Function Preamble defines the header file imports, the global variables, the DLL definitions, etc. as is known in the art. Define Variables defines variables that support the DLL function code call, the logging code, the debugging code, and/or other variables used in reexport_init. Initial Logging Code defines the initial logging code used to log information before the DLL function call. Initial Debugging Code outputs debugging information before the call to the DLL function. Additional Debugging Code outputs debugging information after the call to the DLL function. Additional Logging Code defines the additional logging code used to log information after the DLL function call. Function Return sets the value of the return parameter and returns that parameter to the calling application.

In addition, method <NUM> generates DLL Load Code and DLL Function Call Code that sets up the call to the DLL function and calls that DLL function. DLL Load Code is a set of code that loads the appropriate DLL. DLL can be a DLL of the operating system used by method <NUM>, or can be a DLL compiled for another operating system (different versions, types, etc.). DLL Function Call Code is a set of code that calls the function in the loaded DLL.

If the function definition is not a DLL function call definition, method <NUM> determines if the function definition is a function call template definition at block <NUM>. A function definition indicates a function call template definition by certain types of parameters and/or function names. In one embodiment, a function call template definition is indicated by presence of string variables in the function definition parameter list, function name, and/or combination thereof. For example, the following function definitions can be function call template definitions:.

Function7 function call template definition comprises the stdcall keyword, return type ("void"), function prototype ("function7(LPTSTR string)"), and optional parameter ("genaw"). Function8, function9, and function10 have similar function definitions. In this example, the function definitions for function7-function9 indicate a function call template definition through the use of the parameter type LPRSTR in the parameter list. The function definition for function10 indicates a function call template definition through the particular SAMPLE_STRUCT passed through the parameter list. In this embodiment, genaw, nocf, and callthrough are optional parameters that indicate which template is to be used when method <NUM> generates the header information and function code for these functions.

At block <NUM>, method <NUM> generates the header information and function code information for the function calls defined in the function call template. In one embodiment and using the function7 function call template definition from above, method <NUM> generates the following header information:.

In this example, method <NUM> generates three headers to handle three different string arguments that can be used with the three different variations of function7. Here, method <NUM> generates functions to handle strings of type CFMutableStringRef (pe_function7CF), LPSTR (pe_function7A), and LPWSTR (pe_function7W). As above, each of the functions is renamed with a prepended "pe_" to avoid namespace conflicts. Furthermore, each of the functions have header information that uses the STDCALL parameter to indicate the standard calling convention and "_force_align_arg_pointer" optional parameter to enforce stack checking. In one embodiment, this function call template definition is used as a shortcut to translate calls to function libraries that have similar naming conventions and handling different types of related parameters.

In one embodiment, method <NUM> uses the optional parameters "genaw", "nocf", and "callthrough" to control which functions are generated. In this embodiment, "genaw" indicates to generate a single function named impl_functionnameCF and uses strings of type CFMutableStringRef. Conversely, "nocf" indicates to generate two functions named "impl_functionnameA" and "impl_functionnameW" with strings of type LPSTR and LPWSTR, respectively. "Callthrough" indicates to generate a single function that takes an extra parameter indicating which entry point (A, W, or CF) was actually called.

In addition, method <NUM> generates the function information for each of the functions defined in the function call template definition. In one embodiment, and using one of the example functions generated from a function call template definition, method <NUM> generates function code with the structure comprising:
<IMG>.

The function code generated by method <NUM> for this function call is similar to the runtime library function code described in block <NUM> and DLL function code in block <NUM>. Function Preamble defines the header file imports, the global variables, the DLL definitions, etc. as is known in the art. Define Variables defines variables that support the function code call, the logging code, the debugging code, and/or other variables used in various versions of pe_function7. Initial Logging Code defines the initial logging code used to log information before the OS Service function call. Initial Debugging Code outputs debugging information before the call to the OS Service function. Additional Debugging Code outputs debugging information after the call to the OS Service function. Additional Logging Code defines the additional logging code used to log information after the call to the OS Service function. Function Return sets the value of the return parameter and returns that parameter to the calling application. In addition, method <NUM> generates Function Calling Code that makes the call to the corresponding function. Execution proceeds to block <NUM> below.

If the function definition is not a function call template definition to OS Services, method <NUM> determines if the function definition is a basic function call definition to an OS service at block <NUM>. In one embodiment, a basic function definition to an OS service is a function definition for a call translation to that OS service. The OS service can be for the same or different OS that method <NUM> executes under. In one embodiment, a basic function call definition indicates a function call translation using function name and prototype, along with optional parameters and inline code. In alternate embodiments, other function definition types can use inline code. For example, the following function definitions can be basic function definitions:
<IMG>
Function3 function definition comprises the cdecl keyword, return type of void, function prototype ("function3(void)"), and optional parameters ("ordinal=0x0001"). In one embodiment, ordinal indicates an alternate access to the same function. For example, function3 can be looked up either by name (pe_function3) or by value (<NUM>). Function4-<NUM> have similar function definitions. In addition, the function definition can define inline code and a return value as used in function5 and function6 function definitions, respectively. In one embodiment, method <NUM> generates one set of header information and function code for each basic function definition.

At block <NUM>, method <NUM> generates the header information and function code information for the function calls defined in the basic function definition. In one embodiment and using the function3 function definition above, method <NUM> generates the following header information:
void pe_function3(void) _force_align_arg_pointer;
The header information comprises the void return type, function name (pe_function3). While in this example, there are no parameters for pe_function3, in alternate embodiments, method <NUM> could generate a parameter list in the header information as needed. Furthermore, method <NUM> renames function3 to "pe_function3" to avoid namespace conflicts as described above with reference to block <NUM>.

In addition, method <NUM> generates the function information for the basic function call definition. In one embodiment, and using the example function definition from above, method <NUM> generates function code with the structure comprising:
<IMG>
The function code generated by method <NUM> for the basic function call is similar to the runtime library function described in block <NUM>. Function Preamble defines the header file imports, the global variables, the DLL definitions, etc. as is known in the art. Define Variables defines variables that support the basic function code call, the logging code, the debugging code, and other variable used in pe_function3. Initial Logging Code defines the initial logging code used to log information before the OS service call. Initial Debugging Code outputs debugging information before the OS service call. Additional Debugging Code outputs debugging information after the OS service call. Additional Logging Code defines the additional logging code used to log information after the OS service call. Function Return sets the value of the return parameter and returns that parameter to the calling application. In addition, method <NUM> generates Function Calling Code that sets up the basic function call. Execution proceeds to block <NUM> below.

If the function definition is not a basic call to an OS service, method <NUM> determines if the function definition is an object definition. In one embodiment, the object definition defines an object that is used by the same or different operating system that is executing method <NUM>. For example and by way of illustration, an object can be MICROSOFT WINDOWS-based Component Object Model (COM) object as is known in the art. For example, the following object definition is a COM declaration for the new object class ExampleObject1:
// In the following example we're declaring a new object ExampleObject1. // The spec generator will create all of the code necessary to instantiate one
at runtime
// and will create default implementations for all of the methods in the
IExampleClass and
// IUnknown interfaces, except for SampleMethod1 which is marked "imp"
below
// to indicate that we have already provided an implementation. class ExampleObject1 : public unimp IExampleClass {
imp SampleMethod1;
void AdditionalSampleMethod(void);
private:
int fPrivateData;
};
In this example, class ExampleObject1 implements the IExampleClass interface. ExampleObject1 class has two defined functions, an unimplemented SampleMethod1 and AdditionalSampleMethod. On one hand, the "imp" keyword for SampleMethod indicates that the developer will provide the implementation of SampleMethod. On the other hand, method <NUM> generates a default implementation of AdditionalSampleMethod. In addition, ExampleObject1 has a private int defined, fPrivateData.

At block <NUM>, method <NUM> generates the header information and object function code for the class defined in the object definition. In one embodiment and using the ExampleObject1 definition from above, method <NUM> generates header information for class ExampleObject1 and any inherited interface and class definitions of that class. For example, method <NUM> generates the following header information:
<IMG>
In this embodiment, Initial Declarations are the initial declarations of the functions, the variables, etc. used by class ExampleObject1. Inherited Class/Interface Definitions are definitions for the functions, the variables, etc. for classes and/or interfaces that ExampleObject1 inherits. ExampleObjectl Definitions are definitions of additional functions, variables, etc. that are used by class ExmapleObject1 that are not defined in Inherited Class/Interface Definitions. In another embodiment, the classes and/or interfaces inherited by ExampleObject1 can also be defined using function definition data in a function specification file. In this embodiment, this additional data is processed in a similar fashion as for other object definitions.

In one embodiment, and using the example object definition from above, method <NUM> generates function code for class ExampleObject1 with the structure comprising:
<IMG>
In this embodiment, Interface Defined Functions is a set of code generated for functions of ExmapleObject1 that are defined as part of any interface that ExampleObject1 implements. Inherited Class Defined Functions is a set of set of code generated for functions of ExmapleObject1 that are defined as part of any class that ExampleObject1 inherits. Class Specific Functions is a set of code generated for functions that are specifically defined for ExampleObject1. These generated functions can include any or all of the code structures defined for one of the other types of function definitions (runtime library function call definitions, DLL call definitions, functions template call definitions, basic function call definitions, etc.). For example, a class function defined this way can have one or more of function preamble, variable definition, logging code, debugging code, function call code, and function return code as generated for these other types of function definitions. In addition, the functions generated for class ExampleObject1 can be fully implemented functions or can be partial implementations. Execution proceeds to block <NUM> below.

If the function definition is not an object definition, method <NUM> signals an unsupported definition error at block <NUM>. In one embodiment, method <NUM> signals an unsupported definition by signaling an error, printing an error, stopping execution, etc..

At block <NUM>, method <NUM> optionally receives manual changes to the generated function code. In one embodiment, method <NUM> receives changes to function call code, logging code, debugging code, etc. In addition, method <NUM> integrates the changes into the generated function code. Method <NUM> stores the generated header information and function code, along with optional function code changes, at block <NUM>. The processing loop ends at block <NUM>.

The automatically generated interposing libraries with the logging framework generated in <FIG> can be used in many situation such as, but not limited to: logging calls to OS services, DLLs, and/or runtime libraries; assisting in the enabling of executing applications under a different operating system; and comparing the logs of a single OS-based application executing on many different operating systems.

In one embodiment, the automatically generated interposing libraries support the automatic logging of OS services, DLLs, and/or runtime libraries. This logging can be used for an application compiled with the same or different operating system from the one that controls the execution of the application. Furthermore, this logging can be used to log calls to OS services, DLLs, and/or runtime libraries by applications that are compiled with or without debug information. <FIG> is a block diagram of interposing library <NUM> interposing calls from application <NUM> to system library <NUM> in OS1 environment <NUM>. In <FIG>, application <NUM> is compiled for OS1 environment <NUM> and application <NUM> makes calls to OS1-based services, DLLs, and/or runtime libraries. System library <NUM> can be one or more OS1 Service, DLL, and/or runtime libraries as described reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. System library <NUM> further comprises function 614A. In one embodiment, function 614A can implement an OS1 service, or a function found in a DLL and/or runtime library. Interposing library <NUM> can be one or more interposing libraries for OS1 services, DLLs, and/or runtime libraries as described with reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. Interposing library <NUM> further comprises function 614B. Function 614B is an interposing function that corresponds to function 614A. In one embodiment, function 614B is generated based on a function specification file as described in <FIG> and <FIG>.

In <FIG>, application <NUM> makes a call 612A to function 614A. In the absence of interposing libraries <NUM>, function 614A returns to application <NUM>, including any returned parameters via 612B. With interposing library <NUM> interposing for system library <NUM>, OS1 environment <NUM> redirects the function 614A calls by application <NUM> to corresponding function 614B in interposing library <NUM> via 608A. Function 614B logs this call to logging repository <NUM> via 608B. In one embodiment, function 614B logs the time the call was made, the library function name, and/or the name and value of the parameters being passed to the library function 614B. Logging repository <NUM> can be a file, memory, a database, etc. that is used in the art to store function call logging. Function 614B calls function 614A via 608C.

Function 614B returns to function 614A in interposing library <NUM> via 610A. In one embodiment, function 614A returns parameters to function 614B. Function 614B logs any additional logging such as function 614A return value, timestamp, returned parameters, etc. to logging repository <NUM> via 610B.

In <FIG>, application <NUM> was complied for the same operating system that executed this application. In addition, in another embodiment, the application can be executed using interposing libraries where the application is compiled for a different operating system than is executing it. <FIG> is a block diagram of an interposing library of one operating system interposing library calls of an application that is compiled for another operating system. In <FIG>, application <NUM> is compiled for OS2, but is loaded and executed in the OS1 environment <NUM>. In one embodiment, application <NUM> is application <NUM>. Furthermore, application <NUM> uses system library <NUM> to implement library functions that would otherwise be provided by OS2. System library <NUM> can be can be one or more OS1 Service, DLL, and/or runtime libraries as described reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. System library <NUM> further comprises function 714A. Function 714A can implement an OS1 service, or a function found in a DLL and/or runtime library. Interposing library <NUM> can be one or more interposing libraries for OS1 services, DLLs, and/or runtime libraries as described with reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. In one embodiment, interposing library <NUM> is generated using the same function definition data as interposing library <NUM> described in <FIG>. In this embodiment, interposing library <NUM> is generated for OS1 environment <NUM>, whereas interposing library <NUM> is generated for a different OS environment. Interposing library <NUM> further comprises function 714B. Function 714B is an interposing function that corresponds to function 714A. In one embodiment, function 714B is generated based on a function specification file as described in <FIG> and <FIG>.

In <FIG>, application <NUM> makes a call 712A to function 714A. In the absence of interposing libraries <NUM>, function 714A returns to application <NUM>, including any returned parameters via 712B. With interposing library <NUM> interposing for system library <NUM>, OS1 environment <NUM> redirects the function 714A calls by application <NUM> to corresponding function 714B in interposing library <NUM> via 708A. Function 714B logs this call to logging repository <NUM> via 708B. In one embodiment, function 714B logs the time the call was made, the library function name, and/or the name and value of the parameters being passed to the library function 714B. Logging repository <NUM> can be a file, memory, database, etc. that is used in the art to store function call logging. Function 714B calls function 714A via 708C.

Function 714B returns to function 714A in interposing library <NUM> via 710A. In one embodiment, function 714A returns parameters to function 714B. Function 714B logs any additional logging such as function 714A return value, timestamp, returned parameters, etc. to logging repository <NUM> via 710B.

<FIG> illustrate two different embodiments of interposing libraries interposing calls to libraries. <FIG> is a flow diagram of one embodiment of a method <NUM> to interpose a call to a library from a non-debug application using an interposing library. In one embodiment, the operating system that the non-debug application is compiled for can be the same or different from the operating system that executes the non-debug application. Furthermore, the non-debug application and the library do not require any recompiling in order for the interposing library to log library function calls. Thus, the interposing library can be developed before, during, or later than the development of the non-debug application and/or the library. In <FIG>, at block <NUM>, method <NUM> intercepts a library function call from a non-debug application using the interposing library. In one embodiment, method <NUM> intercepts the library function call using interposing library <NUM> (or <NUM>) as described in reference to <FIG> (<NUM>).

At block <NUM>, method <NUM> logs the call to the library function. In one embodiment, method <NUM> logs the call with function 614B (714B) of interposing library <NUM> (<NUM>) to logging repository <NUM> (<NUM>) as described in reference to <FIG> (<NUM>). In another embodiment, method <NUM> logs one, some or all of the library function calls. Control of which library function calls are logged is controlled at runtime and does not require a recompile of the interposing library or the non-debug application. Furthermore, control of the logging function calls can be at the individual function level, API level, and/or the library level. Method <NUM> makes the call to the library function using the interposing library at block <NUM>. In one embodiment, method <NUM> calls library function 614A (714A) using interposing library function 614B (714B) as described with reference to <FIG> (<NUM>). At block <NUM>, method <NUM> receives the return values from the called library function. In addition, method <NUM> receives any modified parameters that were passed to the called library function.

At block <NUM>, method <NUM> logs the return values and the exit of the interposing library function. In one embodiment, method <NUM> logs passed parameters, timestamp of the interposing library exit, and other information relating to the interposing library function call as described in reference to <FIG> (<NUM>). Method <NUM> passes the return value and any modified parameters back to the non-debug application at block <NUM>.

In <FIG>, OS2-based application <NUM> uses libraries <NUM> and <NUM> when executing in OS1 environment <NUM>. In this Figure, application <NUM> passes parameters to these libraries and receives a return value and any modified parameters in return. One of the possible embodiments is that system library <NUM> creates objects and passes these objects back to application <NUM> via interposing library <NUM>. This embodiment can be useful when application is using OS2-based services to create OS2 provided objects to application <NUM> when executing in OS1 environment <NUM>. For example, a non-MICROSOFT WINDOWS operating system can create MICROSOFT WINDOWS-based COM objects using system library <NUM>.

<FIG> is a block diagram of a system library <NUM> of operating system OS1 creating objects for an application <NUM> compiled for another operating system. In addition, application <NUM> is compiled for OS2, but is executed in OS1 environment <NUM>. In an alternate embodiment, application <NUM> is an OS1-based application. In this Figure, OS2-based application <NUM> is loaded and executed by OS1 environment <NUM>. Furthermore, application <NUM> uses system library <NUM> to implement library functions that would otherwise be provided by OS2. System library <NUM> can be can be one or more OS1 Service, DLL, and/or runtime libraries as described reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. System library <NUM> further comprises function 914A. Function 914A can implement an OS1 service, or a function found in a DLL and/or runtime library. Interposing library <NUM> can be one or more interposing libraries for OS1 services, DLLs, and/or runtime libraries as described with reference to <FIG> and libraries <NUM>, <NUM>, and <NUM>. Interposing library <NUM> further comprises function 914B. Function 914B is an interposing function that corresponds to function 914A. In one embodiment, function 914B is generated based on a function specification file as described in <FIG> and <FIG>.

In <FIG>, application <NUM> makes an object request 908A to system library <NUM>. Object request can be for any type of object known the art: COM, Common Object Request Broker Architecture (CORBA), JAVA BEANS, etc. Function 914B receives object request 908A and logs the object request 908B to logging repository <NUM>. In one embodiment, function 914B logs the object requests with time function 914B was called, function 914A name, and/or the name and value of the parameters being passed to function 914A. Function 914B passes the object request 908C to function 914A in system library <NUM>. In response to object request 908C, function 914A creates the requested object. In one embodiment, function 914A creates an object that is typically created and used in another operating system than the one that is executing application <NUM>. For example and by way of illustration, function 914A creates a COM object while executing in a non-MICROSOFT WINDOWS environment. Function 914A returns the created object to the calling function 914B via 910A. Function 914B logs the created object and other information to logging repository <NUM> via 910B. In one embodiment, function 914B logs a string or other suitable representation of the created object to logging repository <NUM>. In another embodiment, function 914B logs the return value, timestamp, modified parameters, etc. to logging repository <NUM>. Function 914B returns the created object to application <NUM> via 910C.

<FIG> and <FIG> illustrate two different operating systems using interposing libraries to interpose system library function calls for an application compiled for one or another of the operating systems. In these Figures, interposing libraries log library function calls of the executing application. In one embodiment, the different operating systems execute the same application. By executing the same application on different operating systems and logging these calls, a developer can use this to debug, evaluate, develop, etc. a set of libraries intended to support executing the application on an operating system that is different from the operating used to compile the application. In one embodiment, the debugging, evaluation, development, etc. is done by comparing the logs generated in <FIG> and <FIG>.

<FIG> is a flow diagram of one embodiment of a method <NUM> to log and compare the library function calls to operating system libraries for the same application executing in two different operating systems. In <FIG>, at block <NUM>, method <NUM> executes OS2-based application in the OS2 environment using interposing libraries. In one embodiment, method <NUM> executes OS2-based application <NUM> in the OS2 environment using interposing libraries <NUM> as described with reference to <FIG>. In one embodiment, method <NUM> executes OS2-based application in a sequence of steps that are repeatable and, further, this sequence of steps can be used at block <NUM>. At block <NUM>, method <NUM> logs function calls to OS2 services, DLLs, and/or runtime libraries using interposing libraries. In one embodiment, method <NUM> logs these function calls using interposing libraries <NUM> to logging repository <NUM> as described with reference to <FIG>.

At block <NUM>, method <NUM> executes OS2-based application in the OS <NUM> environment using the interposing libraries. In one embodiment, method <NUM> executes OS2-based application <NUM> in the OS1 environment using interposing libraries <NUM> as described with reference to <FIG>. In one embodiment, method <NUM> executes the OS2-based application in the same sequence of steps as in block <NUM> in order to potentially generate the similar set of logs as in block <NUM>. At block <NUM>, method <NUM> logs function calls to OS2 services, DLLs, and/or runtime libraries using these interposing libraries. In one embodiment, method <NUM> logs these function calls using interposing libraries <NUM> to logging repository <NUM> as described with reference to <FIG>.

At block <NUM>, method <NUM> compares the OS1 and OS2 based logs generated by interposing libraries at block <NUM> and <NUM>. In one embodiment, method <NUM> compares the two logs to determine if and where the logs diverge. This can be a debugging tool to visualize the path the application has taken across two operating systems and determine whether an error has occurred by observing the divergence of the two logs. In one embodiment, the comparison process is automated with a log analyzer.

<FIG> is a block diagram illustrating one embodiment of a developer's toolkit <NUM> used on a computer <NUM> that generates an interposing library for use with application compiled for the same or different operating systems. In <FIG>, computer <NUM> comprises OS1 environment <NUM>. OS1 environment <NUM> comprises developer's toolkit <NUM>. Developer's toolkit <NUM> comprises specification file creation module <NUM>, specification file storage <NUM>, specification file preprocessor <NUM>, compiler/linker <NUM>, and application execution module <NUM>. Specification file creation module <NUM> creates the function specification file as described with reference to <FIG>, block <NUM>. In one embodiment, specification file creation module <NUM> is an editor. Specification file storage module <NUM> stores the function specification file as described with reference to <FIG>, block <NUM>. Specification file preprocessor <NUM> preprocesses the function specification file to produce header information and function code for the interposing libraries as described in <FIG>, block <NUM> and <FIG>. Compiler/Linker <NUM> compiles the interposing libraries as described with reference to <FIG>, block <NUM>. Application execution module <NUM> executes the application using the interposing libraries as described with reference to <FIG>, block <NUM>.

<FIG> is a block diagram illustrating one embodiment of a specification file preprocessor <NUM> that generates function code and header information for the interposing library. In <FIG>, specification file preprocessor <NUM> comprises specification file parser <NUM>, function definition type module <NUM>, function runtime code generator <NUM>, function DLL code generator <NUM>, function call template code generator <NUM>, function OS service code generator <NUM>, and function interface generator <NUM>. Specification file parser <NUM> parses the function specification file definition as described in reference to <FIG>, block <NUM>. Function definition type module <NUM> determines the type of function definition as described in reference to <FIG>, blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Function runtime code generator <NUM> generates the runtime header information and function code as described with reference to <FIG>, block <NUM>. Function DLL code generator <NUM> generates the DLL header information and function code as described with reference to <FIG>, block <NUM>. Function call template generator <NUM> generates the function header information and function code using the function call template definition as described with reference to <FIG>, block <NUM>. Function OS service code generator <NUM> generates the OS service header information and function code as described with reference to <FIG>, block <NUM>. Function interface generator <NUM> generates the object and interface header information and function code as described with reference to <FIG>, block <NUM>.

<FIG> is a block diagram illustrating one embodiment of an interposing library <NUM> that comprises function(s) <NUM>. In one embodiment, interposing library <NUM> can be one or more libraries that interpose for operating services, DLL, and/or runtime libraries. Each function(s) <NUM> comprises logging module <NUM>, debug module <NUM>, and the call module <NUM>. In one embodiment, logging module <NUM> logs call to the particular function <NUM> using information related to timestamps, passed parameters, return values, and/or modified parameters as described with reference to one or more of <FIG>. Debug module <NUM> outputs debug information as described with reference to one or more of <FIG>. Call module <NUM> calls the function corresponding to function(s) <NUM> in an operating system service, DLL, and/or runtime library.

In practice, the methods described herein may constitute one or more programs made up of machine-executable instructions. Describing the method with reference to the flowchart in <FIG>, <FIG>, <FIG>, and <FIG> enables one skilled in the art to develop such programs, including such instructions to carry out the operations (acts) represented by logical blocks on suitably configured machines (the processor of the machine executing the instructions from machine-readable media, such as RAM (e.g. DRAM), ROM, nonvolatile storage media (e.g. hard drive or CD-ROM), etc.). The machine-executable instructions may be written in a computer programming language or may be embodied in firmware logic or in hardware circuitry. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interface to a variety of operating systems. In addition, the present invention is not described with reference to any particular programming language. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, logic. ), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a machine causes the processor of the machine to perform an action or produce a result. It will be further appreciated that more or fewer processes may be incorporated into the methods illustrated in the flow diagrams and that no particular order is implied by the arrangement of blocks shown and described herein.

<FIG> shows several computer systems <NUM> that are coupled together through a network <NUM>, such as the Internet. The term "Internet" as used herein refers to a network of networks which uses certain protocols, such as the TCP/IP protocol, and possibly other protocols such as the hypertext transfer protocol (HTTP) for hypertext markup language (HTML) documents that make up the World Wide Web (web). The physical connections of the Internet and the protocols and communication procedures of the Internet are well known to those of skill in the art. Access to the Internet <NUM> is typically provided by Internet service providers (ISP), such as the ISPs <NUM> and <NUM>. Users on client systems, such as client computer systems <NUM>, <NUM>, <NUM>, and <NUM> obtain access to the Internet through the Internet service providers, such as ISPs <NUM> and <NUM>. Access to the Internet allows users of the client computer systems to exchange information, receive and send e-mails, and view documents, such as documents which have been prepared in the HTML format. These documents are often provided by web servers, such as web server <NUM> which is considered to be "on" the Internet. Often these web servers are provided by the ISPs, such as ISP <NUM>, although a computer system can be set up and connected to the Internet without that system being also an ISP as is well known in the art.

The web server <NUM> is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the World Wide Web and is coupled to the Internet. Optionally, the web server <NUM> can be part of an ISP which provides access to the Internet for client systems. The web server <NUM> is shown coupled to the server computer system <NUM> which itself is coupled to web content <NUM>, which can be considered a form of a media database. It will be appreciated that while two computer systems <NUM> and <NUM> are shown in <FIG>, the web server system <NUM> and the server computer system <NUM> can be one computer system having different software components providing the web server functionality and the server functionality provided by the server computer system <NUM> which will be described further below.

Client computer systems <NUM>, <NUM>, <NUM>, and <NUM> can each, with the appropriate web browsing software, view HTML pages provided by the web server <NUM>. The ISP <NUM> provides Internet connectivity to the client computer system <NUM> through the modem interface <NUM> which can be considered part of the client computer system <NUM>. The client computer system can be a personal computer system, a network computer, a Web TV system, a handheld device, or other such computer system. Similarly, the ISP <NUM> provides Internet connectivity for client systems <NUM>, <NUM>, and <NUM>, although as shown in <FIG>, the connections are not the same for these three computer systems. Client computer system <NUM> is coupled through a modem interface <NUM> while client computer systems <NUM> and <NUM> are part of a LAN. While <FIG> shows the interfaces <NUM> and <NUM> as generically as a "modem," it will be appreciated that each of these interfaces can be an analog modem, ISDN modem, cable modem, satellite transmission interface, or other interfaces for coupling a computer system to other computer systems. Client computer systems <NUM> and <NUM> are coupled to a LAN <NUM> through network interfaces <NUM> and <NUM>, which can be Ethernet network or other network interfaces. The LAN <NUM> is also coupled to a gateway computer system <NUM> which can provide firewall and other Internet related services for the local area network. This gateway computer system <NUM> is coupled to the ISP <NUM> to provide Internet connectivity to the client computer systems <NUM> and <NUM>. The gateway computer system <NUM> can be a conventional server computer system. Also, the web server system <NUM> can be a conventional server computer system.

Alternatively, as well-known, a server computer system <NUM> can be directly coupled to the LAN <NUM> through a network interface <NUM> to provide files <NUM> and other services to the clients <NUM>, <NUM>, without the need to connect to the Internet through the gateway system <NUM>. Furthermore, any combination of client systems <NUM>, <NUM>, <NUM>, <NUM> may be connected together in a peer-to-peer network using LAN <NUM>, Internet <NUM> or a combination as a communications medium. Generally, a peer-to-peer network distributes data across a network of multiple machines for storage and retrieval without the use of a central server or servers. Thus, each peer network node may incorporate the functions of both the client and the server described above.

The following description of <FIG> is intended to provide an overview of computer hardware and other operating components suitable for performing the methods of the invention described above, but is not intended to limit the applicable environments. One of skill in the art will immediately appreciate that the embodiments of the invention can be practiced with other computer system configurations, including set-top boxes, hand-held devices, consumer electronic devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The embodiments of the invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network, such as peer-to-peer network infrastructure.

<FIG> shows one example of a conventional computer system that can be used in one or more aspects of the invention. The computer system <NUM> interfaces to external systems through the modem or network interface <NUM>. It will be appreciated that the modem or network interface <NUM> can be considered to be part of the computer system <NUM>. This interface <NUM> can be an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface, or other interfaces for coupling a computer system to other computer systems. The computer system <NUM> includes a processing unit <NUM>, which can be a conventional microprocessor such as an Intel Pentium microprocessor or Motorola Power PC microprocessor. Memory <NUM> is coupled to the processor <NUM> by a bus <NUM>. Memory <NUM> can be dynamic random access memory (DRAM) and can also include static RAM (SRAM). The bus <NUM> couples the processor <NUM> to the memory <NUM> and also to non-volatile storage <NUM> and to display controller <NUM> and to the input/output (I/O) controller <NUM>. The display controller <NUM> controls in the conventional manner a display on a display device <NUM> which can be a cathode ray tube (CRT) or liquid crystal display (LCD). The input/output devices <NUM> can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller <NUM> and the I/O controller <NUM> can be implemented with conventional well known technology. A digital image input device <NUM> can be a digital camera which is coupled to an I/O controller <NUM> in order to allow images from the digital camera to be input into the computer system <NUM>. The non-volatile storage <NUM> is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory <NUM> during execution of software in the computer system <NUM>. One of skill in the art will immediately recognize that the terms "computer-readable medium" and "machine-readable medium" include any type of storage device that is accessible by the processor <NUM> or by other data processing systems such as cellular telephones or personal digital assistants or MP3 players, etc..

Network computers are another type of computer system that can be used with the embodiments of the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory <NUM> for execution by the processor <NUM>. A Web TV system, which is known in the art, is also considered to be a computer system according to the embodiments of the present invention, but it may lack some of the features shown in <FIG>, such as certain input or output devices. A typical computer system will usually include at least a processor, memory, and a bus coupling the memory to the processor.

It will be appreciated that the computer system <NUM> is one example of many possible computer systems, which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an input/output (I/O) bus for the peripherals and one that directly connects the processor <NUM> and the memory <NUM> (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.

It will also be appreciated that the computer system <NUM> is controlled by operating system software, which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the family of operating systems known as MAC OS X from Apple Corporation in Cupertino, California, and their associated file management systems. The file management system is typically stored in the non-volatile storage <NUM> and causes the processor <NUM> to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage <NUM>.

It will be appreciated that computer system <NUM> could be a camera, video camera, scanner, or any other type image acquisition system. In one embodiment, image acquisition system comprises a lens, image sensor or other hardware typically associated with a camera, video camera, or other type if image acquisition system.

Claim 1:
A computerized method comprising:
providing a compiled function in a library by processing a function specification file, the compiled function compiled for a first operating system, and the function specification file including a keyword that indicates that stack checking code is to be added to the compiled function,
executing an application compiled for a second operating system in the first operating system using the compiled function and a loader, wherein the execution of the application occurs without the presence of the second operating system and the compiled function translates a function call for the second operating system to a corresponding function call in the first operating system, the stack checking code enforces a particular stack variable management scheme used by the second operating system for call stack manipulation when the compiled function is called, the particular stack variable management scheme used by the second operating system having a different convention for when to put function parameters onto the call stack and when to take these parameters off the stack than the stack variable management scheme used by the first operating system, and the loader is a first operating system based loader that loads and executes applications that are either first operating system or second operating system based applications.