Patent Description:
Applications utilize application programming interfaces (APIs) to communicate with an operating system and to command hardware elements to perform processing operations and render graphics. The particular set of API calls that an application is designed to utilize may be compatible with a single operating system.

Currently, there exist a limited number of solutions for running applications designed for different operating systems on a same device. The most common solution is to use a virtual machine that allows two different operating systems to execute side-by-side. However, it is highly memory intensive to simultaneously run two full operating systems including their respective kernels and the various drivers of the two different systems.

<CIT> describes techniques for implementing operating system layering. In one example, a method includes managing one or more container temporary storage spaces and one or more container runtime environments. Furthermore, the method includes loading, one or more drivers to provide compatibility between a container operating system and a host operating system, the one or more drivers comprising application program interface (API) compatibility libraries to enable API compatibility between the container operating system and the host operating system; metadata arbitration logic to enable compatibility between the container operating system and the host operating system by modifying container operating system references; and file arbitration logic to modify operating system file locations accessed by the container operating system and the host operating system.

<CIT> describes systems and methods for composing a dynamic runtime API set schema employing a base API set schema and a set of API set schema extensions. A base API set schema may be loaded into system memory at boot time with an associated set of host base binaries. A set of API set schema extensions binaries may also be loaded into system memory at boot time. At a second time, the API set schema extensions may be merged into the base API set schema on a dynamic as-needed basis.

A method for co-executing same-type subsystems on a same base operating system provides for loading a first API set schema and a second API set schema into memory. The first API set schema resolves an API set contract to a first host binary and the second API set schema resolves the API set contract to a second different host binary. The method further provides for executing elements of the first host binary responsive to receipt of a API call identified within the API set contract that is placed within a first runtime context and executing elements of the second different host binary responsive to receipt of the API call placed within a second runtime context.

These and various other features and advantages will be apparent from a reading of the following Detailed Description.

When an application sends commands to an operating system (OS) to initiate processing operations or render graphics, those commands are received and processed by a high-level subsystem that translates the commands into lower-level commands and, eventually, hardware control signals. A high-level subsystem is built to interpret a particular set of function calls referred to as an API set and to resolve those API function calls to corresponding binary executables.

Different operating systems may include different subsystems of a same type that are built to utilize different API sets. As used herein, "subsystem" refers to a subset of the functionality provided by an operating system (e.g. graphics, audio, wireless LAN, etc.). Two operating systems are referred to as being a "same type" of subsystem when they are designed to provide the same subset of the operating system functionality, such as graphics rendering, audio production, etc. For example, Windows <NUM> is a Microsoft operating system designed for desktop computing devices while Windows Mobile is a Microsoft operating system designed to run on lower-memory devices, such as phones and tablets. Windows <NUM> includes a first graphics subsystem, win32kfull. sys, and Windows Mobile includes a second graphics subsystem, win32kmin. Each of these same-type subsystems utilizes a different API set when communicating with its compatible applications and lower-level operating system components.

An API set is typically globally defined at the operating system level. For example, a first graphics subsystem in an electronic device may support a set of APIs defined in a contract "foo. " Regardless of which applications call APIs from the foo. dll contract, the operating system of the device maps this contract to a same host binary file that that is executed by the graphic subsystem upon receipt of the application call to "foo. " Different subsystems of a same type (such as the same-type graphics subsystems win32kmin. sys and win32kfull. sys) support different API sets that have some duplicative contract names and/or duplicative function names intended to correspond to different host binaries. For example, a higher memory graphics subsystem (e.g., win32kfull. sys) and a lower memory graphics subsystem (win32min. sys) may each define a function named "drawshape. dll" that is utilized to call a different executable and render a different type of graphic. This illustrates one challenge of designing a modern operating system that can run diverse applications initially written for compatibility with different operating systems.

The disclosed technology allows two or more applications designed for different operating systems to be executed simultaneously within one system running a single instance of a base operating system. The system runs a single base operating system and side-by-side versions of a same-type subsystems that utilize different API sets to communicate with compatible applications. As used herein, the term "base operating system" refers to at least an operating system kernel and kernel-mode device drivers that enable the kernel to interact with hardware devices.

