Methods, devices, and computer program products for the confluence of multiple operating systems

Abstract

Method for providing multiple operating systems with access to hardware resources within a mobile device with one processor, comprising: Execution of a primary operating system kernel by the processor; Execution of at least one driver within the kernel of the primary operating system by the processor; Providing at least one application associated with the primary operating system with access to at least some of the hardware resources via the driver running within the kernel of the primary operating system; and Providing at least one application associated with a secondary operating system with access to at least some of the hardware resources via the driver running within the kernel of the primary operating system, wherein the provision of the application associated with the secondary operating system with access to at least some of the hardware resources includes: Receiving a request to access at least some of the hardware resources by a service associated with the primary operating system, wherein the request is received by the application associated with the secondary operating system; Submitting the request to access at least some of the hardware resources to the driver; and Providing the application associated with the secondary operating system with access to the requested hardware resources via the driver, wherein providing the application associated with the secondary operating system with access to the requested hardware resources includes: Meeting the requirement to access at least some of the hardware resources; Providing the driver with the fulfilled requirement; Transmitting the fulfilled request to the service associated with the primary operating system; and Transmitting the fulfilled request to the requesting application associated with the secondary operating system.

Description

CROSS-REFERENCE TO RELATED REGISTRATION

[0001] This application claims priority over the preliminary U.S. application No. 61 / 496, 394, filed on June 13, 2011, the entirety of which is incorporated herein by reference. TECHNICAL AREA

[0002] The present disclosure relates generally to computer systems and in particular to the provision of multiple operating systems with access to the hardware of a mobile device. BACKGROUND

[0003] A mobile operating system (OS), also known as a mobile OS, mobile platform, or handheld operating system, is the operating system that controls a mobile device or information device. A mobile OS is fundamentally similar to an operating system like Windows, macOS, or Linux that controls a desktop or laptop computer. However, a mobile operating system is somewhat simpler and focuses more on wireless broadband and local connectivity, mobile multimedia formats, and various input methods compared to a desktop / laptop operating system.

[0004] Typical examples of devices running a mobile operating system include smartphones, personal digital assistants (PDAs), tablet computers and information devices, e.g., smart devices, which may also include embedded systems, or other mobile and wireless devices.

[0005] In today's world, mobile dual operating systems have become more common in devices like laptops, as people want the best of both worlds. Windows became the primary operating system for most of these laptops, along with all Linux-based operating systems. More recently, with the increasing popularity of Android in smartphones, there has been a trend toward using Android as a secondary operating system in notebooks and netbooks. Since Android has the advantage of a mature application market, along with developer support, there is a growing push from the market to run Android alongside Windows. While there are attempts to run multiple operating systems on personal communication devices, such attempts are cumbersome and suffer from poor performance.

[0006] Document US 2011 / 0093836 A1, for example, discloses a device with multiple coexisting and independent environments that interact with a common kernel, as well as associated operating procedures.

[0007] The revelation presented herein was made in consideration of these and other considerations. SUMMARY

[0008] It is understood that this summary is provided to introduce a selection of concepts in a simplified form, the concepts being described in detail below. This summary is neither intended to identify key features or essential characteristics of this disclosure, nor is it intended to limit the scope of the disclosure.

[0009] According to one embodiment, a method provides multiple operating systems with access to hardware resources in a mobile device comprising a processor. The method involves the processor executing a kernel of a primary operating system and a driver within the kernel of the primary operating system. The method further includes providing at least one application associated with the primary operating system that accesses at least some of the hardware resources via the driver running in the kernel of the primary operating system, and providing at least one application associated with a secondary operating system that accesses at least some of the hardware resources via the driver running in the kernel of the primary operating system.Providing the application associated with the secondary operating system with access to at least some of the hardware resources includes receiving a request to access at least some of the hardware resources through a service associated with the primary operating system, with the request being received by the application associated with the secondary operating system. Providing the application associated with the secondary operating system with access to at least some of the hardware resources further includes submitting the request to access at least some of the hardware resources to the driver and providing the application associated with the secondary operating system with access to the requested hardware resources via the driver.Providing the application associated with the secondary operating system with access to the requested hardware resources includes fulfilling the request to access at least some of the hardware resources, providing the fulfilled request to the driver, submitting the fulfilled request to the service associated with the primary operating system, and submitting the fulfilled request to the requesting application associated with the secondary operating system.

