Parallel execution of subsystems of the same type with a shared base operating system

Abstract

A method for executing parallel subsystems of the same type includes storing a plurality of application programming interface (API) collection patterns in a memory. A first API collection pattern in the API collection patterns resolves the API collection contract into a first host binary, and a second API collection pattern in the API collection patterns resolves the API collection contract into a different host binary. The method further includes: executing an element of the first host binary in response to receiving an API call identified by the API collection contract received within a first runtime context; and executing an element of the second host binary in response to receiving an API call within a second runtime context.

Description

Background Art

[0001] In recent years, the number of mobile electronic devices in the home has increased significantly. It is not uncommon for users to have two or more personal devices for executing local and / or cloud-based applications. The development of the mobile electronics industry has forced the design and market production of a variety of different types of operating systems. Some operating systems are designed to have higher memory requirements to support local execution of memory-intensive applications (such as applications for games and graphic design). Other operating systems are designed to have lower memory requirements in order to be integrated into cheaper and less powerful electronic products. In some cases, these different operating systems share the same code base and are closely related, such as Windows Desktop and Windows Mobile.

[0002] Applications use application programming interfaces (APIs) to communicate with the operating system and command hardware elements to perform processing operations and draw graphics. A specific set of API calls that an application is designed to use may be compatible with a single operating system.

[0003] Currently, there are a limited number of modes for running applications designed for different operating systems on the same device. The most common solution is to use a virtual machine that allows two different operating systems to execute side by side. However, running two complete operating systems (including their corresponding kernels and various drivers for two different systems) at the same time will take up a lot of memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 An example system for parallel execution of subsystems of the same type running on the same base operating system is shown.

[0005] Figure 2 Aspects of another example system for parallel execution of subsystems of the same type running on the same base operating system are shown.

[0006] Figure 3 Another example system for parallel execution of different subsystems of the same type running on the same base operating system is shown.

[0007] Figure 4 Example operations are shown for parallel execution of subsystems of the same type executing on a shared base operating system.

[0008] Figure 5 An example schematic diagram of a processing device suitable for implementing aspects of the disclosed technology is shown. Summary of the invention

[0009] A method for co-executing subsystems of the same type on the same base operating system provides loading a first API set schema and a second API set schema into a memory. The first API set schema resolves an API set contract into a first host binary, and the second API set schema resolves the API set contract into a second, different host binary. The method also provides executing elements of the first host binary in response to receipt of an identified API call within the API set contract placed within a first runtime context, and executing elements of the second, different host binary in response to receipt of an API call placed within a second runtime context.

[0010] This Summary is provided to introduce some concepts in a simplified form, which are further described in the Detailed Description below. This Summary is neither intended to identify key features or essential features of the claimed subject matter nor to be used to limit the scope of the claimed subject matter. These and various other features and advantages will become apparent upon reading the following Detailed Description. DETAILED DESCRIPTION

[0011] When an application sends commands to the operating system (OS) to initiate processing operations or draw graphics, these commands are received and processed by the high-level subsystem, which converts the commands into low-level commands and ultimately into hardware control signals. The high-level subsystem can be built to interpret a specific set of function calls called an API set and resolve these API function calls into corresponding binary executables.

[0012] Different operating systems can include different subsystems of the same type that are constructed to utilize different API sets. As used herein, "subsystem" refers to a subset of the functions provided by the operating system (e.g., graphics, audio, wireless LAN, etc.). When two operating systems are designed to provide the same subset of operating system functions (such as graphics rendering, audio production, etc.), they are referred to as "same type" subsystems. For example, Windows 10 is a Microsoft operating system designed for desktop computing devices, and Windows Mobile is a Microsoft operating system designed to run on lower memory devices (such as phones and tablets). Windows 10 includes a first graphics subsystem win32kfull.sys, and Windows Mobile includes a second graphics subsystem win32kmin.sys. Each of these same type subsystems uses different API sets when communicating with its compatible applications and lower-level operating system components.

[0013] API sets are typically defined globally 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.dll". Regardless of which applications call the APIs from the foo.dll contract, the device's operating system maps the contract to the same host binary, which is executed by the graphics subsystem when an application call to "foo.dll" is received. Different subsystems of the same type (such as the same type of graphics subsystems win32kmin.sys and win32kfull.sys) may support different API sets with some duplicate contract names and / or duplicate 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" for calling different executables and drawing different types of graphics. This illustrates the challenge of designing a modern operating system that can run a variety of applications that were originally written to be compatible with different operating systems.

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

