as) United States
`a2) Patent Application Publication co) Pub. No.: US 2002/0174215 Al
`
`(43) Pub. Date: Nov.21, 2002
`Schaefer
`
`US 20020174215A1
`
`(54) OPERATING SYSTEM ABSTRACTION AND
`PROTECTION LAYER
`
`(76)
`
`Inventor: Stuart Schaefer, Marblehead, MA (US)
`
`Correspondence Address:
`Albert T. Keyack
`1005 Glenderon Drive
`Ambler, PA 19002 (US)
`
`(21) Appl. No.
`
` 09/859,209
`
`(22) Filed:
`
`May16, 2001
`
`Publication Classification
`
`(ST) Te CU? eecessesensnsssssessesneseeeneenenee GO6F 15/173
`(52) US. Che
`eeececcsseseeccssssseseeseeneeeseenrnnmeeesceneesesses 709/224
`
`ABSTRACT
`(57)
`The present invention provides a system for creating an
`application software environment without changing an oper-
`
`ating system of a client computer, the system comprising an
`operating system abstraction and protection layer, wherein
`said abstraction andprotection layeris interposed between a
`running software application and said operating system,
`whereby a virtual environment in which an application may
`run is provided and application level interactions are sub-
`stantially removed. Preferably, any changes directly to the
`operating system are selectively made within the context of
`the running application and the abstraction and protection
`layer dynamically changes the virtual environment accord-
`ing to administrative settings. Additionally,
`in certain
`embodiments, the system continually monitors the use of
`shared system resources andacts as a service to apply and
`remove changes to system components. The present thus
`invention defines an “Operating System Guard.” These
`components cover the protection semantics required by
`.DLLs and other shared library code as well as system
`device drivers,
`fonts,
`registries and other configuration
`items, files, and environmentvariables.
`
`60
`
`Application/User Data
`
`Application
`
`Application
`
`50
`
` Application/User Data
` 60
`
`50
`
`
`
`
`
`
`
`
`Shared Resources
`
`Shared Resources
`
` Trusted Shared
`
`Resources
`
`
`
`Operating System
`
`
`
`Google Exhibit 1021
`Google v. VirtaMove
`
`Google Exhibit 1021
`Google v. VirtaMove
`
`

`

`Patent Application Publication Nov. 21, 2002 Sheet 1 of 4
`
`US 2002/0174215 Al
`
`09
`
`OOL
`
`
`
`D}Dq4asp~/uolDoI|ddyDJDqJes/uolool|\ddy|—09
`|
`
`lua}iskSBuljosedo
`SOOINOSSYPeuDUsSSOOUNOSayPesDYS
`
`
`
`uonpoiddyuoljpoiddyOS
`
`eeon|S90UNOSay
`
`psiDUSpaysnil
`
`
`
`
`
`P4ABNDSO
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Nov. 21,2002 Sheet 2 of 4
`
`US 2002/0174215 Al
`
`Application 1
`Instance 1
`
`Operating System
`
`Application 1
`Instance 2
`
`
`
`152
`
`Application
`
`
`Configuration
`
`
`
`
`
`
`
`Application
`
`Configuration |
`154
`
`
`
`
`Private
`Contexts
`
`|
`
`System
`
`System
`Configuration
`
`System Services
`
`Configuration
`System Services
`
`Fig. 2
`
`

`

`Patent Application Publication Nov. 21,2002 Sheet 3 of 4
`
`US 2002/0174215 Al
`
`52
`
`
`
`
`
`Application 1
`Instance 1
`
`54
`
`
`Application 1
`Instance 2
`
`
`
`|
`
`10C
`
`Operating System Guard
`
`Application
`Configuration
`
`Shared
`Context
`
`
`Configuration
`
`System Services
`
`System
`
`Fig. 3
`
`

`

`Patent Application Publication Nov. 21, 2002 Sheet 4 of 4
`
`US 2002/0174215 Al
`
`108
`
`112
`
`Virtual File System
`Manager
`
`104
`
`
`Proc.Environ.
`Configuration
`
`
`102
`
`Core
`Manager
`
`Operating System Guard
`
`Process
`Manager
`
`Recovery
`
`