[0010] According to another embodiment, a computer system within a mobile device comprises memory configured to store applications, services, a primary operating system, a secondary operating system, and at least one device driver. The computer system further comprises a processor connected to the memory. The processor is configured to execute the applications and services, the primary operating system, the secondary operating system, and the driver.The processor is configured to perform actions including executing the driver within the kernel of the primary operating system, providing at least one application associated with the primary operating system with access to memory and other hardware resources via the driver executed by the kernel of the primary operating system, and providing at least one application associated with the secondary operating system with access to memory and other hardware resources via the driver executed in the kernel of the first operating system.Providing the application associated with the secondary operating system with access to at least some of the hardware resources includes receiving a request to access at least some of the hardware resources through a service associated with the primary operating system, with the request being received by the application associated with the secondary operating system. Providing the application associated with the secondary operating system with access to at least some of the hardware resources further includes submitting the request to access at least some of the hardware resources to the driver and providing the application associated with the secondary operating system with access to the requested hardware resources via the driver.Providing the application associated with the secondary operating system with access to the requested hardware resources includes fulfilling the request to access at least some of the hardware resources, providing the fulfilled request to the driver, submitting the fulfilled request to the service associated with the primary operating system, and submitting the fulfilled request to the requesting application associated with the secondary operating system.

[0011] According to another embodiment, a computer program product in a mobile device comprises a storage medium on which instructions are stored which, when executed by a processor, cause the processor to perform actions. These actions include executing a kernel of a primary operating system, executing a driver within the kernel of the primary operating system, and providing at least one application associated with the primary operating system with access to at least some of the hardware resources via the driver executing within the kernel of the primary operating system. The actions further include providing at least one application associated with the secondary operating system with access to at least some of the hardware resources via the driver executing within the kernel of the primary operating system.Providing the application associated with the secondary operating system with access to at least some of the hardware resources includes receiving a request to access at least some of the hardware resources through a service associated with the primary operating system, with the request being received by the application associated with the secondary operating system. Providing the application associated with the secondary operating system with access to at least some of the hardware resources further includes submitting the request to access at least some of the hardware resources to the driver and providing the application associated with the secondary operating system with access to the requested hardware resources via the driver.Providing the application associated with the secondary operating system with access to the requested hardware resources includes fulfilling the request to access at least some of the hardware resources, providing the fulfilled request to the driver, submitting the fulfilled request to the service associated with the primary operating system, and submitting the fulfilled request to the requesting application associated with the secondary operating system. BRIEF DESCRIPTION OF THE DRAWINGS. Fig. Figure 1 shows a conventional Android architecture for mobile devices; Fig. Figure 2 shows a conventional Windows architecture for mobile devices; Fig. Figure 3 shows an architecture for running multiple operating systems in a mobile device according to an exemplary embodiment; Fig. 4 shows a method for fulfilling a requirement of a main operating system according to an exemplary embodiment; Fig. Figure 5 shows a method for fulfilling a requirement of a secondary operating system according to an exemplary embodiment; Fig. Figure 6 shows a block diagram of a computer system, in which the architecture of Fig. 3. can be implemented according to exemplary embodiments. Detailed description

[0012] Detailed embodiments are disclosed herein. It is understood that the described and illustrated embodiments are merely examples, which can be implemented in various and alternative forms and combinations thereof. As used herein, the word "exemplary" is used expansively to refer to embodiments that serve as examples and illustrations. The figures are not necessarily to scale, and some features may be enlarged or reduced to show details of certain components. Specific structural and functional details disclosed herein are not to be interpreted as limiting.

[0013] Computer operating systems are typically built on a multi-layered approach. One advantage of this layered operating structure is that each code layer only has access to the layer below it. This structure also makes it possible to build an error-free operating system, starting with the lowest layer and adding one layer at a time until the entire system functions correctly. Layering also makes it easier to improve the operating system; an entire layer can be replaced without affecting other parts of the operating system.