[0015] The ability to execute multiple subsystems of the same type (e.g., a graphics subsystem) on top of the same base operating system improves computer systems by reducing the amount of memory consumed when applications designed for different operating systems are co-executed. For example, this eliminates the need to use a virtual machine to execute a complete second operating system along with the main operating system executing on the host computer.

[0016] According to one implementation, the foregoing is implemented in part by a software tool that evaluates the context in which an API call is placed. In one implementation, the context is evaluated on a per-application basis (e.g., the context evaluation returns the same value for each call made by an application). Based on the associated context of the call to the API element, the API element is interpreted as belonging to one of a plurality of preloaded API collection patterns. Essentially, this allows the same API (function) call to be mapped to a first host binary when called within a first context, and to a second host binary when called within a second context.

[0017] Figure 1 A first example system 100 for parallel execution of multiple subsystems of the same type running on the same base operating system is shown. The system 100 includes a processing device 102 and hardware 126 (such as a processor, a display, etc.) and a memory 108. The memory 108 stores an operating system 116, which includes a base operating system 120 and at least two subsystems of the same type (e.g., a first subsystem 122 and a second subsystem 124), which utilize different API sets when interacting with one or more applications 110 of a supported subset. Although other implementations are contemplated, in one implementation, the first subsystem 122 and the second subsystem 124 are subsystems that communicate with the base operating system 120 to draw graphics and / or perform computing operations in response to API calls initiated by one or more applications 110. For example, the first subsystem 122 can utilize a first API (e.g., a set of functions) to initiate graphics drawing operations for a first subset of applications 110, and the second subsystem 124 can utilize a second API to initiate graphics drawing operations for a second subset of applications 110.

[0018] The system 100 allows a user (not shown) to interact with at least two applications (application A and application B) of the applications 110 that were originally designed to be compatible with two different operating systems. Application A is an application that was originally designed to be compatible with and used on a processing device running a high-memory operating system 112. For example, the high-memory operating system 112 may be an operating system designed for a desktop computer such as Windows 10. The high-memory operating system 112 includes an instance of a first subsystem 122, which is also included within the operating system 116 of the processing device 102.

[0019] Compared to application A, application B is an application that was originally designed to be compatible with and used on a processing device running a low-memory operating system 114 (compared to the memory requirements of the high-memory operating system 112). For example, the low-memory operating system 114 may be an operating system designed for a lightweight mobile phone or tablet computer with reduced memory and / or processing power compared to a desktop computer executing the high-memory operating system 112. The low-memory operating system 114 includes an instance of a second subsystem 124, which is also included within the operating system 116 of the processing device 102.

[0020] Application A is a software executable that declares at runtime that it consumes multiple contracts, including, for example, a first API set contract 128. As used herein, an "API set contract" refers to an API set name corresponding to a declared set of API functions. In one implementation, the first API set contract is part of a first API set schema that is globally defined in the high memory operating system 112 and utilized by the first subsystem 122. The term "API set schema" refers to a data structure that allows a mapping from an API set contract to an associated binary that hosts an implementation of the API set contract to be obtained at runtime.

[0021] Compared to application A, application B is a software executable that declares another set of contracts at runtime, including, for example, the second API set contract 130. In one implementation, the second API set contract is part of a second API set schema globally defined in the low memory operating system 114.

[0022] In the specific example provided, both the first API set contract 128 and the second API set contract 130 are identified within the system by the same API set name ("foo.dll"). Despite this common API set name, the first API set contract and the second API set contract may declare different API sets. Furthermore, certain APIs declared by the first API set contract and the second API set contract may have the same function names, even if these functions are designed to correspond to different host binaries.

[0023] When the first subsystem 122 and the second subsystem 124 are executed on different base operating systems designed for compatibility with application A and application B, respectively, there is no ambiguity as to which host binary corresponds to each API set contract. The high memory operating system 112 is globally aware of a single API set schema, and the low memory operating system 114 is globally aware of a different single API set schema. However, when the first subsystem 122 and the second subsystem 124 are running on the same base operating system 120 within the processing device 102, as shown in FIG. Figure 1 As shown, there are two different host binaries that are effectively mapped to the same API set contract. The runtime context evaluator 118 implements logic to resolve the API calls of each different application to the associated one of the two different host binaries.