`

`US 2002/0174215 Al
`
`Nov.21, 2002
`
`OPERATING SYSTEM ABSTRACTION AND
`PROTECTION LAYER
`
`[0001] This application is a continuation-in-part of U.S.
`Patent Application No.
`,
`the entirety of which is
`incorporated herein by reference as if fully set forth.
`
`[0002] The present inventionrelates to computer software,
`and more particularly to operating system software.
`
`-BACKGROUND OF TE INVENTION
`
`In many environments,but particularly in environ-
`[0003]
`ments where an application is delivered via a network, the
`most important feature is an ability to run applications on the
`fly, without a complex installation Typically, in certain prior
`art systems, great pains were taken to modify a client system
`to appear as if a program wasinstalled, or to actually install
`the software itself and then back out these modifications to
`restore the original configuration. In doing this, mile prob-
`lems present themselves: conflicts between an application
`and the computer’s current configuration, multiple instances
`of the sameor different applications, complexity of the back
`oul process requires an application to be put through a
`rigorous process to ensure all of its modifications can be
`accounted for, and the use of shared files and system
`components by multiple applications complicates back out
`and the installation process.
`
`SUMMARYOF THE INVENTION
`
`[0004] The present invention provides a system for creat-
`ing an application software environment without changing
`an operating system of a client computer, the system com-
`prising an operating system abstraction and protection layer,
`wherein said abstraction and protection layer is interposed
`between a running software application and said operating
`system, whereby a virtual environment in which an appli-
`cation mayrun is provided and application level interactions
`are substantially removed. Preferably, any changesdirectly
`to the operating system are selectively made within the
`context of the running application and the abstraction and
`protection layer dynamically changes the virtual environ-
`ment according to administrative settings. Additionally, in
`certain embodiments, the system continually monitors the
`use of shared system resources and acts as a service to apply
`and remove changes to system components.
`
`[0005] Thus, for example, in embodiments within Win-
`dows-based operating systems, and whereinall operations to
`the Windows Registry are through the Win32 API,
`the
`system preferably provides a means for hooking functions,
`whereby each time said functions are invoked another
`function or application intercepts the call, and the system
`most preferably hooks each appropriate API function to
`service a request whether made by an application run from
`a server or if made by an application against a configuration
`key being actively managed
`
`In other preferred embodiments of the present
`[0006]
`invention, additional functionality is provided, such as those
`embodiments wherein the operating system abstraction and
`protection layer manages
`the
`integration of multiple
`instances of an application by recognizing how many
`instancesof an application are running, and in such embodi-
`ments most preferably it also avoids making changes on
`startup and shutdown unless there is only onc application
`
`instance running. In this embodimentit is also possible to
`support multi-user operating systems in which multiple
`instances of an application can be running on behalf of
`different users.
`
`[0007] Thus, the operating system abstraction and protec-
`tion layer presents an environment to an application that
`appears to be an installation environment without perform-
`ing an installation, whereby a “pseudo installation” is cre-
`ated in which all of the settings are brought into a virtual
`environmentat the time the application runs. Or in the case
`of an installed application, acts to dynamically modify the
`behavior of the application at run-time. Preferred embodi-
`ments provide a means for preventing information on the
`client computer from interfering or modifying the behavior
`of an application, and most preferably provide a means for
`dynamically changing the virtual environment according to
`administrative settings. As mentioned above,
`in certain
`embodiments it will be possible to have more than one
`instance of a single software application running on the
`same client computer, even if it was not originally authored
`to do so. In such embodiments, shared, controlled contexts
`are provided in which at least two of said instances of a
`single application share one or more virtual settings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG.1 is a block diagram schematic showing the
`[0008]
`relative relationship of the present invention, an operating
`system and a software application;
`
`[0009]
`
`FIG.2 is a block diagram schematic showing
`
`[0010]
`
`FIG.3 is a block diagram schematic showing
`
`(0011] FIG. 4 is a block diagram schematic showing
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`[0012] Referring now to FIG.1, thereis illustrated a block
`diagram schematic showing the relative relationship of the
`present invention, an operating system and a software appli-
`cation. Preferred embodiments of the present
`invention
`provide an operating system abstraction and protection layer
`100 denominated an “Operating System Guard.” Internally,
`many operating systems 10 provide fault domainsto protect
`applications 50 from affecting cach other when run. How-
`ever, shared system resources and many other operating
`system features allow this protection domain to be compro-
`mised. An operating system abstraction and protection layer
`100 will provide an additional, programmatically controlled
`barrier between applications 50 to remove most application
`level interactions. Disposed between the application 50 and
`operating system 10 the operating system abstraction and
`protection layer 100 selectively allows changes directly to
`the operating system 10, versus containing the change
`within the context of the running application For one
`example, in Windows-based systems, all operations to the
`Windows Registry are typically done through the Win32
`APL As cxplained below, system functions like Que-
`ryRegEx and GetProfileString can be hooked so that each
`time they are invoked, another function or application inter-
`cepts the call. The Operating System Guard 100 of the
`present invention will hook each appropriate API function to
`service the request, if made by an application being actively
`managed or if made by an application against a configura-
`
`