[0014] Computer operating systems provide different levels of access to resources at various levels. A protection ring is one of two or more hierarchical levels or layers of privileges within a computer system's architecture. This is generally implemented by some CPU architectures through hardware that provides different CPU modes at the hardware or microcode level. Rings are arranged in a hierarchy from the most privileged (most trusted, usually numbered zero) to the least privileged (least trusted, usually with the highest ring number). In most operating systems, ring 0 is the most privileged level and interacts most directly with the physical hardware, such as the CPU and memory.

[0015] Fig. Figure 1 is a diagram of a conventional Android architecture for mobile devices. The in Fig. The Android architecture shown in Figure 100, which can be included in a mobile device, contains a software stack with an application layer, an application framework layer, a library layer, a runtime layer, and a kernel layer. The application layer, located in Ring 3, can be considered the least privileged layer. The application framework layer, running in Ring 2, has more privileges. The libraries / Android runtime layer, layers 130 and 140, run in Ring 1 and have even more privileges. The kernel, running in Ring 0, has the highest privileges.

[0016] Application layer 110 includes various applications that can be written in Java. These applications include, for example, a calendar, a contact list, an email client, an SMS program, a map, a telephone application, a web browser application, etc.

[0017] The Application Framework 120 is used by developers to access framework application programming interfaces (APLs) and manage basic mobile device functions such as resource allocation, switching between processes or programs, phone applications, and tracking the mobile device's physical location. The application framework includes various managers, such as an activity manager, a window manager, a content provider manager, an observation system manager, a packet manager, a telephony manager, a resource manager, a location manager, and a message manager.

[0018] Library layer 130 comprises libraries written in languages ​​such as C, C++, etc., and used by various systems. These libraries instruct the mobile device on how to process different types of data and are visible to Android developers via the application framework layer 120. Examples of libraries include a UI manager, a media framework library, an SQLite library, an OpenGL / ES library, a free type library, a WebKit library, an SGL library, an SSL library, and a libc library.

[0019] The Android runtime layer 140, which contains a set of core libraries and a Dalvik Virtual Machine (DVM), is also located in library layer 130. Runtime layer 140 contains the set of base libraries required for Java libraries. Each Android application gets its own instance of the Dalvik Virtual Machine. Dalvik is written in such a way that a device can efficiently run multiple virtual machines with minimal memory.

[0020] The Linux kernel layer 150 includes Android memory management programs, security settings, power management software, and various drivers for hardware, file system access, network, and inter-process communication. Kernel 150 also acts as an abstraction layer between the hardware layer 160 and the rest of the software stack.

[0021] Hardware layer 160 includes physical hardware, including, for example, a hard drive for storing data, a processor for running applications, and memory that may include an operating system that controls the scheduling of tasks and access to system resources.

[0022] Fig. Figure 2 shows an example of a traditional Windows architecture for a mobile device. The in Fig. The Windows architecture shown represents a Windows 2000 operating system. However, it should be recognized that other versions of Windows are also relevant. The Windows 200 architecture, which can be included in a mobile device, operates in two modes. These two modes correspond to... Fig. The kernel is divided into two rings: ring 220 for kernel mode and ring 210 for user mode. User mode components reside in ring 3, the least privileged ring. Kernel mode components reside in ring 0, the most privileged ring.

[0023] User mode 210 has four main functions: special system support processes, services (which are server processes), environment subsystems, and user applications. The special support processes include, for example, the logon process and the session manager. The services (which are server processes) include, for example, the event log and scheduling services. The environment subsystems provide an operating system environment by exposing native operating system services to user applications. User mode includes user applications, such as the Win32 applications shown in section 204. User applications can also include various other types of applications, such as Windows 3.1, MS-DOS, POSIX, OS-2 applications, etc. Applications in section 204 can be similar to those described in Fig. The applications shown in Figure 1 include, for example, various user applications such as camera applications, a telephone application, a browser application, etc.