[0024] For example, when compiled, application A and application B may declare to consume an API collection contract "foo.dll". At runtime for either application, operating system 116 takes steps to determine which host binary will resolve the API collection contract ("foo.dll"). To address this issue, processing device 102 includes a runtime context evaluator 118 that evaluates the context of the runtime environment to determine a call context identifier that can be used to resolve an API call from an application to an associated host binary.

[0025] For example, the API call context identifier may determine which of the applications 110 is attempting to resolve the API collection contract "foo.dll" and / or may identify the corresponding user login session in which the call is placed. Based on the call context information, the runtime context evaluator 118 selects one of a plurality of API collection modes loaded into the memory space of the base operating system 120. The runtime context evaluator 118 then uses the selected API collection mode to resolve the received API function call into the corresponding host binary.

[0026] In the example shown, Figure 1 The runtime context evaluator 118 determines that application A is an application attempting to resolve a contract named "foo.dll", and further determines that application A is associated with a first API collection mode memory utilized by the first subsystem 122. In this case, the operating system 116 utilizes the first API collection mode of the first subsystem 122 to resolve the API calls placed by the application into corresponding host binaries.

[0027] Figure 22 shows aspects of another example system 200 that supports parallel execution of subsystems of the same type on the same base operating system. The system 200 includes a runtime context evaluator 202 that, in one implementation, is coupled to a runtime context evaluator 202. Figure 1 The runtime context evaluator 118 of can be the same or similar.

[0028] The runtime context evaluator 202 includes an API set schema selector 204. At runtime of the application, the runtime context evaluator 202 receives an instruction to resolve an API set contract declared by the application into an associated host binary. In response to the instruction, the runtime context evaluator 202 evaluates one or more runtime factors to determine a call context identifier. The API set schema selector 204 uses the determined call context identifier to resolve the specified API set contract into one of a plurality of API set schemas loaded into the memory of the associated device operating system.

[0029] As mentioned above about Figure 1 As explained, each API collection contract defines a set of APIs that it exposes. For example, Table 1 below shows a list of exemplary APIs exposed by an API collection contract named "api-ms-win-core-com-L1-1-0.dll".

[0030] Table 1:

[0031]

[0032] At compile time, an application can declare one or more API collection contracts, where each declared contract defines a set of APIs called by the application. For example, Table 2 below shows a set of APIs declared by the application "notepad.exe" and the API collection contract name ("api-ms-win-core-com-l1-1-0.dll") that exposes each API.

[0033] Table 2:

[0034]

[0035]

[0036] At boot time, the system 200 installs the first API set schema 206 and the second API set schema 208 within the device operating system and into the kernel address space. Each of the preloaded API set schemas loaded into the memory is a data structure that can be used to resolve multiple API set contracts (e.g., contracts 214, 216, 218) into associated host binaries (e.g., host binaries 220, 222, 224). In one implementation, the first API set schema 206 and the second API set schema 208 are each embedded in a portable executable (PE) file (e.g., named apisetschema_1.dll and apisetschema_2.dll, respectively) and loaded into the kernel memory space.

[0037] exist Figure 2 In the example of FIG. 2 , some API collection contract names are repeated and are included in the mapping provided by the first API collection pattern 206 and are also included in the mapping provided by the second API collection pattern 208. However, each of these different API collection patterns maps these repeated API collection names to different host binaries. For example, the first API collection pattern 206 maps the API collection contract "api-ms-win-core-com-l1-1-0" to the host binary "%windire%\system32\combase.dll", while the second API collection pattern 208 maps the same API collection contract "api-ms-win-core-com-l1-1-0" to a different host binary "%windire%\system32\combase_2.dll".

[0038] Based on the determined calling context identifier, the APIsetschema selector 204 selects one of a plurality of preloaded API set schemas (eg, the first API set schema 206 or the second API set schema 208 ) to resolve the API set schema(s) declared by the application at runtime of the particular application.

[0039] Figure 3Another example system 300 for parallel execution of different subsystems of the same type running on the same base operating system is shown. System 300 includes a computer 326 executing an operating system 308 having a user mode 322 and a kernel mode 324. In addition to other software components (not shown), user mode 322 also includes a unified graphics subsystem 306, which includes multiple graphics binary files (e.g., GraphicsBinary1, GraphicsBinary2, ..., GraphicsBinaryN). In one implementation, these various graphics binary files represent graphics subsystem executables, each of which is designed to provide graphics support on different operating system platforms. Individually, each of the graphics binary files hosts an implementation of an associated API collection contract, which can be declared by one or more compatible applications at compile time.