`

`US 2002/0174215 Al
`
`Nov.21, 2002
`
`tion item being actively managedIn this way, unless explic-
`itly configured to do so, the present invention can create the
`application environment without making any actual changes
`to the end-user’s system. Also, any modifications made at
`run-time by the application can be persisted or removed
`easily.
`
`[0013] As used herein the term “Operating System Guard”
`defines a layer between a running application and the
`operating system of a target computeror client computer that
`provides a virtual environment in which an application may
`run. This virtual environment has several purposes. First, it
`prevents a running application from making changesto the
`client computer. If an application attempts to change under-
`lying operating system settings of a client computer, such
`settings are protected and only “made”in the virtual envi-
`ronment. For example, if an application attempts to change
`the version of a shared object like MSVCRI-DLL,
`this
`changeis localized to the application and the code resident
`on the client computer is left untouched.
`
`[0014] Second, the invention presents an environmentto a
`running application that appears to be aninstallation envi-
`ronment without performing an installation, and is thus a
`“pseudo installation” or “installation-like.” All of the set-
`tings are brought into a virtual environmentat the time the
`application being served runs, or just-in-time when the
`application needs the particular setting. For example, if a
`computer program such as Adobe Photoshop® cxpccts to
`see a set of Windows Registry entries under HKEY_LO-
`CAT._MACHINE/Software/Adobe and they are not there on
`the client A computer since Photoshop was neverinstalled,
`a system made in accordance with this aspect of the present
`invention will “show”those registry entries to the Photoshop
`programming code exactly as if they were resident on the
`client computer.
`
`[0015] Next, the invention prevents information thal may
`exist on the client/users machine from interfering with or
`modifying the behavior of an application. For example, if
`the user has already existing registry entries under:
`
`IIIKEYLOCAL_MACTINE/Software/Adobefor
`(0016]
`an older version of Photoshop, but now wishes to operate a
`newer version, these entries can be hidden from the new
`application to prevent conflicts.
`
`Finally, the present invention unlocks application
`[0017]
`behavior that may not exist as the application is currently
`written.
`It does this through the ability to dynamically
`change the virual environment according to administrative
`settings. For example, in a typical instance of an enterprise
`software application, a client application may expect to read
`a setting for the address of the database to which the user
`should connect from a setting in the registry. Because this
`registry key is often stored in HKEY_LOCALMACHINE,
`the setting is global for the entire client computer. A user can
`only connect to one database withoutreinstalling the client,
`or knowing how to modify this registry key, and doing so
`each time they wish to run the application. However, by
`implementing the present invention,
`two instances of the
`application may now run on the same client computer, each
`connecting to a different database.
`
`[0018] CONTEXTS
`
`In providing this functionality, each application is
`[0019]
`able to run in a private context within the system. To the
`
`application, it has its own private view of what the system
`looks like and its behavior. The present invention provides
`this by its inherent nature. Referring to FIG.2, two separate
`applications 52,54, or two instances of the same application
`(50 illustrated in FIG. 1), can be provided private contexts
`in which they will appear to have separate ordiffering copies
`of system services, configuration and data. In the preferred
`embodiment, this is the default behavior of the system.
`
`[0020] By extending this concept, the Operating System
`Guard 100 of the present invention can also provide shared,
`controlled contexts in which two or more applications 52,54
`can share some or all of their virtual settings. This is
`important for application suites such as Microsoft Office, or
`for applications that perform differently in the presence of
`other applications. For example, many applications use
`Microsoft Word as an engine for doing Mail Merge or
`document creation fuctionality. The application must know
`aboutthe installation or presence of Word and beable to tap
`into its
`functions.
`In the preferred embodiment,
`two
`instances of the same application will share a single context
`by default, while two separate applications will maintain
`private contexts. Referring to FIG, 3, the two applications
`52,54 can run while the Operating System Guard 100
`provides a shared view of the available system resources.
`
`[0021] DESIGN
`
`the Operating System
`[0022] As illustrated in FIG. 4,
`Guard is comprised of the following subsystems: core 102,
`configuration manager 104, file manager 106, shared object
`manager 108, device manager 110, font manager 112, pro-
`cess manager 120, process environment manager114, loader
`116, and recovery manager 118. With the exception of the
`core 102, the process manager 120, and the loader 116, all
`other subsystems are elements of the Virtualization System
`described in further detail below. The core 102 is primarily
`responsible for managing applications and their context as
`defined by the configuration files.
`
`[0023] The process manager 120 provided by the Operat-
`ing System Guard allowsthe core 102 to be informed of any
`process or thread event
`that may be of interest. It also
`provides an abstraction layer to the operating system-depen-
`dent
`implementations for managing a process space and
`handling thread processing. Processes may be grouped
`together into application bundles. An application bundle is a
`group of processes which all share their virtual resources
`with each other. For example, Microsoft Word and Microsoft
`Excel may wantto share the virtual registry and virtualfile
`system to be able to work together as an application suite.
`The process manager 120 calls these application bundles
`“applications”. The information about an application exists
`until the process manager 120 is told to release the appli-
`cation. If another process needs to be loaded into the
`application bundle, it may do so as long as the application
`has not been released.
`
`[0024] The loader subsystem 116 of the present invention
`is used to allow virtual environments to be transferred into
`
`and out of the running system. Each of the Virtualization
`Subsystemsis capable of serializing its configuration for the
`loader 116, and retricving it through the reverse process. In
`addition, the loader 116 is capable of staged loading/unload-
`ing and combining the results of individual stages into one
`single environment description.
`
`

`