[0024] User mode 210 also includes services, such as Win32 services 202. These services can also include other types of services, e.g., Windows 3.1, MS-DOS, POSIX, OS 2 services, etc. Services 202 can include special types of applications that can be started automatically at system startup, e.g., event logging and scheduling. Services 202 provide application programming interfaces (APIs) that are specific to the Windows operating system.

[0025] In user mode 210, some applications and services form a client-server relationship, where the applications are the clients and the services are the servers. One of the advantages of this type of architecture is that support for other types of applications can be provided simply by adding subsystems. Other applications communicate directly with the execution layer.

[0026] In user mode, software cannot directly access the hardware. Access to the hardware in user mode 210 is provided via kernel mode 220. In kernel mode 220, the software can access hardware and system data as well as all other system resources.

[0027] Kernel-mode layer 220 has the following components: Execution layer 225, Microkernel layer 228, Kernel-mode driver 227, and Windows Hardware Abstraction Layer (HAL) 229. Execution layer 225 contains execution services, execution components 224, and an object manager 226. Execution services 222 provide application programming interfaces (APIs) for accessing execution components 224. Both Win32 applications 201 and Win32 services 202 use execution services 222 to access the I / O manager, process manager, and other execution components.

[0028] The execution components 224 contain components that implement memory management, process and thread management, security, I / O, interprocess communication, and other basic operating system services. In most cases, these components interact with each other in a modular, layered manner.

[0029] As in Fig. As shown in Figure 2, the execution components 224 comprise an I / O system manager, responsible for executing all system I / O requests, and a security reference monitor, responsible for controlling which objects have permissions for which resources. Each object has an Access Control List (ACL) that is queried when the object makes a service request. Access to resources is allowed or denied according to the rights the module has in the ACL.

[0030] The execution components 224 also include a Local Procedure Call (LPC) manager, which uses inter-process communication to transmit messages between processes, and a Virtual Memory Manager (VMM), which manages the virtual address space of each process, shares memory between processes, and protects the virtual memory of each process. All I / O devices, network ports, printers, drives, and so on are represented as virtual files. These virtual files are called file objects and are managed by the object manager 226 like any other object.

[0031] The execution components 224 also include the process manager, which views processes as objects. Its task is to create and terminate processes and threads. It also suspends and resumes the execution of threads and stores and retrieves information about processes and threads.

[0032] The execution components 224 also include a PnP manager, which handles plug-and-play devices and assists with detection and installation during boot, and a power manager, which handles power supply events and notifies affected drivers.

[0033] The execution components 224 also include a window manager and a Graphic Device Interface (GDI) that provide the graphical user interface (GUI). The window manager controls the placement and appearance of windows within a windowing system in a graphical user interface. GDI tasks include drawing lines and curves, rendering fonts, and managing palettes.

[0034] Although not shown, the execution components 224 can also include additional components, such as a cache manager. The cache manager improves the performance of file-based I / O by keeping recently referenced disk data in main memory for faster access. It also defers disk writes by storing updates in memory for a short time before writing them to disk.

[0035] Object Manager 226 handles calls from other execution layer systems, particularly system calls. System calls pass through the object manager to access Windows resources. Object Manager 226 creates, manages, and deletes execution objects. Execution objects are created in the leadership layer 225 and are accessible to execution and protected subsystems. They can be thought of as message packets representing elements such as processes, threads, semaphores, and other low-level objects.

[0036] The Microkernel 228 sits between the execution layer 225 and the Windows HAL 229 and provides multiprocessor synchronization, thread and interrupt feeding, execution and trap handling, and exception handling. During system startup, it extracts information from the registry, such as which device drivers to load and in what order.

[0037] The hardware abstraction layer 229 contains code that is modified by the Windows operating system, which in turn is modified by the hardware on which the operating system runs. This ensures compatibility with multiple processor platforms. The hardware abstraction layer 229 directly manipulates the hardware 230.

[0038] Hardware layer 230 includes physical hardware, including, for example, a hard drive for storing data, a processor for running applications, and memory that may include an operating system, task scheduling, and access to system resources.