[0040] In addition to various graphics binaries (e.g., parallel implementations of different graphics subsystems), operating system 308 includes runtime context evaluator 302, which includes API set schema selector 304. In response to each detected application launch event, runtime context evaluator 302 determines a call context identifier based on one or more runtime factors 328 that describe the runtime context (e.g., runtime environment) in which the associated application was launched.

[0041] The API set schema selector 304 uses the identified call context identifier to select one of a plurality of preloaded first API set schemas 340 and second API set schemas 342 to resolve the application's API to an associated host binary.

[0042] By way of example and not limitation, Figure 3 Runtime factors 328 are shown to include a session ID and / or an application ID (e.g., an application identifier). In different implementations, these runtime factors 328 can be used alone, in combination, or in conjunction with other runtime factors as a call context identifier for selecting which of a plurality of preloaded first API set patterns 340 or second API set patterns 342 to resolve an API set contract declared by an application into an associated host binary.

[0043] In one implementation, the call context identifier includes a login session ID. Figure 3In the example of , operating system 308 has initialized two exemplary login sessions with session identifiers "Session 0" and "Session 1". A login session can be understood to consist of all processes and other system objects (e.g., windows, desktops, and window stations) that represent a single user's login session. For example, Session 0 can be associated with a first user account, while Session 1 can be associated within a second user account. In another implementation, Session 0 is a specialized session in which GUI components of interactive services (e.g., windows, dialog boxes, pop-up windows, etc.) are displayed in a manner that is completely isolated from desktop shell graphics and user applications in windows displayed in Session 1.

[0044] In some implementations, the session ID identifies the container in which the associated application is launched. For example, each session in the session (session 0, session 1) can be launched in a different container created by the operating system 308. In general, the term "container" refers to an isolated, resource-controlled, and portable runtime environment that runs on a host or virtual machine. Each application or process running in a container is packaged together with all necessary dependencies and configuration files. In one implementation, session 1 and session 2 run in different containers (different containers share the operating system kernel 314) and execute in parallel without using virtual machines.

[0045] In one implementation, a session ID is assigned by the operating system to the initial process (e.g., a login process) running the session when the session is created. Each child and descendant process of the initial process will then inherit the session ID. In one implementation in which the call context identifier includes the session ID, the runtime context evaluator 302 queries the parent process responsible for launching application A during the startup sequence. Based on the query, the runtime context evaluator 302 determines that application A is being launched in session 1 and provides the session ID to the APIsetschema selector 304. The APIsetschema selector 304 determines that session 1 is associated in memory with a first API set pattern of a plurality of loaded first API set patterns 340 or second API set patterns 342 in kernel memory space. Therefore, the APIsetschema selector 304 selects the first API set pattern as the pattern to be used when resolving the API of the newly initialized instance of application A.

[0046] In yet another implementation, the runtime context evaluator 302 identifies a call context identifier on a per-application basis, such as based on an application identifier (application ID) that identifies the application for which the API resolution request is being initiated. For example, the APIsetschema selector 304 may implement logic to select a first API set schema when launching application A and select a second API set schema when launching another application (e.g., application B). In one implementation, the runtime context evaluator 302 queries a database containing a list of application IDs for an application at runtime, wherein each application ID is associated with an API set schema pre-designated for association with each application ID. The runtime context evaluator 302 selects an API set schema that is pre-associated in the database with the application ID of the currently launched application.

[0047] In another implementation, the runtime context evaluator 302 uses properties attached to the application being launched to select an API collection mode for resolving API calls placed by the application. For example, some operating systems support a "capability" property for each application. In this case, the capabilities of the application can determine how the runtime context evaluator 302 selects the API collection mode.

[0048] In other cases, the call context identifier is based on multiple runtime factors 328, such as in combination with each other or with Figure 3 The session ID and application ID may be combined with other factors shown in , including but not limited to factors such as the current load of the system or the quality of service level requested by the application. For example, an API set mode may access hardware that provides accelerated implementation of certain functions, and the API set mode may be selected based on the requested quality of service level. In one implementation, the APIsetschema selector 304 may reference a table that identifies a selected API set mode from a plurality of API set modes to be selected when multiple runtime factors collectively satisfy associated defined runtime conditions. For example, an exemplary runtime condition may provide for selection of a first API set mode 340 when application A is launched in container 0 or 1 or when application B is launched in container 2. At the same time, another exemplary runtime condition may provide that a second API set mode 342 is selected when application A is launched in container 2 or application B is launched in container 0 or 1.