The capability of executing multiple same-type subsystems (e.g., graphics subsystems) on top of a same base operating system improves the computer system by reducing the amount of memory that is consumed when co-executing applications designed for different operating systems. For example, this eliminates the need to use a virtual machine to execute a full, second operating system alongside a primary operating system executing on the host.

A software tool that evaluates the context in which an API call is placed. The context is evaluated on a per-application basis (e.g., context evaluation returns a same value for each call made by an application). Based on the associated context of a call to an API element, the API element is interpreted as belonging to a select one of multiple pre-loaded API set schemas. In essence, this allows a same API (function) call to be mapped to a first host binary when called within a first context and mapped to a second host binary when called within a second context.

<FIG> illustrates a first example system <NUM> for side-by-side execution of multiple same-type subsystems running on a same base operating system. The system <NUM> includes a processing device <NUM> and hardware <NUM> (such as a processor, display, etc.) and memory <NUM>. The memory <NUM> stores an operating system <NUM> including a base operating system <NUM> and at least two same-type subsystems (e.g., subsystems <NUM>, <NUM>) that utilize different API sets to when interfacing with one or more applications <NUM> of a supported subset. The first subsystems <NUM>, <NUM> are, in one implementation, subsystems that communicate with the base operating system <NUM> to render graphics and/or to perform compute operations in responsive to API calls initiated by one or more of the applications <NUM>. For example, the first subsystem <NUM> may utilize a first API (e.g., set of functions) to initiate graphics rendering operations for a first subset of the applications <NUM> and the subsystem <NUM> may utilize a second API to initiate graphics rendering operation for a second subset of the applications <NUM>.

The system <NUM> allows a user (not shown) to interact with at least two of the applications <NUM> - App A and App B that are initially designed for compatibility with two different operating systems. App A is an application initially designed for compatibility with and use on a processing device running a high-memory operating system <NUM>. For example, the high-memory operating system <NUM> may be an operating system designed for a desktop computer such as Windows <NUM>. The high-memory operating system <NUM> includes an instance of the first subsystem <NUM>, which is also included within the operating system <NUM> of the processing device <NUM>.

In contrast to App A, App B is an application initially designed for compatibility with and use on a processing device running a low-memory operating system <NUM> (as compared to the memory requirements of the high-memory operating system <NUM>). For example, the low-memory operating system <NUM> may be an operating system designed for a light-weight mobile phone or tablet with reduced memory and/or processing power as compared to a desktop computer that executes the high-memory operating system <NUM>. The low-memory operating system <NUM> includes an instance of the second subsystem <NUM>, which is also included within the operating system <NUM> of the processing device <NUM>.

App A is a software executable that, at run-time, declares it consumes multiple contracts including, for example, a first API set contract <NUM>. As used herein, "API set contract" refers to an API set name corresponding to a declared set of API functions. The first API set contract is part of a first API set schema that is globally defined in the high-memory operating system <NUM> and utilized by the first subsystem <NUM>. The term "API set schema" refers to a data structure that allows a mapping to be obtained - at run-time - from an API set contract to an associated binary that hosts the implementation of the API set contract.

In contrast to App A, App B is a software executable that, at run-time, declares it another set of contracts including, for example, a second API set contract <NUM>. The second API set contract is part of a second API set schema that is globally defined in the low-memory operating system <NUM>.

In the particular example provided, both the first API set contract <NUM> and the second API set contract <NUM> are identified within the system by a same API set name - "foo. " Despite this common API set name, the first API set contract and the second API set contract declare non-identical API sets. Further, some APIs declared by the first API set contract and the second API set contract may have identical function names, even if those functions were designed to correspond to different host binaries.

