as United States
`a2) Patent Application Publication co) Pub. No.: US 2002/0052727 Al
`Bondetal.
`(43) Pub. Date:
`May2, 2002
`
`US 20020052727A1L
`
`(54) KERNEL EMULATOR FOR NON-NATIVE
`PROGRAM MODULES
`
`(76)
`
`Inventors: Barry Bond, Maple Valley, WA (US);
`ATM Shafiqul Khalid, Bellevue, WA
`(US)
`eeares,
`421 W RIVERSIDE AVENUESUITE 500
`SPOKANE, WA 99201
`°
`
`(21) Appl. No.:
`
`09/847,535
`
`(22)
`
`Filed:
`
`May1, 2001
`
`Related U.S. Application Data
`
`(63) Non-provisional of provisional
`60/244,410, filed on Oct. 30, 2000.
`
`application No.
`
`Publication Classification
`
`Tint, C07 oe eeceeseeeecceeseneeeteennnnnnseess GO06F 9/455
`(SD)
`(52) US. Ce ieeeceeceseeesesnnseeesnneeesunnceenneecenenecseaee 703/26
`
`ABSTRACT
`(57)
`Described herein is a technologyfacilitating the operation of
`non-native program modules within a native computing
`platform. This invention further generally relates to a tech-
`nology facilitating the interoperability of native and non-
`native program modules within a native computing plat-
`form. More specifically,
`this
`technology involves
`an
`emulation of the kernel of the non-native operating system.
`Instead of interacting with the native kernel of the native
`computing platform, the non-native program modules inter-
`act with a non-native kernel emulator. This abstractitself is
`not intended to limit the scope of this patent. The scope of
`the present invention is pointed out in the appending claims.
`
`
`112d ~
`1120 ~
`
`
`
`Application |
`
`Application
`
` 1426 —
`
`
`
`
`1i4|||I|i\
`
`\
`'
`
`{\\\I\||'{
`
`|
`
`1 |
`
`|
`\
`1
`{|
`|
`|
`
`1 :
`
`| i
`
`1
`
`User
`Mode
`
`Kernel
`Mode
`
`Application APIs
`
`
`
`132
`
`Kernel APIs
`134
`
`14
`
`13
`
`139
`138
`i
`Other Kernel
`Memory
`130
`Functions
`Management
`
`
`Device Drivers
`
`Hardware Interfaces
`
`144
`
`
`
`
`
`142 \
`
`Hardware
`
`150
`) dv
`l
`
`Hardware such as the processor, memory,I/O,ete.
`
`|
`
`i
`i
`|
`1
`1
`|
`t
`
`Google Exhibit 1017
`Google v. VirtaMove
`
`Google Exhibit 1017
`Google v. VirtaMove
`
`

`

`Patent Application Publication May 2,2002 Sheet 1 of 6
`
`Device Drivers
`
`142
`
`HardwareInterfaces
`144
`
`||\|| I
`
`{{|||
`
`User
`Mode
`
`Kernel
`
`Mode
`
`Hardware
`
`US 2002/0052727 Al
`
`
`
`
`||
`
`||
`
`Hardware suchas the processor, memory,I/O, etc.
`
`|
`
`|{
`
`

`

`Patent Application Publication May 2,2002 Sheet 2 of 6
`
`US 2002/0052727 Al
`
`10=2) ee ee eee
`112a
`210
`
`Native Apps
`
`Apps
`
`112b
`
`eee oe ee —_— ee
`
`rococo tfnenrer rr
`
`Non-Native Hardware Emulation
`
` Native Apps
`
`
`
`
`| ||||\{!\|
`
`||1||{|{|l\
`
`||
`
`|\
`|
`
`User
`Mode
`
`Kernel
`Mode
`
`Hardware
`
`

`

`Patent Application Publication May 2,2002 Sheet 3 of 6
`
`US 2002/0052727 Al
`
`ser
`
`,
`Mode
`
`Kernel
`Mode
`
`_ :
`
`Native
`
`tive APIs
`
`(—
`Non-Native
`AP!
`
`
`Non-Native Kernel
`Emulator
`
`Non-Native
`
`/312b >
`
`.
`
`.
`Non-Native
`
`
`
`Apps
`
`312¢ ~
`~$t4b
`
`
`NativeApps |
`mt
`Apps
`
`
`| - yl
`
`s 322
`320
`on
`ive
`
`
`
`
`
`
`
`Hardware
`Device
`Interfaces
`Drivers
`
`
`
`
`
`Hardware |
`
`Hardware
`
`350
`Un---- +o --e een no en eneene en n nn 2nn nnnn e nnnn enn e enn nn enn enne ne nnn 2ne nn nee ennnen nn nee eee!
`
`

`

`Patent Application Publication May 2,2002 Sheet 4 of 6
`
`US 2002/0052727 Al
`
`Non-Native APIs
`
`10
`
`Emulator of Non-Native Kernel APIs
`(i.e., Non-Native CPU Simulator)
`
`
`Translator
`
`
`
`
`Non-Native to
`Native CPU
`Instruction Set
`
`414
`
`
`
`
`
`
`
`Non-Native to
`
`
`Native Word-Size
`Converter
`
`
`
`
`
`
`
`
`
`Memory Constrainer
`
`Shared Memory
`Facilitator
`
`
`
`1/0 UntSB.
`
`Native
`Kernel
`
`Non-Native Kernel Emulator
`
`
`
`Memory
`
`

`

`Patent Application Publication May 2,2002 Sheet 5 of 6
`
`US 2002/0052727 Al
`
`510 —
`
`™~
`
`514
`
`
`Laad an application
`
`
`
`
`Proceed as normal
`512
`Is app non-
`native?
`for native app
`
`
`Non-
`
`Native
`
`
`Determine the target platform and
`select CPU simulator for that platform
`
`
`
`
`
`
`519 —| Ask CPU simulator to start executing instructions in
`host program
`
`
`soent)
`
`Fig. 5A
`
`
`¥
`-
`
`[
`Ascalls are received, translate non-native kernelcalls into
`native kernel calls
`
`550 -
`
`
`
`952 ~
`
`-
`
`¥
`
`.
`
`-
`
`Synchronizenative and targetTEBs and PEBs
`
`|
`
`Fig. 5B
`
`

`

`Patent Application Publication
`
`May 2, 2002 Sheet 6 of 6
`
`US 2002/0052727 Al
`
`Computing
`Device
`
`
`
`
`
`Application
`Programs
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`926 —
`Data Media
`Interfaces
`
`
`anon
`iF
`Video Adapter
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Ko
`
`
`S38pili
`
`seo
`Network
`Adapter
`
`System
`B
`wens
`
`|
`
`‘
`
`Operating
`System 926
`
`Application
`
`Programs 928
`
`'Other Program
`Medules 930
`
`Program
`Data
`
`932
`
`904 —..
`
`Processing
`Unit
`
`v7 940
`
`
`t
`
`System ~_-
`Application 99g
`Programs
`Program 930
`Modules
`Program 932
`
`
`
`c|
`
`
`
`
`gouoo||
`
`Printer
`
`Mouse \
`946
`
`Keyboard
`\— 936
`
`
`
`\
`
`Other Device(s)
`
`

`

`US 2002/0052727 Al
`
`May2, 2002
`
`KERNEL EMULATOR FOR NON-NATIVE
`PROGRAM MODULES
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`{0001] This application claims priority from U.S. Provi-
`sional Patent Application Serial No. 60/244,410,titled “Ker-
`nel Emulator for Non-Native Program Modules” filed on
`Oct. 30, 2000.
`
`TECHNICAL FIELD
`
`[0002] This invention generally relates to a technology
`facilitating the operation of non-native program modules
`within a native computing platform. This invention further
`generally relates to a technology facilitating the interoper-
`ability of native and non-native program modules within a
`native computing platform.
`
`BACKGROUND
`
`[0003] Applications designed to run on a specific comput-
`ing platform do not operate on a different computing plat-
`form. Generally, software is inextricably linked to the com-
`puting platform on whichit is designed to operate. Software
`written and compiled to operate within minicomputer run-
`ning a specific implementation of the Unix operating system
`will not function within a hand-held computer using a
`proprietary operating system.
`
`[0004] A computing platform typically includes an oper-
`ating system (OS) and computing hardware architecture.
`Examples of OSs include these Microsoft® operating sys-
`tems: MS-DOS®, Windows® 2000, Windows NT® 4.0,
`Windows® ME, Windows® 98,
`and Windows® 95.
`Examples of computing hardware architecture include those
`associated with these Intel® microprocessors: 80286, Pen-
`tium®, Pentium® II, Pentium® III, and Itanium™.
`
`[0005] Examples of computing platforms includes 16-bit
`platforms (such as Microsoft® MS-DOS® and Intel®
`80286), 32-bit platforms (such as Microsoft® Windows®
`NT®andIntel® Pentium® Il), and 64-bit platforms (such as
`Intel® Itanium™and an appropriate 64-bit OS). A comput-
`ing platform may also be called a platform, computing
`environment, or environment.
`
`[0006] Specific versions of applications are designed to
`operate undera specific platform. These applications may be
`called “native” when they execute under their specific
`platform. For example, Microsoft® Office 2000 is an appli-
`cation designed to operate on 32-bit platform.
`In other
`words, Microsoft® Office s 2000 is a native application
`relative to its 32-bit platform. However, these 32-bit appli-
`cations maybe called “non-native” when they execute under
`a different platform, such as a 64-bit platform.
`
`[0007] An example of a program-module target platform
`(or simply “target platform”) is the platform an executable
`program (e.g., program module, application, program) was
`targeted to run. For a program module,its target platform is
`also its native platform. For example,
`if one builds a
`Microsoft® Office® application to run under Windows®
`2000 32-bit X86 OS environment then for that image target
`platform would be 32-bit x86.
`
`term “program module” includes other executable software
`that may not be labeled an application.
`
`[0009] Typical Computer Architecture
`
`[0010] Typical computer architecture is multi-layered.
`From the bottom up,
`it includes the hardware layer, the
`operating system (OS) layer, and the application layer.
`Alternatively, these layers may be described as the hardware
`layer, the kernel mode layer, and the user mode layer.
`
`{0011] FIG. 1 illustrates the layers of typical computer
`architecture 100. ‘The top of the architecture is the user mode
`110. It includes applications, such as applications 112a-e.
`These applications communicate with a set of APIs 120.
`Typically, this API set is considered part of the OS, and thus,
`part of the computing platform.
`
`[0012] The next layer of the architecture is the kernel
`mode 130. This may be generally called the “kernel” of the
`OS. Since it is part of the OS,it is part of the computing
`platform.
`
`{0013] A kernel of an OSis the privileged part of the
`OS—the mosttrusted part of the OS. It is an inner layer of
`code. It typically operates I/O 132, security 134, display
`control (i.e., access to the screen) 136, memory management
`138, and other privileged functions 139. The kernel has sole
`access to the hardware in the hardware layer 150 via device
`drivers 142 and other hardware interfaces 144.
`
`[0014] Kernel APIs 140 are those APIs within the kernel
`that arbitrate access to the kernel functions. The applications
`typically do not call the kernel directly. Instead, the appli-
`cations call the APIs 120 and the APIs, in turn, may call the
`kernel (in particular the kernel APIs 140).
`
`[0015] Although FIG. 1 does not show the components
`132-144 of the kernel 130 with connections between them,
`these components are connected as is necessary. The cou-
`pling lines are omitted from the drawing for the sake of
`simplicity and clarity.
`
`[0016] Below the kernel mode 139,there is the hardware
`layer 150. This layer includes all of the hardware of the
`actual computer. This includes the processor(s), memory,
`disk I/O, other I/O, etc. The platform also includes the
`hardware layer.
`
`(0017] Therefore, a computing platform includes the hard-
`ware layer, the kernel layer, and typically the user-mode
`APIs 120.
`
`[0018]
`
`Interoperability and Compatibility
`
`[0019] Application compatibility has been big concern
`since computing platforms started evolving. People want to
`run desired applications in their chosen platform in the ideal
`world. However, in the real world,it’s very difficult to run
`an application in a different host platform that it wasn’t
`written for. For example, 32-bit x86 application cannot run
`on 64-bit Merced (IA64) environment. The problem
`becomes worse when people buy a more powerful machine
`with a different platform than they used to for a long time.
`Immediatelyall the applicationsin the old platform becomes
`useless unless they find some way to use that in the new
`environment.
`
`[0008] An application program is the primary example of
`a “program module”asthe term is used herein. However,the
`
`[0020] Each platform hasits corresponding bady of native
`applications that are designed to run under it. When a ncw
`
`

`

`US 2002/0052727 Al
`
`May2, 2002
`
`generation of platform is released, software developers
`generally upgrade their products to run under the new
`generation platform. Software developers do this for many
`reasons, including marketing, technology, and economics.
`
`[0021] For similar reasons, OS developers wish to make
`their products backwards compatible.
`In this way, older
`generations of applications may run on the latest generation
`of the OS (and thus the latest generation of platform). In
`other words, if non-native applications can run under a
`native platform (including the new OS), this encourages
`users to purchase the new OS because they are not forced to
`discard their current applications and purchase new ver-
`sions. This also gives software developers time to develop
`upgrades to their applications.
`
`[0022] Herein, an example of compatibility is a non-native
`program module functioning appropriately and peacefully
`co-existing with native program modules within a native
`computing environment(e.g., an OS).
`
`[0023] As used herein, an example of interoperability is
`the ability of both native and non-native program modules to
`share resources (such as access data within each other’s
`memory space or a shared memory space) and/or work
`together and cooperatively.
`
`[0024] For the sake of clarity and simplicity, an example
`is used herein to illustrate the problem of incompatibility of
`non-native applications and non-interoperability between
`native and non-native applications. The non-native program
`modules are called 32-bit applications because they are
`designed to operate on a 32-bit platform. The native appli-
`cations are called 64-bit applications because they are
`designed to operate on the native platform, which is 64-bit.
`This is provided as one example and not for limitation.
`Those of ordinary skill in the art understand and appreciate
`that there exists other combinations of native and non-native
`
`applications and native platforms.
`
`{0025] Running Non-Nalive Applications on a Native
`Platform
`
`[0026] Consider this: Running non-native applications on
`a native platform. More specifically, consider this example:
`Running 32-bit applications
`in a 64-bit environment.
`Assume, for this example, that the 64-bit platform is an
`upgrade to an existing popular 32-bit platform (on whichthe
`32-bit applications are designed to run).
`
`[0027] One advantage of a 64-bit platform over a 32-bit
`plattorm is that
`the much larger memory space can be
`addressed. 32-bit processors in a 32-bit platform can address
`about 2GB of memory, but a 64-bit processors in a 64-bit
`platform can address terabytes of memory.
`
`[0028] One of the problems with going from 32-bit plat-
`form to 64-bit platform is that the application programming
`interfaces (APIs) grow from 32-bit to 64-bit. Therefore, the
`new APIs deal with larger memory pointers, larger memory
`addressable space, etc. Thus, the 64-bit APIs are incompat-
`ible with calls from 32-bit applications. Thus, software
`developers need to recompile their applications to 64-bit and
`release a new version for the 64-bit platform. For manylarge
`end applications (particularly on servers), porting to 64-bit
`is the most appropriate alternative to take advantage of the
`new capabilities of a 64-bit OS. But for most applications,
`it is not best to port the application for numerous reasons,
`
`suchasthe sales projections for the 64-bit platform may not
`enough to justify the expense of porting, the application is
`very difficult to port, etc.
`
`[0029] However, it is desirable to have the 32-bit appli-
`cations operate and function correctly on a 64-bit platform.
`In other words, it is desirable to have a non-native (e.g.,
`32-bit) application min properly in a native (e.g., 64-bit)
`environment.
`
`[0030] The capability of running 32-bit applications on the
`64-bit platform is highly desirable for easing the transition
`from the popular 32-bit platform to the new 64-bit platform.
`Not only may this ease the transition,
`it may reduce the
`burden on software developers to immediately port their
`software to the 64-bit platform.It also gives the new 64-bit
`platform an existing library of software (e.g., the old 32-bit
`applications). Furthermore, it is desirable to have 32-bit and
`64-bit applications interoperate.
`
`[0031] Virtual Machine (VM)
`
`In similar situations in the past, the solution has
`[0032]
`nearly always been to emulate the hardware on which the
`non-native applications would run. In other words,
`the
`native platform emulates the non-native hardware environ-
`ment (such as a 32-bit processor) in which the non-native
`applications (such as 32-bit applications) run. Furthermore,
`the non-native OS (such as a 32-bit OS) run in the non-
`native hardware environmentbecause the non-native appli-
`cations need the non-native OS. This non-native hardware
`
`emulation is often called a “virtual machine” (VM) and the
`combination of the VM andthe non-native OS is sometimes
`called the “box” or non-native OS “box”(e.g., a MS-DOS®
`box).
`
`FIG.2 illustrates the same multi-layered architec-
`[0033]
`ture of FIG. 1 except it includes a virtual machine 200. The
`VM emulates the non-native hardware layer 250 in software.
`To run non-native applications (such as 212a@ and 212b)
`within a VM, a non-native OS runs on top of the emulated
`non-native hardware layer 250. This non-native OS includes
`a user mode 210 and a kernel mode 230. Non-native APIs
`220 are in the user mode 210 and a non-native kernel is in
`the kernel mode 230. As a result, these three layers (user
`mode, kernel mode, and hardware) are executed solely in
`software in a segregated “box’200. There are other possible
`arrangements for a VM. For example, someorall of the VM
`components may be implemented within the native kernel
`130.
`
`the actual non-native kernel 230 is
`[0034] Notice that
`being executed within the VM 200. The non-native kernel
`230 is not being emulated. Rather, it is running on top of an
`emulated hardware layer 250 of the VM 200.
`
`[0035] Those of ordinary skill in the art understand the
`VM model. Although this model
`is very common,it is
`consume a large amount of resources and processing power
`(ie., it is expensive). This is because it emulates a non-
`native hardware and exccutes the complete non-native OS
`on top of that emulated hardware. In addition, non-native
`applications operating within a VM box cannot interoperate
`(“interop”) with native applications running within the
`native platform. Moreover, they cannot interoperate with
`other non-native applications running within other VMs.
`Thus, VM cmulation is expensive and incompatible.
`
`

`

`US 2002/0052727 Al
`
`May2, 2002
`
`SUMMARY
`
`[0036] Described herein is a technology facilitating the
`operation of non-native program modules within a native
`computing platform. This invention further generally relates
`to a technology facilitating the interoperability of native and
`non-native program modules within a native computing
`platform.
`
`Specifically, this technologyinvolves an emulation
`[0037]
`of the kernel of the non-native operating system. Instead of
`interacting with the native kernel of the native computing
`platform, the non-native program modules interact with a
`non-native kernel emulator. This emulator handles the nec-
`
`essary conversions and translations. With this non-native
`kernel emulation, native and non-native program modules
`are interoperable. Except for the kernel emulator, noneofthe
`program module (native or non-native) and noneofthe other
`portions of the native computing platform are aware of the
`emulation. The computing environment and other program
`modules appear to be non-native to the non-native program
`modules. Likewise, the non-native program modules appear
`to be native to the computing environment and the native
`program modules.
`
`[0038] This summary itself is not intended to limit the
`scope of this patent. For a better understandingof the present
`invention, please see the following detailed description and
`appending claims, taken in conjunction with the accompa-
`nying drawings. The scope of the present
`invention is
`pointed out in the appending claims.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0039] The same numbers are used throughout the draw-
`ings to reference like elements and features.
`
`[0040] FIG. 1 is a schematic block diagram showing a
`computing architecture.
`
`[0041] FIG. 2 is a schematic block diagram showing a
`computing architecture with an example ofa virtual machine
`(VM)implementation.
`
`[0042] FIG. 3 is a schematic block diagram showing a
`computing architecture showing an embodiment in accor-
`dance with the invention claimed herein.
`
`[0043] FIG. 4 is a schematic block diagram of a kernel
`emulator in accordance with the invention claimed herein.
`
`[0044] FIG. 5 is a flow diagram showing a methodologi-
`cal implementation of the invention claimed herein.
`
`[0045] FIG. 6 is an example of a computing operating
`environment capable of implementing an implementation
`(wholly or partially) of the invention claimed herein.
`
`DETAILED DESCRIPTION
`
`forth specific
`following description sets
`[0046] The
`embodiments of a kernel cmulator for non-native program
`modules here that
`incorporate elements recited in the
`appended claims. These embodiments are described with
`specificity in order to mect statutory written description,
`enablement, and best-mode requirements. However,
`the
`description itself is not intended to limit the scope of this
`patent.
`
`[0047] Described herein are one or more exemplary imple-
`mentations of a method and system of fusing portions of a
`print medium. The inventors intend these exemplary imple-
`mentations to be examples. The inventors do not
`intend
`these exemplary implementations to limit the scope of the
`claimed present invention. Rather, the inventors have con-
`templated that the claimed present invention might also be
`embodied and implemented in other ways, in conjunction
`with other present or future technologies.
`
`[0048] Anexample of an embodiment ofa kernel emulator
`for non-native program modules here may be referred to as
`an “exemplary kernel emulator.”
`
`[0049]
`
`Incorporation by Reference
`
`[0050] This provisional application is incorporated by
`reference herein: U.S. Provisional Patent Application Ser.
`No. 60/244,410,
`titled “Kernel Emulator for Non-Native
`Program Modules”filed on Oct. 30, 2000.
`Introduction
`
`[0051]
`
`[0052] The one or more exemplary implementations,
`described herein, of the exemplary kernel emulator may be
`implemented (whole or in part) by a kernel emulator 400
`and/or by a computing environmentlike that shown in FIG.
`6.
`
`[0053] The exemplary kernel emulator, described herein,
`provides a mechanism with which non-native applications
`can be mn on a native platform transparently. For instance,
`32-bit applications can be run on 64-bit platform by using
`the exemplary kernel emulator.
`
`‘This mechanism canalso be used to plug-in a CPU
`[0054]
`simulator to broaden the scope. For example, the exemplary
`kernel emulator enables an application to run on a computer
`with a Merced processor where the application was written
`for x86 instruction set.
`
`[0055] Using an exemplary implementation of the kernel
`emulator, the kernel of nearly any platform may be emulated
`and different CPU instructions can be simulated by plug-in
`CPUsimulators.
`
`references to “kernel emulation” mean
`[0056] Herein,
`emulation of a non-native kernel within the context of a
`
`to “kernel
`nalive platform. Similarly, references, herein,
`emulator’ mean a non-native kernel emulator within the
`
`context of a native platform.
`
`[0057] Overview of Kernel Emulation
`
`[0058] As described in the above Background section,
`traditional solution for enabling non-native programs to
`operate on top of a native platform is virtual machine (VM).
`However, kernel emulation is less expensive than VMs. Less
`expensive in terms resources dedicated to emulation (e.g.,
`resources include processor cycles, memory, overhead,etc.).
`Moreover, unlike VM emulation,all applications (including
`both native and non-native) may interoperate (“interop”).
`
`In this cxemplary kerncl cmulation, described
`[0059]
`the non-native applications believe that they are
`herein,
`running on an operating system (OS) with their non-native
`kernel. Instead, their non-native kernel is being emulated.
`The non-native kernel emulator intercepts kernel calls made
`by the non-native applications and translates them into
`native kernclcalls.
`
`

`

`US 2002/0052727 Al
`
`May2, 2002
`
`[0060] The exemplary kernel emulator is an emulator of
`the kernel of a non-native OS. It allows non-native appli-
`cations to run within a native environment by emulating the
`non-native kernel of a non-native OS. The hardware is not
`emulated. Nor are the APIs. Instead,
`the kernel of the
`non-native OS is emulated. The emulated kernel translates
`non-native calls (from the applications and their APIs) into
`calls that can be interpreted and handled by the native OS.
`Moreover, the emulated kernel interprets and handles infor-
`mation flowing to the non-native applications from the
`native OS.
`
`[0061] To accomplish this, an exemplary kernel emulator
`may perform one or more of the following functions:
`
`translate hardware instruction set from non-
`[0062]
`native to native
`
`intercept kernel calls to convert from non-
`[0063]
`native memory addressing to native memory
`addressing
`
`constrain memory access of non-native appli-
`[0064]
`cations to only the memory space addressable by
`such applications(e.g., the lower 2GB of RAM). By
`doing so, the native memory manager need not be
`bothered with such constraints
`
`[0065] manage memory shared by both non-native
`and native applications
`
`accommodate a suitable CPU simulator that
`[0066]
`can be plugged in to simulate a variety of CPU
`architectures.
`
`[0067] Computer Architecture Implementing Exemplary
`Kernel Emulator
`
`[0068] FIG. 3 illustrates a computer architecture 300
`within which the exemplary kernel emulator may be imple-
`mented. The architecture includes a native platform, which
`includes hardware 350, kernel mode 330, and set of native
`APIs 320 of user mode 310. The top of the architecture 300
`is the user mode 310. It includes applications. More spe-
`cifically, it includesnative applications(such as applications
`312a-c) and non-native applications (such as applications
`314a and 3145).
`
`[0069] The native applications communicate with a set of
`native APIs 320. Typically,
`this native API set 320 is
`considered part of the native OS, and thus, part of the native
`computing platform. The non-native applications commu-
`nicate with a set of non-native APIs 322. Typically, this
`non-native API set 320 is considered part of a non-native
`OS, and thus, the set is not part of the native computing
`platform.
`
`[0070] Without the exemplary kerne] emulation, the non-
`native applications (such as 314a and 3146) would not
`function. Why? They cannot call
`the native APIs 320
`because they are unaware of them and because the native
`APIs are written to understand the instruction set and
`
`memory organization of the native platform, which arc
`different from the instruction set and memory organization
`of the non-native platform expected by the non-native
`applications.
`In addition,
`if the non-native applications
`called their own non-native APIs 322, the non-native APIs
`would fail for the same reasons given above. Furthermore,
`the non-native APIs attempts to call the kernel APIs would
`
`call native kernel APIs 340. Such calls would not be
`understood by the native kernel APIs 340.
`
`[0071] The non-native APIs 322 include “stub” code that
`directs their calls to a non-native kernel, which does not
`exist in the native platform. However,this “stub” codeis the
`bridge between the “user mode” and the “kernel mode.” In
`this exemplary kernel emulator, this stub code is modified so
`that it calls a non-native kernel emulator 400.
`
`[0072] The next layer of the architecture 300 is the native
`kernel mode 330. This may be generally called the native
`“kernel” of the native OS. Since it is part of the native OS,
`it is part of the native computing platform.
`
`[0073] This native kernel 330 includes the native kernel
`APIs 340 and various kernel functions 333, such as I/O,
`security, display control (i.e., access to the screen), memory
`management, and other privileged functions. The native
`kernel 330 has sole access to the hardware in the hardware
`
`layer 350 via device drivers 342 and other hardware inter-
`faces 344. Native kernels APIs 340 are those APIs within the
`kernel that arbitrate access to the kernel functions.
`
`[0074] Although FIG. 3 does not show the components
`333-344 of the kernel 330 with connections between them,
`these components are connected as is necessary. The cou-
`pling lines are omitted from the drawing for the sake of
`simplicity and clarity.
`
`[0075] Below the kernel mode 339,there is the hardware
`layer 350. This layer includes all of the hardware of the
`actual computer. This includes the processor(s), memory,
`disk I/O,other I/O, etc. The native platform also includes the
`hardware layer.
`
`[0076] Therefore, native computing platform includes the
`hardware layer 350, the kernel layer 330, and typically the
`user-mode native APIs 320. The native platform does not
`include the non-native APIs 322 or the non-native kernel
`emulator 400.
`
`[0077] Exemplary Kernel Emulator
`
`[0078] As shown in FIG.3, the non-native kernel emu-
`lator 400 is part of both the user layer of the user mode 310
`and the kernel layer of the native kernel mode 330. Conse-
`quently, portions of the non-native kernel emulator 400 may
`operate primarily in the user layer and others may operate
`primarily in the kernel layer. Alternatively, the non-native
`kernel emulator 400 maybepartof just the kernel layer. The
`non-native kernel emulator 400 communicates with non-
`native APIs 332, the native kernel, and directly with the
`memoryof the hardware layer 350.
`
`[0079] Although FIG. 3 shows the non-native kernel
`emulator 400 within the kernel mode layer,
`it may be
`implemented in the user mode layer in alternative embodi-
`ments. It may also be implementedpartially in the user mode
`and partially in the kernel mode.
`
`FIG. 4 illustrates the non-native kernel emulator
`[0080]
`400, which is an implementation of the exemplary kernel
`emulator. It includes an emulator 410 of non-native kernel
`APIs, which may also be called the non-native CPU simu-
`lator (or simply the “CPU simulator). To avoid confusion
`with nomenclature, this will be called CPU simulator 410.
`
`[0081] Although this name seems to imply hardware emu-
`lation,
`the hardware is not being emulated by the CPU
`
`

`

`US 2002/0052727 Al
`
`May2, 2002
`
`simulator 410 or by any other portion of the non-native
`kernel emulator 400. As discussed in the Background sec-
`tion, the OS is inextricably linked to the hardware (included
`the CPU). Therefore, the native and non-native hardware is
`a major consideration in non-native kernel emulation. Those
`of ordinary skill in the art see and understand that this CPU
`simulation is fundamentally different from an emulation of
`hardware (like in the VM model).
`[0082] The exemplary kernel emulator may have CPU
`simulators for different platforms. The exemplary kernel
`emulator finds a CPU simulator for the target CPU archi-
`tecture (of the non-native application) and usesforits kernel
`emulation.
`
`[0083] The CPU simulator 410 includes a translator 412
`for translating non-native to native CPU instructions sets, a
`converter 414 for converting non-native to native word
`sizes, and a memory constrainer 416 to limit the memory
`accessible to non-native applications to that which such
`applications are capable of addressing.
`the translator
`[0084]
`In the exemplary implementation,
`412 and converter 414 operate primarily within the user
`mode. The advantage to running them in user modeis that
`bugs in that code will crash only the user-mode process.If
`code running in kernel mode crashes, it will likely crash the
`entire machine.
`
`[0085] Calls to the Kernel by Non-Native Applications
`[0086] The CPU simulator 410 receives the kernel calls
`from non-native applications. More specifically, the CPU
`simulator 410 receives the kernel calls from non-native
`APIs.
`
`[0087] The kernel emulator 400 does not perform the
`functions of a kernel. Rather,
`it translates the non-native
`calls from their non-native format to a native format. It then
`
`passes the translated calls onto the native kernel for the
`native kernel to process as if the call was from a native
`application. However, to do this may involve more than a
`simply translation of a language. It may involve a conver-
`sion of paradigms between the non-native and native plat-
`forms.
`
`[0088] For or example, within a 32-bit platform (such as
`Microsoft® Windows® 98 and an x86 instruction-set pro-
`cessor), when an application wants to make a kernel API
`call, it pushes its arguments onto a stack (within memory).
`The arguments sit in memory.If the application wantsto call
`an API and passit “3” and a pointerto a string of text, then
`the application writes “3” to the memory (onto the stack) and
`then writes the address of the string to memory, as well. The
`API can read these values from memory to pick up the
`arguments when the API is executed.
`[0089] Continuing the example, on a 64-bit platform (such
`as a 64-bit OS and an Intel® Itanitum™processor), argument
`values are passed within the CPUitself. More specifically,
`the argument values are passed within the registers of the
`CPU. Instead of an application storing the argument values
`in a stack (ie., memory), it stores them in CPUregisters.
`[0090]
`Thetranslator 412 performsinstruction emulation.
`It handles the cmulation of the non-native proccssor’s
`instruction set.
`
`the translator 412 and converter 414
`[0092] Together,
`manage the argument-passing-via-stack convention of the
`32-bit platform to the argument-passing-via-registers con-
`vention of the 64-bit platform. This is an example of a
`paradigm change in how argument values are passed. The
`CPU simulator 410 accounts for this change with its trans-
`lation of the CPU instruction set by translator 412.
`
`In another example, in a 32-bit platform, the word
`[0093]
`size is 32bits long. Thus, addresses and data are typically
`written in 32-bit sized words in memory. In a 64-bit plat-
`form, the word size is 64bits long. Thus, addres