[0049] exist Figure 3 In the example, the user performs an operation that triggers the launch of application A in session 1. When application A is launched, application A transmits a request to the operating system to request that the specified API set contract declared by the application be parsed at compile time.

[0050] Upon receiving a request to resolve a specified API set contract, the operating system employs a runtime context evaluator 302 to determine how to resolve the API set contract identified by the request. The runtime context evaluator 302 evaluates one or more runtime factors 328 and determines a call context identifier based on the evaluation. Typically, a call context identifier is an identifier that characterizes the context of an API call that will be made by application A in an instance of application A that is initiated by a user action that initiates an API set contract resolution request. The APIsetschema selector 304 determines which of a plurality of preloaded first API set schemas 340 or second API set schemas 342 is associated in memory with the determined call context identifier, and selects the API set schema to resolve the API call placed by the application.

[0051] The binary loader (not shown) of the operating system 308 performs the contract to host binary resolution by looking up and loading the selected API set pattern selected by the runtime context evaluator 302. When the application is executed, each API function call placed by the application is resolved by the operating system 308 to the host binary identified by the selected API set pattern (e.g., one of GraphicsBinary1, GraphicsBinary2, ..., GraphicsBinaryN).

[0052] In addition to the components executing in user mode 322 described above, operating system 308 includes various software components executing in kernel mode 324 to facilitate the generation of control signals to command device hardware 320 in response to various API function calls placed by application(s) executing in user mode 322. Kernel mode 324 represents an exemplary basic operating system that provides support for concurrent execution of the same system subsystems.

[0053] Kernel mode 324 includes, among other components, an operating system kernel 314, a graphics subsystem driver 312, and various other drivers (eg, other kernel mode drivers 316), such as file system drivers and drivers that control peripheral hardware (such as a display, keyboard, etc.).

[0054] In one implementation, the graphics subsystem driver 312 is a kernel-mode device driver that provides kernel-mode support for the unified graphics subsystem 306. The graphics subsystem driver 312 is part of the lower-level graphics pipeline and serves as an interface between the unified graphics subsystem 306 and the device hardware 320. For example, the graphics subsystem driver 312 can control window display, manage screen output, collect input from peripheral accessories (such as a keyboard and mouse), and pass the collected input to user-mode applications.

[0055] It is worth noting that the graphics subsystem driver 312 can utilize an API set for communicating with the hardware abstraction layer 318 and the device hardware 320 that is different from the API set used in the user mode 322. To this end, some implementations of the technology can provide a mechanism for loading multiple kernel mode API set modes in the kernel mode memory space and selectively switching between kernel mode API set modes to provide kernel mode extensions for processing actions initiated at the application layer in the user mode 322. For example, an indirect table (not shown) can be utilized at application runtime to dynamically select any one of the kernel mode API set modes that corresponds to the user mode API set mode that has been selected by the runtime context evaluator 302.

[0056] In addition, the operating system 308 also includes a unified service table 310 that acts as a translation layer between user mode APIs (such as APIs used by the unified graphics subsystem 306) and APIs used within the kernel mode 324. The unified service table 310 enables the shared operating system kernel 314 to serve multiple environments (e.g., the same type of subsystem) and their associated API collection modes by exposing a union of kernel mode services called by a union of API collection contracts to host mappings across all supported API collection modes.

[0057] For example, in Figure 3 In the example, GraphicsBinary1 can call kernel mode service S1, and GraphicsBinary2 can call kernel mode service S2. Since kernel mode is shared by the same type of subsystems, unified service table 310 includes both S1 and S2. GraphicsBinary1 or GraphicsBinary2 (eg, two graphics subsystems of the same type).

[0058] Since the kernel mode 324 and the unified service table 310 are shared by all subsystems within the unified graphics subsystem 306, any application can call all services in the unified service table 310 regardless of the selected API set mode. This can create a potential security vulnerability because a malicious application can manually call services that are not normally accessible through the application's associated API set mode. For example, an application assigned to APIsetschema_1.dll by the runtime context evaluator 302 can directly call service S2, which is normally only accessible through an application assigned to APIsetschema_2.dll.