`US 2002/0174215 Al
`
`Nov.21, 2002
`
`[0025] REGISTRY AND CONFIGURATION
`
`[0026] Applications require varying amounts of configu-
`ration information to operate properly. Anywhere from zero
`to thousands of configuration records exist for which an
`application can read its configuration On Windows,there are
`two commonplaces for configuration information, the Win-
`dows Registry and system level initialization files win.ini
`and system.ini
`In addition,
`the /(WINDOWS/SYSTEM
`directory is a commonplace for applications to write appli-
`cation specific configuration or initialization files. Applica-
`tions will also use configuration or data files in their local
`application directories to store additional configuration
`information. Often this information is difficult to deal with,
`as it is in a proprietary format. On platforms other than
`Windows, there is no equivalent of the Registry, but com-
`mon directories exist for configuration information. X Win-
`dows has an app-defaulls directory. Macintosh has the
`System Folder, and other operating systems will have cor-
`responding elements. It is important to note that on most
`UNIX systems, each individual application 52,54 will most
`often store its own configuration 152,154 locally, as seen in
`FIG.2.
`
`embodiment,
`one
`in
`invention,
`[0027] The present
`includes a virtual WindowsRegistry component, which will
`provide a full function registry to an application, but prevent
`modification to the underlying system registry. All keys that
`an application expects to access will be present, but may
`only exist in the virtual registry. In this way, the Operating
`System Guard 100 of the present invention and the Windows
`Registry form a two-stage process for accessing the registry.
`If an application needs access to a key, it will query the
`Registry. The Operating System Guard will respond with the
`keyand its value if it knowsit. Otherwise, it will allow the
`request to pass through to the Windows Registry. If an
`attempt is made to modify the value, the Operating System
`Guard will allow the modification to occur to itself only. The
`next time the application accesses the key, it will be present
`in the Operating System Guard and the request will not flow
`through to the real Registry, leaving it untouched.
`
`[0028] The keys that the Operating System Guard uses are
`specified in three separate sections. These Operating System
`Guard keys are specified as commandsin these sections to
`modify an existing key, delete the presence of a key, or add
`a newkeyto the registry. In this way, the virtual registry can
`appear exactly as the system intends. This is important as the
`presence or absence of a key can be as important as the
`actual value of the key.
`
`Inthe preferred embodiment, the Operating System
`[0029]
`Guard first loads a data file that contains basic registry
`entries for the application. Then a seconddata file is loaded
`that contains the user’s preferences. Finally, the Operating
`System Guard can optionally load a set of keys that include
`policy items that the user is not allowed to override. The
`three files load on top of each other with duplicate items in
`each file overriding items in thefile before it. The first time
`a user runs an application, the second datafile will not exist
`because there will be no user-specific information, only
`application defaults. After each session, though, the Oper-
`ating System Guard will save the user’s changes, generating
`that second data file for use in future sessions.
`
`[0030] Configuration files can be modified in two ways.
`First, the file can be edited directly by an application. In this
`
`the Operating System Guard File subsystem
`scenario,
`described below will address the modification made to the
`file. Second, in the preferred embodiment, an application
`can call the Windows API family of calls GetProfileString,
`WriteProfileString, or others to modify these files. In this
`case, the Operating System Guard of the present invention
`performs exactly as described above intercepting these calls
`and servicing them from within.
`
`[0031] SHARED OBJECTS
`
`[0032] Many components used by operating systems and
`running applications are shared across several applications
`or instances.In general, this is a very good idea. It saves disk
`space, not requiring many copies of the samefile. It also
`provides the ability for operating system vendors and third
`parties to create and distribute libraries of commonly used
`code. On the Windowsplatform Dynamic Link Libraries,
`DLLs, are often shared within and across applications. On
`other platforms, the problem is the same. On the Macintosh,
`INITs and other system components are loaded for applica-
`tions. These components can have many versions, of which
`only one is used at a time. On UNIX systems, dynamic
`shared objects, e.g., “so” library files, are used by applica-
`tions to speed load time, save disk space, and for other
`reasons. Manyprogramsusethe default “libc.so.” However,
`this library file is typically a symbolic link to some version
`of itself suchas libe.so.3. In practice,this feature has created
`havoc. ‘These shared components have often gone through
`revision, with many versions of the same componentavail-
`able to be installed Application authors have found their
`software to work with potentially only one or some of the
`versions of the shared component. Thus, in practice, appli-
`cations typically install the version they desire, overwriting
`other present versions. This potentially causes defaults in
`other applications running on a system
`
`[0033] On Windows 98, Windows 2000, Microsoft has
`created the Windows Protected File System (WPFS) to
`allow system administrators to create a file called XXXX-
`-LOCAL in the base directory of an application, where
`XXXX is the executable file name without the extension.
`This causes the Windows Loader to alter its method of
`
`resolving path references during LoadLibrary executions.
`This, however,
`is not sufficient
`to completely solve the
`problem. First, setting up the XXXX file is left
`to the
`knowledge of the system administrator, which varies widely.
`Second, a componentversion must undergo a rewind back to
`the original, then install this component in the local direc-
`tory, and then create the “LOCAL”file. This is not a
`straightforward process for any but the most basic compo-
`nents placed in WINDOWS/SYSTEM.Also, this solution
`does not cover all of the needed functionality. During
`LoadLibrary, Windowsusesdifferent path resolution seman-
`tics depending on whether the component wasresolved as a
`result of an explicit or implicit LoadLibrary, and also
`whether a Registry Key exists indicating that it is a named,
`or well-known, DLL. In this case, the LoadLibrary call will
`always resolve to the WINDOWS/SYSTEMdirectory.
`
`[0034] DLLs and other shared components also retain
`reference count semantics to ensure that a componentis not
`touched unless no running applications refer to it. In prac-
`tice, only applications from the operating system vendor and
`the operating system itself have done a good job of obeying
`this protocol.
`
`