[0039] The kernel-mode device drivers 227 enable kernel layer 220 to interact with hardware layer 230. Each driver has well-defined system routines and interval routes that it executes to the rest of the operating system. The kernel-mode drivers 227 send and receive load parameters and configuration data from the registry.

[0040] While the Android and Windows architectures described above are useful for mobile devices for different reasons, there was a push to have multiple operating systems on a single mobile device. Several attempts were made to achieve this.

[0041] One approach is to run an Android operating system as a second operating system on a mobile device that already has a Windows operating system. To use this approach, the user must shut down Windows to boot Android (and vice versa). This restart takes a few minutes, depending on the processor. This restart is inconvenient for the user. Furthermore, this approach requires separate driver development for Android and Windows, resulting in additional development costs (which are ultimately passed on to the consumer).

[0042] Another approach involves using Android with virtualization technology. While virtualization is a common approach, not all processors have built-in virtualization capabilities. This approach also results in reduced processor performance.

[0043] Another approach involves switching between operating systems using S3 technology. This approach has the disadvantage of only allowing one operating system at a time. Furthermore, this approach requires significant memory usage and BIOS modifications. Additionally, it necessitates developing separate drivers for Android and Windows.

[0044] Another approach is Dalvik virtualization. This approach has the disadvantage that applications are not 100% compatible. Furthermore, this approach would require a lot of changes for each new Android release.

[0045] Fig. Figure 3 illustrates an architecture for running multiple operating systems in a mobile device according to an exemplary embodiment. Referring to Fig. Version 3 includes the 300 architecture, which can be included in a mobile device, a Windows architecture similar to that in Fig. 2 with extensions for running an Android operating system. It should be noted that in the Fig. In the diagram shown in Figure 3, various elements of the Windows architecture have been omitted for the sake of simplicity. Although various elements of the Windows architecture are not shown, these elements are considered part of the architecture of the system described in Figure 3. Fig. 3 systems shown were viewed.

[0046] Architecture 300 comprises a software architecture with a user-mode layer (310) and a kernel-mode layer (320). Components in user-mode (310) can be located in ring 3, which is the least privileged. Components in kernel-mode (320) can be located in ring 0, which is the most privileged.

[0047] In user mode, software cannot directly access the hardware. User mode includes Windows applications (310), Android and Windows applications (305), and services such as Win32 services (308), Windows 3.1, MS-DOS, POSIX, OS2 services, etc. Windows applications (307) encompass various applications, such as a camera application, a browser application (e.g., Explorer), a phone application, Notepad, etc. Windows applications (307) can include Win32 applications, Windows 3.1, MS-DOS, POSIX, OS2 applications, etc. Android applications (305) can also include various applications, such as a camera application, a browser application, a phone application, etc.

[0048] Hardware layer 330 comprises physical hardware, such as a hard drive for storing data, a processor for running applications, and memory that can control the operation of a Windows operating system, schedule tasks, and access system resources, along with the code for running other software. Fig. 3.

[0049] Hardware access is provided to user mode 310 via kernel mode 320. In kernel mode 320, software can access hardware and system data, as well as all other system resources.

[0050] The kernel-mode device drivers 324 enable kernel layer 320 to interact with hardware layer 330. A driver 326 is also provided for running the Android kernel. Thus, according to the examples, the Android OS can be run in kernel mode 320, just like Windows drivers.

[0051] In user mode (310, 307), Windows applications can access kernel mode (320) directly via the Windows driver (324) or indirectly via the Win32 services (308), depending on the application. For example, a modem application can access the modem directly via the Windows driver (324), while general Windows applications access the keyboard using the Win32 services (308) to process keyboard input. Access requests from Android applications (305) are relayed to the Windows services (308) via a confluence software bus (322). The Windows services (308) send the request to a Windows driver (324), which provides access to the hardware through a HAL (330) (not shown for simplicity). The requested hardware resources are then relayed to the Android applications (305) via the driver (324), the Windows services (308), and the confluence software bus (326).