[0059] In one implementation, the operating system 308 mitigates this potential security vulnerability by re-executing the logic of the runtime context evaluator 302 each time the unified service table 310 is accessed. For example, the runtime context evaluator 302 can evaluate one or more of the runtime factors 328 during an application startup sequence to determine that the startup application is assigned to APIsetschema_1.dll. When the application subsequently places a call to the unified service table 310 for service S1, the runtime context evaluator 302 can again check (multiple) runtime factors 328 (e.g., session ID, application ID) in real time to confirm which API set mode is selected and verify whether the selected API set mode supports the requested service S1. For example, this real-time check can prevent an application assigned to use APIsetschema_1.dll from calling service S2, which is designed to be assigned to an application using a different API set mode.

[0060] Figure 4 Example operations 400 for parallel execution of subsystems of the same type executing on a shared base operating system are shown. Loading operation 405 loads multiple API collection patterns into volatile memory of a device during a boot sequence. Each of the API collection patterns resolves one or more API collection contracts into associated binaries that host implementations of the contracts. Each API collection contract included in the API collection contract declares a set of associated API functions exported by the contract.

[0061] A receiving operation 410 receives a request to parse a selected API set contract from an API set contract into an associated host binary. An evaluation operation 415 evaluates runtime parameters associated with the request to determine a call context identifier. A selection operation 420 uses the determined call context identifier to select one of a plurality of API set patterns for parsing the API set contract into an associated host binary. For example, the call context identifier may identify an application in which the API set contract parsing request is placed or a session ID for a container in which the requesting application is executing. A parsing operation 425 parses the API set contract into a selected host binary according to a mapping defined by the selected API set pattern, and an execution operation 430 executes elements of the selected host binary in response to receiving an API call from an application.

[0062] Figure 5An example schematic diagram of a processing device 500 suitable for implementing various aspects of the disclosed technology is shown. The processing device 500 includes one or more processor units 502, memory 504, a display 506, and other interfaces 508 (e.g., buttons). The memory 504 typically includes volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 510 (such as an operating system such as a processor) and a processor 502 may be used to perform operations such as performing a program execution, such as performing a program execution, or performing a program execution. operating system, Mobile operating system or a specific operating system designed specifically for gaming devices) resides in memory 504 and is executed by processor unit(s) 502, although it should be understood that other operating systems may be employed.

[0063] One or more applications 512 are loaded into memory 504 and executed by processor unit(s) 502 on operating system 510. Applications 512 may receive input from various input local devices such as microphone 534, input accessories 535 (e.g., keyboard, mouse, stylus, touch pad, game pad, racing wheel, joystick). In addition, applications 512 may communicate with such devices over a wired or wireless network using one or more communication transceivers 530 and antenna 538 to provide network connectivity (e.g., mobile phone network, ) to receive input from one or more remote devices (such as remotely located smart devices). The processing device 500 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., a microphone 534, an audio amplifier and speaker, and / or an audio jack), and a storage device 528. Other configurations may also be used.

[0064] The processing device 500 also includes a power supply 516, which is powered by one or more batteries or other power sources and provides power to other components of the processing device 500. The power supply 516 can also be connected to an external power source (not shown) that replaces or charges the internal battery or other power source. In an example implementation, the task scheduling recommendation tool can include hardware and / or software embodied by instructions stored in the memory 504 and / or storage device 528 and processed by the processor unit(s) 502. The memory 504 can be the memory of a host device or an accessory coupled to the host.

[0065] The processing device 500 may include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage may be embodied by any available media that the processing device 500 can access, and includes volatile and non-volatile storage media, removable and non-removable storage media. Tangible computer-readable storage media do not include intangible and transient communication signals, and include volatile and non-volatile, removable and non-removable storage media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Tangible computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CDROM, digital versatile disk (DVD) or other optical disk storage, magnetic tape, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium that can be used to store the desired information and can be accessed by the processing device 500. 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 residing in a modulated data signal such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. 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.

[0066] Some implementations may include a product. The product may include a tangible storage medium (memory device) for storing logic. Examples of storage media 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, writable or rewritable memory, etc. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, applications, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, processes, software interfaces, application programming interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, a product may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and / or operations according to the described implementation. 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, etc. Executable computer program instructions can be implemented according to a predefined computer language, manner or syntax to instruct the computer to perform a specific operation segment. The instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0067] An example method disclosed herein includes: loading a first application programming interface (API) set pattern into a memory, the first API set pattern resolving the API set contract into a first host binary; loading a second API set pattern into a memory, the second API set pattern resolving the API set contract into a different second host binary; executing an element of the first host binary in response to receiving an API call received within a first runtime context, the API call being identified by the API set contract; and executing an element of the different second host binary in response to receiving an API call within a second runtime context.