`

`US 2002/0174215 Al
`
`Nov.21, 2002
`
`[0035] As a general rule, it is desired to have a shared
`object always resolve to the correct component. To provide
`this functionality it is required to understand the version of
`a component,or range of versions, that an applicationis able
`to function with. Then, when the application is to be run,the
`present
`invention should ensure that
`the component
`is
`resolved correctly. It is acceptable, in the present invention,
`to automate the use of WPFS or other operating system
`provided capability, if desired. In this case, it is necessary to
`detect needed components and place them in the local file
`system. This is more complex than just watching installa-
`tion, as an installation program will often not
`install a
`componentif the required one is alreadythere.
`
`It is desired to identify a method to ensure that
`[0036]
`named objects are also loaded correctly. On the Windows
`platform MSVCRT-.DLLis a significant culprit within this
`problem area. If multiple versions of this object are main-
`tained, the aforementioned Registry key can be dynamically
`changed, allowing the LoadLibrary function to resolve the
`correct component version. Another reasonable method of
`ensuring correct componentloading is the dynamic editing
`of a process environment to use a valid search path. This
`search path will ensure that a local componentis resolved
`before a system wide component. Another possible method
`for resolution of the correct shared object is through the use
`of symbolic links. A symbolic link can be madefor a shared
`component, whichis resolved at run-time by the computer’s
`file system to the needed component. Finally, the actual
`open/read/close requests for information from a shared
`objects file can be intercepted by the present invention and
`responded to dynamically for the correct version ofthe file
`which may exist on the local system or within the inven-
`tion’s subsystems.
`
`[0037] Several special forms exist. On the Windowsplat-
`form, OLE, ODBC, MDAC,... as well as a numberof other
`vendor specific components, are written to be shared glo-
`bally among several or all running processes. In the case of
`OLE, going as far as sharing data and memory space
`between separate processes. OLE prevents more than one
`copy of itself running at a time, as do manyof these
`components. OLEalso has many bugsandfeatures requiring
`a specific version to be loaded for a specific application. In
`the present invention,an application is able to load whatever
`version of OLEis required,still enabling the shared seman-
`tics with other components using the same version of OLE.
`
`In general, unless specifically configured as such,
`[0038]
`shared objects should be loaded privately to ensure conflict
`prevention. Nothing about
`the method used to allow a
`component to be loaded privately should prevent it from
`being unloaded cleanly or correctly loading for another
`software application, whether being actively managed bythe
`Operating System Guard or not. In addition, if the system
`crashes it is required to recover from this crash to a clean
`state, not having overwritten or modified the underlying
`operating system.
`
`virtual environmentorfiles to redirect to another within the
`virtual environment. Whenever the application accesses or
`modifies any files, the Operating System Guard checksif the
`file must be redirected, and if so, in the preferred embodi-
`ment redirects the request to a location specified in the
`Operating System Guard configuration.
`
`If an application tries to create a new file or open
`[0041]
`an existing file for writing on a user’s local drive,
`the
`Operating System Guard must ensurethat the file is actually
`ercated or modified in the redirected location. If the appli-
`cation is reloaded at a later time, this file mapping must be
`reloaded into the Operating System Guard virtual environ-
`ment. Whenthe request is to modify an existing file, which
`resides on a user’s local drive, the Operating System Guard
`must copythe file in question to the redirection point before
`continuing with the request. The redirected files may not be
`of the same nameasthe original file to ensure safe mapping
`of file paths. In the preferred embodiment, MI files are
`handled in this way to offer maximum system security while
`allowing maximum application compatibility.
`
`invention is particularly useful for
`[0042] The present
`applications delivered over a network in such implementa-
`tions it is important to understand that software applications
`are madeof several kinds of data, where the bulk ofthe files
`a software application uses are most preferably mounted on
`a separate logical drive. Configuration, including both file
`based and registry based, can be user specific and system
`wide. The application delivery system used should mark
`each file for which of these types any file is. This informa-
`tion provides hints to the Operating System Guard system to
`act on appropriately.
`
`[0043] DEVICE DRIVERS
`
`[0044] Many applications use device drivers or other
`operating system level software to implement some ofits
`functions such as hardware support or low levelinteractions
`directly with the operating system. In the present invention,
`the Operating System Guard will provide the capability of
`dynamically, and as possible privately, adding and removing
`these components to an application’s virtual environment.
`
`[0045] Many device drivers are built to be dynamically
`loadable. If at all possible, it is the preferred embodimentto
`load all device drivers dynamically. If a device driver
`requiresstatic load at boot time, the user must be presented
`with this knowledge before running the application. Once
`the system has rebooted, the application should continue
`from whereit left otf. However, a large percentage of device
`drivers are not dynamically unloadable. Although it is pre-
`ferred to dynamically unload the driver, if this cannot be
`accomplished the driver will be marked for removal on the
`next reboot, and the user should be made awareofthis. If the
`application is run a second time before the next reboot, the
`system should remain aware of the presence of the driver
`and not attempt a second installation, waiting for termina-
`tion to remark the component removable at next reboot.
`
`[0039] FILES
`
`It is important to characterize the base similaritics
`[0046]
`[0040] Many applications use data files within the appli-
`and differences, as they exist for each device driverclass,to
`ensure the present invention can correctly function. It is not
`cation to store configuration entries or other application
`truly desired to load and unload device drivers for system
`data. The present invention provides a virtual file system
`much like the virtual registry described above. Before the
`hardware that is constantly present. It should be understood
`
`applicationstarts, the present invention can loadalistoffile that although this is not a preferred embodimentin terms of
`system changes, includingfiles to hide andfiles to addto the
`programming casc,
`it is within the scope of the present
`
`

`