[0052] Android application requests, requested by the Android operating system, are sent to the Android kernel, running as Windows driver 326, via the Confluence software bus 322. The Android kernel 326 fulfills the request provided by the Android OS and makes the fulfilled request available to the Android applications 305 via the Confluence software bus 322.

[0053] As an example of how architecture, according to Fig. 3. If a camera application can be used, it can be assumed that it is working. When the camera application is accessed via Windows, the Windows Camera application requests an image from the camera driver (Windows driver 324). The camera driver accesses the actual camera at hardware layer 330 and provides the image to the requesting application. When the camera application is accessed via Android, the Android Camera application requests an image from the camera hardware layer, and the request is forwarded to the camera server services included in Windows services 308 via the software confluence bus 322. A Windows Camera Server service within Windows services 308 includes requests to the Windows Camera driver for an image. The camera driver accesses the actual camera and provides the images to the Windows Camera services.The Windows service sends the camera image to the Android camera application via the confluence software bus 322.

[0054] According to one exemplary embodiment, the architecture 300 can be included in a mobile device such as a mobile phone. However, the architecture can also be included in other devices, for example, a workstation, a telephone, a desktop computer, a laptop, a notebook computer, a server, a handheld computer, a media player, a gaming system, a mobile computing device, or any other type and form of computer, telecommunications, or media device that communicates.

[0055] Fig. 4 and Fig. Figure 5 are flowcharts illustrating methods for providing access to the hardware resources in a mobile device according to an exemplary embodiment. It should be understood that the stages or other interactions of the illustrated method are not necessarily presented in a specific order, and the performance of some or all steps in an alternative sequence is possible and should be considered. The steps are shown in sequence for the convenience of description and illustration. Steps may be added, omitted, and / or performed concurrently without affecting the scope of the attached claims. It is also understood that the method can be terminated at any time.In certain embodiments, some or all steps of the method and / or substantially equivalent steps can be performed by executing computer-executable instructions or contained on a non-transitory, computer-readable medium.

[0056] Fig. Figure 4 shows a method for handling a request to access the hardware from an application with a primary operating system, for example, a Windows operating system. Referring to Fig. Step 4: A request will be received from an application and assigned to a primary operating system, such as a Windows application (307) at step 410. At step 420, the request is communicated to a driver running within the kernel of the primary operating system, such as driver 324. Although not shown, it should be understood that the request can instead be communicated to a service, such as services (308), and then passed to driver 324, depending on the type of application. At step 430, the hardware drivers will be accessed to fulfill the request. At step 440, the request is fulfilled and provided to the driver. At step 450, the fulfilled request is passed to the requesting application.

[0057] Fig. Figure 5 shows a method for handling a request for hardware access from an application with a secondary operating system, e.g., an Android operating system. Referring to Fig. Step 510 is a request received from an application associated with a secondary operating system, such as an Android application (305). In step 520, the request is communicated to a service associated with the primary operating system, such as service 308. In step 530, the request is communicated to a driver running in the kernel of the primary operating system, such as driver 324. In step 540, the hardware drivers are accessed to fulfill the request. In step 550, the fulfilled request is provided to the drivers associated with the primary operating system. In step 560, the fulfilled request is communicated to the requesting service associated with the primary operating system. In step 570, the fulfilled request is communicated to the requesting service associated with the secondary operating system.

[0058] Fig. Figure 6 is a block diagram of a computing device 600, in which the software architecture according to the figure can be implemented. The computing device 600 can be contained in a mobile device. Referring to Fig. The computing unit 600 contains a processor 610, inputs (e.g., user requests) which are received and transmitted via I / O data ports 620, and outputs (e.g., for responding to user requests). The I / O data ports 620 can be implemented with, for example, an interface that includes an antenna or other suitable type of transceiver, through which data and signals are transmitted and received wired and / or wirelessly.