[0068] Another example method according to any of the foregoing methods also includes: receiving a request to parse an API collection contract into an associated host binary file, the API collection contract defining a set of APIs called by an application; evaluating a runtime context of the request to determine a call context identifier associated with the request; and selecting one of a first API collection mode and a second API collection mode to parse the request based on the call context identifier.

[0069] In yet another example method of any of the foregoing methods, the call context identifier comprises a session identifier for a container in which the application is loaded.

[0070] In yet another example method of any of the foregoing methods, the call context identifier includes an application identifier for an application that initiated the request to resolve the API collection contract into an associated host binary file.

[0071] In yet another example method of any of the foregoing methods, the first host binary and the different second host binary are executables of the same type of subsystem sharing a base operating system in the computing device.

[0072] In yet another example method of any of the foregoing methods, the first host binary and the different second host binary are graphics subsystems.

[0073] In yet another example method of any of the foregoing methods, the base operating system includes a unified service table for interfacing between kernel-side elements in the graphics pipeline and each subsystem of the same type.

[0074] An example system disclosed herein includes a memory storing a first application programming interface (API) set schema and a second API set schema, the first API set schema resolving the API set contract to a first host binary, the second API set schema resolving the API set contract to a second different host binary. The system also includes an operating system that uses the first API set schema to resolve API calls placed within a first runtime context and uses the second API set schema to resolve API calls placed within a second runtime context, the API calls being identified by the API set contract.

[0075] In another example system of any of the foregoing systems, the operating system includes a runtime context evaluator stored in a memory and executable to: receive a request to resolve an API set contract into an associated host binary file; evaluate a runtime context of the request to determine a call context identifier associated with the request; and select one of a first API set mode and a second API set mode to resolve the request based on the call context identifier.

[0076] In yet another example system of any of the foregoing systems, the call context identifier comprises a session identifier for a container in which the associated application initiated the request to resolve the API collection contract into an associated host binary file.

[0077] In yet another example system of any of the previous systems, the call context identifier comprises an application identifier for an application that initiated the request to resolve the API collection contract into an associated host binary file.

[0078] In yet another example system of any of the previous systems, the first host binary and the different second host binary are executables of the same type of subsystem that shares a base operating system in the computing device.

[0079] In yet another example system of any of the previous systems, the first host binary and the different second host binary are graphics subsystems.

[0080] In yet another example system of any of the previous systems, the base operating system includes a unified service table for interfacing between kernel-side elements in the graphics pipeline and each of the same type of subsystems.

[0081] An example memory device disclosed herein is encoded with processor-executable instructions for performing a computer process, the computer process comprising: loading a first application programming interface (API) set pattern into the memory, the first API set pattern resolving the API set contract into a first host binary; loading a second API set pattern into the memory, the second API set pattern resolving the API set contract into a different second host binary; executing an element of the first host binary in response to receipt of an API call placed within a first runtime context, the API call being identified by the API set contract; and executing an element of the different second host binary in response to receipt of an API call placed within a second runtime context.

[0082] On another example memory device of any previous memory device, the computer process also includes: receiving a request to resolve an API set contract into an associated host binary file, the API set contract defining a set of APIs called by an application; evaluating a runtime context of the request to determine a call context identifier associated with the request; and selecting one of a first API set mode and a second API set mode to resolve the request based on the call context identifier.

[0083] In yet another example memory device of any previous memory device, the call context identifier includes a session identifier for a container in which the application is loaded.

[0084] In yet another example memory device of any of the previous memory devices, the call context identifier comprises an application identifier for an application for initiating the request to resolve the API set contract into an associated host binary file.

[0085] In yet another example memory device of any of the preceding memory devices, the first host binary and the different second host binary are executables of a same type of subsystem that shares a base operating system in the computing device.

[0086] In yet another example memory device of any of the preceding memory devices, the first host binary and the different second host binary are graphics subsystems.