When the first subsystem <NUM> and the second subsystem <NUM> are executed on different base operating systems designed for compatibility with App A and App B, respectively, there is no ambiguity regarding which host binary corresponds to each API set contract. The high-memory operating system <NUM> is globally aware of a single API set schema and the low-memory operating system <NUM> is globally aware of a different single API set schema. However, when the first subsystem <NUM> and the second subsystem <NUM> are run on the same base operating system <NUM> within the processing device <NUM>, as in <FIG>, there then exist two different host binary files that are effectively mapped to a same API set contract. A runtime context evaluator <NUM> implements logic to resolve API calls of each different application to an associated one of the two different host binary files.

For example, App A and App B may, when compiled, declare consumption of the API set contract "foo. " At runtime for either application, the operating system <NUM> takes actions to determine which host binary to resolve the API set contract ("foo. To address this, the processing device <NUM> includes a runtime context evaluator <NUM> that evaluates a context of the runtime environment to determine a call context identifier usable for resolving API calls from the application to an associated host binary.

For example, the API call context identifier may determine which of the applications <NUM> is attempting to resolve the API set contract "foo. dll" and/or may identify a corresponding user login session in which the call was placed. Based on this call context information, the runtime context evaluator <NUM> selects one of multiple API set schemas that are loaded into memory space of the base operating system <NUM>. This runtime context evaluator <NUM> then uses the select API set schema to resolve the received API function call to a corresponding host binary.

In the illustrated example, the runtime context evaluator <NUM> of <FIG> determines that App A is the application attempting to resolve the contract named "foo. dll" and further determines that App A is associated in memory with the first API set schema utilized by the first subsystem <NUM>. In this case, the operating system <NUM> utilizes the first API set schema of the first subsystem <NUM> to resolve API calls placed by the application to a corresponding host binary.

<FIG> illustrates aspects of another example system <NUM> that supports side-by-side execution of same-type subsystems on a same base operating system. The system <NUM> includes a runtime context evaluator <NUM> which is, in one implementation, is the same or similar to the runtime context evaluator <NUM> of <FIG>.

The runtime context evaluator <NUM> includes an APIsetschema selector <NUM>. At runtime of an application, the runtime context evaluator <NUM> receives an instruction to resolve an API set contract declared by the application to an associated host binary. Responsive to this instruction, the runtime context evaluator <NUM> evaluates one or more runtime factors to determine a call context identifier. Using the determined call context identifier, the APIsetschema selector <NUM> resolves the specified API set contract to one of multiple API set schemas loaded into memory of an associated device operating system.

As explained above with respect to <FIG>, each API set contract defines a set of APIs that it exposes. For example, table <NUM> below illustrates a list of exemplary APIs exposed by an API set contract named "api-ms-win-core-com-L1-<NUM>-<NUM>.

At compile time, an application may declare one or more API set contracts, where each declared contract defines a set of APIs called by the application. For example, table <NUM> below illustrates an application "notepad. exe" declaring a set of APIs called by the application as well as the API set contract name ("api-ms-win-core-com-l1-<NUM>-<NUM>. dll") that exposes each API.

At boot time, the system <NUM> mounts a first API set schema <NUM> and a second API set schema <NUM> within the device operating system and into kernel address space. Each of the pre-loaded API set schemas loaded into memory is a data structure usable to resolve multiple API set contracts (e.g., contracts <NUM>, <NUM>, <NUM>) to an associated host binary (e.g., host binaries <NUM>, <NUM>, <NUM>). In one implementation, a first API set schema <NUM> and a second API set schema <NUM> are each embedded in a portable executable (PE) file - e.g., named apisetschema_1. dll and apisetschema_2. dll, respectively, and loaded into kernel memory space.

In the example of <FIG>, some API set contract names are duplicative included in the mapping provided by the first API set schema <NUM> and also in the mapping provided by the second API set schema <NUM>. However, these different API set schemas each maps these duplicative API set names to different host binaries. For example, the first API set schema <NUM> maps the API set contract "api-ms-win-core-com-<NUM>-<NUM>-<NUM>" to a host binary "%windire%\system32\combase. dll" and while the second API set schema <NUM> maps the same API set contract "api-ms-win-core-com-l1-<NUM>-<NUM>" to a different host binary "%windire%\system32\combase_2.

Based on the determined call context identifier, the APIsetschema selector <NUM> selects one of the multiple pre-loaded API set schemas (e.g., API set schema <NUM> or API set schema <NUM>) to resolve, at runtime of a particular application, the API set contract(s) declared by the application.

<FIG> illustrates another example system <NUM> for side-by-side execution of different same-type subsystems running on a same base operating system. The system <NUM> includes a computer <NUM> executing an operating system <NUM> with a user mode <NUM> and a kernel mode <NUM>. The user mode <NUM> includes, among other software components (not illustrated), a unified graphics subsystem <NUM> that includes a number of graphics binary files (e.g., GraphicsBinary1, GraphicsBinary2. Graphics Binary N). In one implementation, these various graphics binary files represent graphics subsystem executables each designed to provide graphics support on a different operating system platform. Individually, each of the graphics binary files hosts the implementation of an associated API set contract that may be declared by one or more compatible applications at compilation time.

In addition to the various graphics binary files (e.g., side-by-side implementations of different graphics subsystems), the operating system <NUM> also includes a runtime context evaluator <NUM> including an APIsetschema selector <NUM>. Responsive to each detected application launch event, the runtime context evaluator <NUM> determines a call context identifier based on one or more runtime factors <NUM> describing a runtime context (e.g., runtime environment) in which the associated application was launched.

The APIsetschema selector <NUM> uses the identified call context identifier to select one of multiple preloaded API set schemas <NUM>, <NUM> to resolve the application's APIs to an associated host binary.

By example and without limitation, <FIG> illustrates the runtime factors <NUM> as including a session ID and/or an App ID (e.g., an application identifier). In different implementations, these runtime factors <NUM> may alone, in combination, or in combination with other runtime factors, serve as the call context identifier that is used to select which of the multiple preloaded API set schemas <NUM>, <NUM> to use for resolving an API set contract declared by an application to an associated host binary.

In one implementation, the call context identifier includes a login session ID. In the example of <FIG>, the operating system <NUM> has initialized two exemplary login sessions with session identifiers "session <NUM>" and "session <NUM>. " A login session may be understood as consisting of all of the processes and other system objects (e.g., windows, desktops, and window stations) representing a single user's logon session. For example, session <NUM> may be associated with a first user account while session <NUM> is associated within a second user account. In another implementation, session <NUM> is a specialized session where the GUI components (e.g. windows, dialog boxes, popups, etc.) of interactive services are displayed in complete isolation from the desktop shell graphics and user applications in windows that are displayed in session <NUM>.

In some implementations, the session ID identifies a container in which the associated application is launched. For example, each of the sessions (session <NUM>, session <NUM>) may be booted within a different container that is created by the operating system <NUM>. In general, the term container refers to an isolated, resource controlled, and portable runtime environment which runs on a host machine or virtual machine. Each application or process that runs in a container is packaged with all the required dependencies and configuration files. In one implementation, session <NUM> and session <NUM> run in different containers that share the operating system kernel <NUM> and execute side-by-side without the use of a virtual machine.

In one implementation, the session ID is assigned by the operating system at session creation time to an initial process running the session (e.g., a login process). Each child and descendant process of the initial process then inherits that session ID. In one implementation where the call context identifier includes the session ID, the runtime context evaluator <NUM> queries the parent process responsible for launching App A during the launch sequence. From this query, the runtime context evaluator <NUM> determines that App A is being launched in session <NUM> and provides this session ID to the APIsetschema selector <NUM>. The APIsetschema selector <NUM> determines that session <NUM> is associated in memory with a first API set schema of the multiple API set schema <NUM>, <NUM> loaded in kernel memory space. Consequently, the APIsetschema selector <NUM> selects the first API set schema as the schema to use when resolving APIs of newly-initialized instance of App A.

In still another implementation, the runtime context evaluator <NUM> identifies the call context identifier on a per-application basis, such as based on an application identifier (App ID) identifying an application being launched for which API resolution is requested. For example, the APIsetschema selector <NUM> may implement logic to select a first API set schema when launching App A and to select a second API set schema when launching another application (e.g., App B). In one implementation, the runtime context evaluator <NUM> queries a database at runtime for an application that contains a list of application IDs each associated with an API set schema pre-designated for use in association with each application ID. The runtime context evaluator <NUM> selects the API set schema that is pre-associated in the database with an application ID for the application currently being launched.

In another implementation, the runtime context evaluator <NUM> uses a property attached to the application being launched to select the API set schema to use to resolve API calls placed by the application. For example, some operating systems support a "capability" property for each application. In this case, an application's capability may determine how the runtime context evaluator <NUM> is to select the API set schema.

In still other cases, the call context identifier is based on multiple runtime factors <NUM>, such as session ID and app ID in combination with one another or in combination with still other factors not shown in <FIG> including, without limitation, factors such as the current load of the system or the quality of service level requested by the application. For example API set schema may give access to hardware that provides accelerated implementation of some functions and the API set schema may be selected based on the quality of service level requested. In one implementation, the APIsetschema selector <NUM> may reference a table that identifies a select one of the multiple API set schemas that is to be selected when multiple runtime factors collectively satisfy an associated defined runtime condition. For example, one exemplary runtime condition may provide for selection of the first API set schema <NUM> when App A is launched in containers <NUM> or <NUM> or when App B is launched in container <NUM>. At the same time, another exemplary runtime condition may provide for selection of the second API set schema <NUM> when App A is launched within container <NUM> or when App B is launched in containers <NUM> or <NUM>.

In <FIG>, a user performs an action that triggers launch of an application (App A) within session <NUM>. When App A is launched, App A transmits a request to the operating system to request resolution of a specified API set contract that was declared by the application at compilation time.

Upon receipt of the request to resolve a specified API set contract, the operating system employs a runtime context evaluator <NUM> to determine how to resolve the API set contract identified by the request. The runtime context evaluator <NUM> evaluates one or more of the runtime factors <NUM> and, based on this evaluation, determines a call context identifier. In general, the call context identifier is an identifier characterizing the context of API calls that are to be made by App A in the instance of App A that is launched by the user action that initiated the API set contract resolution request. The APIsetschema selector <NUM> determines which one of the multiple pre-loaded API set schema <NUM>, <NUM> is associated in memory with the determined call context identifier and selects this API set schema for resolving API calls placed by the application.

A binary loader (not shown) of the operating system <NUM> performs the contract to host binary resolution by looking up and loading the selected API set schema selected by the runtime context evaluator <NUM>. While the application is executing, each API function call placed by the application is resolved by the operating system <NUM> to a host binary identified by the selected API set schema (e.g., one of GraphicsBinary1, GraphicsBinary2. GraphicsBinaryN).

In addition to the above-described components executing in the user mode <NUM>, the operating system <NUM> also includes various software components executing in the kernel mode <NUM> to facilitate the generation of control signals to command device hardware <NUM> in response to the various API function calls placed by application(s) executing in the user mode <NUM>. The kernel mode <NUM> represents an exemplary base operating system that provides support for side-by-side execution of same-system subsystems.

Among other components, the kernel mode <NUM> includes an operating system kernel <NUM>, a graphics subsystem driver <NUM>, and a variety of other drivers (e.g., other kernel mode drivers <NUM>), such as file system drivers and drivers to control peripheral hardware such as a display, keyboard, etc..

In one implementation, the graphics subsystem driver <NUM> is a kernel-mode device driver that provides kernel mode support for the unified graphics subsystem <NUM>. The graphics subsystem driver <NUM> is part of the lower-level graphics pipeline and serves as an interface between the unified graphics subsystem <NUM> and the device hardware <NUM>. For example, the graphics subsystem driver <NUM> may control window displays, manage screen output; collect input from peripheral accessories such as a keyboard and mouse, and pass the collected inputs to user mode applications.

Notably, the graphics subsystem driver <NUM> may utilize an API set for communicating with a hardware abstraction layer <NUM> and device hardware <NUM> that is different than the API sets utilized in the user mode <NUM>. For this reason, some implementations of this technology may provide a mechanism for loading multiple kernel-mode API set schemas in kernel mode memory space and selectively switching between the kernel-mode API set schemas to provide kernel-mode extensions for the processing actions initiated at the application layer in the user mode <NUM>. For example, an indirection table (not shown) may be utilized at application runtime to dynamically select whichever one of the kernel mode API set schemas that corresponds to the user mode API set schema has been selected by the runtime context evaluator <NUM>.

Further, the operating system <NUM> also includes a unified service table <NUM> that acts as a translation layer between user mode APIs, such as the API used by the unified graphics subsystem <NUM> and APIs used within the kernel mode <NUM>. The unified service table <NUM> enables the shared operating system kernel <NUM> to serve multiple environments (e.g., same-type subsystems) and their associate API set schemas by exposing the union of the kernel-mode services called by the union of API set contract-to-host mappings across all supported API set schemas.

For example, in <FIG>, GraphicsBinary1 may call a kernel mode service S1 while Graphics Binary2 may call a kernel mode service S2. Since the kernel mode is shared by the same-type subsystems, the unified service table <NUM> includes both S1 and S2. GraphicsBinary1 or GraphicsBinary2 (e.g., two same-type graphics subsystems).

Since the kernel mode <NUM> and unified service table <NUM> are shared by all subsystems within the unified graphics subsystem <NUM>, all services in the unified service table <NUM> may be called by any application regardless of the selected API set schema. This creates a potential security vulnerability in that a malicious application can handcraft a call to a service that is not normally reached via the application's associated API set schema. For example, an application assigned to APIsetschema_1. dll by the runtime context evaluator <NUM> can directly call service S2, which is normally reachable exclusively through an application assigned to APIsetschema_2.

In one implementation, the operating system <NUM> mitigates this potential security vulnerability by executing logic of the runtime context evaluator <NUM> again each time the unified service table <NUM> is accessed. For example, the runtime context evaluator <NUM> may, during an application launch sequence, evaluate one or more of the runtime factors <NUM> to determine that the launching application is assigned to APIsetschema_1. When the application subsequently places a call to the unified service table <NUM> for a service S <NUM>, the runtime context evaluator <NUM> may again check the runtime factor(s) <NUM> in real time (e.g., session ID, app ID) to confirm which API set schema is selected and to verify that the selected API set schema supports the requested service S1. This real-time check may, for example, prevent an application assigned to use APIsetschema_1. dll from calling a service S2 that was designed for applications assigned to use different API set schema.

<FIG> illustrates example operations <NUM> for side-by-side execution of same-type subsystems executing on a shared base operating system. A loading operation <NUM> loads multiple API set schemas into volatile memory of a device during a boot sequence. Each of the API set schemas resolves one or more API set contracts to an associated binary hosting an implementation of the contract. Each of the API set contracts included within the API set schemas declares an associated set of API functions exported by the contract.

A receiving operation <NUM> receives a request to resolve a select one of the API set contracts to an associated host binary. An evaluation operation <NUM> evaluates run-time parameters associated with the request to determine a call context identifier. A selecting operation <NUM> uses the determined call context identifier to select one of the multiple API set schemas for resolving the API set contract to an associated host binary. For example, the call context identifier may identify an application that placed the API set contract resolution request or a session ID for a container in which the requesting application is executing. A resolving operation <NUM> resolves the API set contract to a select host binary according to a mapping defined by the selected API set schema, and an execution operation <NUM> executes elements of the selected host binary responsive to receipt of API calls from the application.

<FIG> illustrates an example schematic of a processing device <NUM> suitable for implementing aspects of the disclosed technology. The processing device <NUM> includes one or more processor unit(s) <NUM>, memory <NUM>, a display <NUM>, and other interfaces <NUM> (e.g., buttons). The memory <NUM> generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system <NUM>, such as the Microsoft Windows® operating system, the Microsoft Windows® Mobile operating system or a specific operating system designed for a gaming device, resides in the memory <NUM> and is executed by the processor unit(s) <NUM>, although it should be understood that other operating systems may be employed.

One or more applications <NUM>, are loaded in the memory <NUM> and executed on the operating system <NUM> by the processor unit(s) <NUM>. Applications <NUM> may receive input from various input local devices such as a microphone <NUM>, input accessory <NUM> (e.g., keypad, mouse, stylus, touchpad, gamepad, racing wheel, joystick). Additionally, the applications <NUM> may receive input from one or more remote devices, such as remotely-located smart devices, by communicating with such devices over a wired or wireless network using more communication transceivers <NUM> and an antenna <NUM> to provide network connectivity (e.g., a mobile phone network, Wi-Fi®, Bluetooth®). The processing device <NUM> may also include various other components, such as a positioning system (e.g., a global positioning satellite transceiver), one or more accelerometers, one or more cameras, an audio interface (e.g., the microphone <NUM>, an audio amplifier and speaker and/or audio jack), and storage devices <NUM>. Other configurations may also be employed.

The processing device <NUM> further includes a power supply <NUM>, which is powered by one or more batteries or other power sources and which provides power to other components of the processing device <NUM>. The power supply <NUM> may also be connected to an external power source (not shown) that overrides or recharges the built-in batteries or other power sources. In an example implementation, a task-scheduling recommendation tool may include hardware and/or software embodied by instructions stored in the memory <NUM> and/or the storage devices <NUM> and processed by the processor unit(s) <NUM>. The memory <NUM> may be the memory of a host device or of an accessory that couples to the host.

The processing device <NUM> may include a variety of tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage can be embodied by any available media that can be accessed by the processing device <NUM> and includes both volatile and nonvolatile storage media, removable and non-removable storage media. Tangible computer-readable storage media excludes intangible and transitory communications signals and includes volatile and nonvolatile, removable and non-removable storage media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Tangible computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store the desired information, and which can be accessed by the processing device <NUM>. In contrast to tangible computer-readable storage media, intangible computer-readable communication signals may embody computer readable instructions, data structures, program modules or other data resident in a modulated data signal, such as a carrier wave or other signal transport mechanism. By way of example, and not limitation, intangible communication signals include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

Some implementations may comprise an article of manufacture. An article of manufacture may comprise a tangible storage medium (a memory device) to store logic. Examples of a storage medium may include one or more types of processor-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and/or operations in accordance with the described implementations. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a computer to perform a certain operation segment. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

Claim 1:
A method comprising:
loading into memory (<NUM>) a first application programming interface, API, set schema (<NUM>, <NUM>) resolving a first API set contract (<NUM>) to a first host binary (<NUM>), wherein the first host binary (<NUM>) is an executable of a first subsystem, and the first API set contract (<NUM>) is used by the first subsystem to communicate with compatible applications;
loading into the memory (<NUM>) a second API set schema (<NUM>, <NUM>) resolving a second API set contract to a second different host binary (<NUM>), wherein:
the second host binary (<NUM>) is an executable of a second subsystem, and the second API set contract (<NUM>) is used by the second subsystem to communicate with compatible applications;
the first subsystem and the second subsystem are same-type subsystems that share a base operating system in a computing device; and
the first API set contract (<NUM>) and the second API set contract (<NUM>) are identified by a same API set name;
receiving an API call from an application running on the computing device, the API call being identified by the same API set name;
evaluating a runtime context in which the API call was placed, wherein the runtime context is evaluated on a per-application basis, and wherein evaluating the runtime context resolves API calls of applications to an associated one of the first host binary (<NUM>) or the second host binary (<NUM>); and either:
mapping the API call to the first host binary (<NUM>) when the API call is called within a first runtime context; and
executing elements of the first host binary (<NUM>) responsive to receipt of the API call within the first runtime context; or
mapping the API call to the second different host binary (<NUM>) when the API call is called within a second runtime context; and
executing elements of the second different host binary (<NUM>) responsive to receipt of the API call within the second runtime context.