[0059] The computing device 600 also includes a physical hard disk 680. The processor 610 communicates with the memory 630 and the hard disk drive 680 via, for example, an address and a data bus (not shown). The processor 610 can be any commercially available or custom-designed microprocessor. The memory 630 represents the entire hierarchy of storage devices that the software and data use to implement the functionality of the device 600. The memory 630 may include, but is not limited to, the following types of devices: processor registers, processor cache, RAM, ROM, PROM, EPROM, EEPROM, flash memory, SRAM, DRAM, and other volatile memory types, as well as non-volatile, semi-permanent, or permanent memory types, such as tape-based media, optical media, semiconductor media, hard disks, combinations thereof, and the like.

[0060] As in Fig. As shown in Figure 6, the memory 630 can contain various categories of software and data in the device 600, including applications 640, a database 650, an operating system (OS) 660, and input / output (IO) device drivers 670. The memory 630 can also house devices that can consider a specific category of applications 640. As a person skilled in the art will recognize, the operating system 660 can include code for any operating system for use with a data processing system, for example, a Windows operating system, Android OS, etc.

[0061] The I / O device drivers 670 can be accessed via various routines by at least one of the OS 660 through applications 640 and services 650 to communicate with devices and include certain memory components. According to an exemplary embodiment, one of the operating systems, e.g., the Windows operating system, runs in kernel mode, while another operating system, e.g., the Android operating system, runs as a driver in the kernel of the other operating system.

[0062] The applications 640 can be stored in memory 630 and / or in firmware (not shown) as executable instructions and can be executed by the processor 610. The applications comprise 640 different programs that implement the various functions of the device 600. The database 650 is used for the static and dynamic data stored in memory by the applications 640, the operating system 660, the I / O device driver 670, and other software programs.

[0063] While the memory 630 is shown positioned close to the processor 610, it is understood that at least part of the memory 630 can be a remote access storage system, for example, a server in a communication network, a remote hard disk drive, a removable storage medium, combinations thereof, and the like. Thus, any of the data, applications, and / or software described above can be stored in the memory 630 and accessed via the network or connections to other data processing systems (not shown), which may include a local area network (LAN), a man-centered network (MAN), or a wide area network (WAN).

[0064] It should be understood that Fig.Section 6 and the above description are intended to be a brief, general description of a suitable environment in which the various aspects of some embodiments of the present disclosure can be implemented. While the description refers to computer-readable instructions, the present invention can also be implemented in combination with other program modules and / or as a combination of hardware and software, additionally or instead of computer-readable instructions. The term "application," or variants thereof, is used here in an expansive manner to include routines, program modules, programs, components, data structures, algorithms, and the like.Applications can be implemented on various system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronics, combinations thereof, and the like.

[0065] The law does not require, and it is economically unreasonable, to illustrate and teach all possible embodiments of the present claims. Therefore, the embodiments described above are presented merely as exemplary illustrations of implementations for a clear understanding of the principles of the invention. Variations, modifications, and combinations of the embodiments described above are possible without deviating from the scope of the claims. All such variations, modifications, and combinations are included herein by the scope of this disclosure and the following claims.

Claims