[0087] The implementation described herein is implemented as logical steps in one or more computer systems. Logical operations can be implemented as (1) a series of processor-implemented steps executed in one or more computer systems, and (2) interconnected machines or circuit modules in one or more computer systems. Implementation is a matter of choice, depending on the performance requirements of the computer system used. Therefore, the logical operations that constitute the implementation described herein are variously referred to as operations, steps, objects, or modules. In addition, it should be understood that the logical operations can be performed in any order unless otherwise explicitly stated or the claim language inherently requires a specific order. The above description, examples, and data, together with the attached appendix, provide a complete description of the structure and use of the exemplary implementation.

Claims

1. A method for executing subsystems of the same type in parallel, comprising: loading a first application programming interface set schema into a memory, the first application programming interface set schema parsing an application programming interface set contract into a first host binary; loading a second application programming interface set schema into the memory, the second application programming interface set schema parsing the application programming interface set contract into a second different host binary; receiving an application programming interface call, the application programming interface call comprising a request to parse the application programming interface set contract into an associated host binary file, the application programming interface set contract defining a set of application programming interfaces called by an application; evaluating a runtime context of the application programming interface call to determine a call context identifier associated with the request, the call context identifier comprising a session identifier for a container in which the application is loaded; Selecting one of the first application programming interface set mode and the second application programming interface set mode using external information of the application programming interface call, the external information including the call context identifier; In response to selecting the first application programming interface set mode, executing elements of the first host binary instead of elements of the second host binary; as well as In response to selecting the second application programming interface set mode, elements of the different second host binary are executed instead of elements of the first host binary. 2 . The method of claim 1 , wherein the first host binary and the different second host binary are executables of the same type of subsystem sharing a base operating system in a computing device. 3 . The method of claim 1 , wherein the first host binary and the different second host binary are graphics subsystems.

4. The method of claim 2, wherein the base operating system includes a unified service table for interfacing between kernel-side elements in a graphics pipeline and each of the subsystems of the same type.

5. A system for executing subsystems of the same type in parallel, comprising: a memory storing a first application programming interface set mode and a second application programming interface set mode, wherein the first application programming interface set mode parses the application programming interface set contract into a first host binary, and the second application programming interface set mode parses the application programming interface set contract into a second different host binary; and Operating system, adapted to: receiving an application programming interface call, the application programming interface call comprising a request to parse the application programming interface collection contract into an associated host binary file; evaluating a runtime context of the request to determine a call context identifier associated with the request, the call context identifier comprising a session identifier for a container in which an associated application was loaded when the associated application initiated the request to resolve the application programming interface set contract into the associated host binary file; selecting one of the first application programming interface set mode and the second application programming interface set mode using external information of the application programming interface call, the external information of the application programming interface call including the call context identifier; In response to selecting the first application programming interface set mode, parsing the application programming interface call using the first application programming interface set mode; as well as In response to selecting the second application programming interface set mode, the application programming interface call is resolved using the second application programming interface set mode.

6. The system of claim 5, wherein the first host binary and the different second host binary are executables of the same type of subsystem sharing a base operating system in a computing device.

7. The system of claim 6, wherein the base operating system includes a unified service table for interfacing between kernel-side elements in a graphics pipeline and each of the same type of subsystems.

8. The system of claim 5, wherein the first host binary and the different second host binary are graphics subsystems.

9. One or more memory devices encoded with processor-executable instructions for performing a computer process comprising: loading a first application programming interface set schema into a memory, the first application programming interface set schema parsing an application programming interface set contract into a first host binary; loading a second application programming interface set schema into the memory, the second application programming interface set schema parsing the application programming interface set contract into a second different host binary; receiving an application programming interface call, the application programming interface call comprising a request to parse the application programming interface set contract into an associated host binary file, the application programming interface set contract defining a set of application programming interfaces called by an application; evaluating a runtime context of the application programming interface call to determine a call context identifier associated with the request, the call context identifier comprising a session identifier for a container in which the application is loaded; selecting one of the first application programming interface set mode and the second application programming interface set mode using external information of the application programming interface call, the external information of the application programming interface call including the call context identifier; In response to selecting the first application programming interface set mode, executing elements of the first host binary instead of elements of the second host binary; as well as In response to selecting the second application programming interface set mode, elements of the second host binary are executed instead of elements of the first host binary.

10. The one or more memory devices of claim 9, wherein the first host binary and the different second host binary are executables of the same type of subsystem sharing a base operating system in a computing device.

11. The one or more memory devices of claim 9, wherein the first host binary and the different second host binary are graphics subsystems.

Images