`US 2002/0174215 Al
`
`Nov.21, 2002
`
`invention and may be required for specific reasons, such as
`the restriction in licensing agreements for applications that
`are delivered and run using the present invention.
`
`[0047] On non-Microsoft platforms, device drivers are
`typically handled very differently. Macintosh systems sup-
`port both static and dynamic drivers, but
`they are all
`installed and removed through the same method Linking
`with the Macintosh system folder will provide the necessary
`support. For UNIX systems, device drivers most typically
`require a modification to the running UNIX kernel, followed
`by a reboot. This process can be very complex. In the
`preferred embodiment, this process is automated; including
`resetting the kernel once the application is complete. The
`general parameters of the process are the same as that
`described above for Windows applications, the actual pro-
`cess steps of compilation and persons familiar with such
`operating syslems can carry out reboot.
`
`Finally, those of skill in the art will understand that
`[0048]
`it is desirable to be able to recover and removedrivers across
`system failures. Whatever data or processes necessary to
`retain systemintegrity are therefore a preferred embodiment
`of the present invention. ‘Those of skill in the art will also
`appreciate that all
`types of device drivers might not be
`conveniently or efficiently provided via the present inven-
`tion, most particularly those associated with permanent
`hardware attached devices.
`
`[0049] OTHER ITEMS
`
`In the present invention, it is recognized that there
`[0050]
`are several components of the invention, the behavior or
`presence of which is different on alternate operating sys-
`tems. These components include fonts, processes, environ-
`ment variables, and others.
`
`Someapplications require fonts to be installed in
`[0051]
`order to perform correctly. Any fonts required will be
`specified in the Operating System Guard’s configurationfile.
`The Operating System Guard will enable these fonts prior to
`running the application and if necessary remove them after-
`wards. Most systems have