[1] Method for providing multiple operating systems with access to hardware resources within a mobile device with one processor, comprising: Execution of a primary operating system kernel by the processor; Execution of at least one driver within the kernel of the primary operating system by the processor; Providing at least one application associated with the primary operating system with access to at least some of the hardware resources via the driver running within the kernel of the primary operating system; and Providing at least one application associated with a secondary operating system with access to at least some of the hardware resources via the driver running within the kernel of the primary operating system, wherein the provision of the application associated with the secondary operating system with access to at least some of the hardware resources includes: Receiving a request to access at least some of the hardware resources by a service associated with the primary operating system, wherein the request is received by the application associated with the secondary operating system; Submitting the request to access at least some of the hardware resources to the driver; and Providing the application associated with the secondary operating system with access to the requested hardware resources via the driver, wherein providing the application associated with the secondary operating system with access to the requested hardware resources includes: Meeting the requirement to access at least some of the hardware resources; Providing the driver with the fulfilled requirement; Transmitting the fulfilled request to the service associated with the primary operating system; and Transmitting the fulfilled request to the requesting application associated with the secondary operating system. [2] The method of claim 1, further comprising executing a kernel of the secondary operating system as a driver within the kernel of the primary operating system. [3] Method according to claim 1, wherein the provision of the application associated with the primary operating system comprises accessing at least some of the hardware resources: Receiving a request from the driver to access at least some of the hardware resources from the application associated with the primary operating system; and Providing access to the requested hardware resources via the driver. [4] Method according to claim 1, wherein the request is transmitted from the application associated with the secondary operating system to the service associated with the primary operating system via a software bus. [5] Method according to claim 1, wherein the primary operating system is a Windows-based operating system and the secondary operating system is an Android operating system. [6] Computer system within a mobile device, comprising: a storage device for storing applications, services, a primary operating system, a secondary operating system, and a variety of drivers; a processor that is coupled with the memory and is trained, to run applications and services and to run the primary operating system, the secondary operating system and the driver, with the processor performing actions, including: Executing a driver within a kernel of the primary operating system; Providing at least one application associated with the primary operating system with access to memory and other hardware resources via the driver running within the kernel of the primary operating system; and Providing at least one application associated with the secondary operating system with access to memory and other hardware resources via the driver running within the kernel of the primary operating system, wherein the provision of the application associated with the secondary operating system includes access to at least some of the hardware resources: Receiving a request to access at least some of the hardware resources by a service associated with the primary operating system, wherein the request is received by the application associated with the secondary operating system; Submitting the request to access at least some of the hardware resources to the driver; and Providing the application associated with the secondary operating system with access to the requested hardware resources via the driver, wherein providing the application associated with the secondary operating system with access to the requested hardware resources includes: Fulfilling the requirement to access at least some of the hardware resources; Providing the driver with the fulfilled requirement; Transmitting the fulfilled request to the service associated with the primary operating system; and Transmitting the fulfilled request to the requesting application associated with the secondary operating system. [7] Computer system according to claim 6, wherein the actions performed by the processor further comprise: Running a secondary operating system kernel as a driver within the primary operating system kernel. [8] Computer system according to claim 6, wherein the provision of the application associated with the primary operating system comprises access to at least some of the hardware resources: Receiving a request from the driver to access at least some of the hardware resources from the application associated with the primary operating system; and Providing access to the requested hardware resources via the driver. [9] Computer system according to claim 6, wherein the request is transmitted from the application associated with the secondary operating system to the service associated with the primary operating system via a software bus. [10] Computer system according to claim 6, wherein the primary operating system is a Windows-based operating system and the secondary operating system is an Android operating system. [11] Computer program product within a mobile device comprising a storage medium on which instructions are stored which, when executed by a processor, cause the processor to perform actions, comprising: Running a kernel of a primary operating system; Executing a driver within the kernel of the primary operating system; Providing at least one application associated with the primary operating system with access to at least some of the hardware resources via the primary operating system's kernel running in the driver; and Providing at least one application associated with the secondary operating system with access to at least some of the hardware resources via the kernel of the primary operating system running in the driver, wherein the provision of the application associated with the secondary operating system with access to at least some of the hardware resources includes: Receiving a request to access at least some of the hardware resources by a service associated with the primary operating system, wherein the request is received by the application associated with the secondary operating system; Submitting the request to access at least some of the hardware resources to the driver; and Providing the application associated with the secondary operating system with access to the requested hardware resources via the driver, wherein providing the application associated with the secondary operating system with access to the requested hardware resources includes: Meeting the requirement to access at least some of the hardware resources; Providing the driver with the fulfilled requirement; Transmitting the fulfilled request to the service associated with the primary operating system; and Transmitting the fulfilled request to the requesting application associated with the secondary operating system. [12] Computer program product according to claim 11, wherein the instructions further cause the processor to perform: Running a kernel in the secondary operating system as a driver within the kernel of the primary operating system. [13] Computer program product according to claim 11, wherein the provision of the application associated with the primary operating system comprises access to at least some of the hardware resources: Receiving a request by the driver to access at least some of the hardware resources from the application associated with the primary operating system; and Providing access to the requested hardware resources via the driver. [14] Computer program product according to claim 13, wherein the request from the application associated with the secondary operating system is transmitted to the service of the primary operating system via a software bus.

Images