Transportable volume, local environment repository

This application is a continuation of, and claim priority to, U.S. Provisional Application Ser. No. 60/225,528, filed on Aug. 15, 2000, and is incorporated by reference herein.

1. Field

This disclosure relates to an emulator for operating systems, more particularly to a selectable, portable emulator repository.

2. Background

Mobility in computing has become far more important. Notebook, subnotebook and palmtop computing platforms abound. Typically, users employ these devices when traveling and then synchronize their data between a base computer, either at the home or the office. This ensures that their data is updated between the two devices. Other users rely strictly on their portable platform. However, it is sometimes not convenient to carry the portable platform. This leaves the user at a loss if the user travels to a location that does not have a computer with the same operating system of the user's system.

One solution to allowing a user's environment to be simulated is VirtualPC™ software from Connectix, Inc. If a user having PC-compatible system wants to access PC software on a Macintosh computer, that user can run VirtualPC™. This is an example of software that can emulate computing environments. Current implementations target a single host system and are, therefore, not generally portable.

Other users access a base computer remotely. They use Remote Access Servers (RAS) in conjunction with software that allows them to access their base computer. This avoids the problems with synchronizing data and allows access to all of the necessary applications. However, there can be weaknesses in the communication link between the remote computer and the base computer. While they have access to their normal computing environment, they are tied to a particular method, such as a modem, to access that environment.

No method or apparatus exists in the current art that allows a user to save the entire computing environment onto a piece of removable media and access it anywhere. Examples of removable media include not only floppy diskettes and CD-ROMs, but also devices that are cable connected to a host system, such as IOMega Zip Drives™, and PakIt™ by In-System Design. However, these are typically used as mass storage devices and do not emulate a computing environment.

One potential problem with using an emulator that can interact with a host computer is contamination, whether the contamination be from a virus or just involves changing the operating parameters of the host or the emulator. If such an emulator were provided, it would need to insulate the host computer from the emulator and the emulator from the host computer, while providing full functionality of both.

One aspect of the invention is an operating environment emulation system. The system includes a memory, a connector and at least one set of instructions stored in the memory. The connector allows the emulation system to be connected to a host system. Upon connection, the instructions can be executed, allowing the user to establish a simulated operating environment on the host computer.

The invention may be best understood by reading the disclosure with reference to the drawings, wherein:

FIG. 1 shows one embodiment of an operating environment emulation system in accordance with the invention.

FIG. 2 shows one embodiment of a method of connecting a memory device with a host computer in order to establish a simulated operating environment in accordance with the invention.

FIG. 3 shows one embodiment of a method of insulating an operating environment emulator from a host computer, in accordance with the invention.

An operating environment emulation system is shown in FIG. 1 . This emulation system will be referred to as such, an emulator or a memory device. One of its functions is as a transportable volume acting as a local environment repository. The operating environments it may emulate would be those commonly used by computer users, including Windows™ 95/98/2000/NT, referred to here as Windows™ XX, Unix, Linux and MacIntosh. Those operating systems that run on the IBM-PC compatible standard will be referred to as personal computer (PC) compatible. The system 10 includes a memory 12 and a connector 14 .

The memory 12 includes a set of instructions, referred to here as an emulator 18 . There may be several versions of the emulator installed in the memory device 12 . Each copy of the emulator is intended for a different operating system and/or processor combination on the host computer. The combinations of processor and operating system are only limited by the manner in which the emulators are packaged. For example, there could be an emulator packaged by processor, such as the Intel Pentium 3™. The memory device may have several copies of the emulator on it, one each for Windows XX, Linux and Unix. Alternatively, the emulators could be packaged by operating system, such as one for Windows XX, with several versions for common processors.

Each emulator, then, is a set of instructions to emulate a particular operating environment for a particular processor. The set of instructions are the boot commands, and any other instructions necessary to simulate the operating environment. For example, Windows operating systems generally user application programming interfaces (APIs), dynamic link libraries (DLLs), etc., and object translation tools in operation. These would be included in the instruction set. The instruction sets for each operating system and each processor are typically available, the system designer would just select which combinations would be included as options.

Within the memory device is a data file 16 . The data file 16 contains all of the elements of the original operating environment to be simulated by the host computer. The data file will typically remain the same, as it is accessible by the emulators. When connected to the host computer 20 , the operating system of the host computer accesses the appropriate packaged emulator, and runs the emulator as a task by executing the instructions, and accesses the data file. Once the data file is accessed, the host computer becomes an emulation of the original operating environment.

It must be noted that the host computer does not have to be a complete personal computer system. The emulator only requires a processor 22 that is running an operating system and a connector. This could include any number of accessories available today, such as palmtop devices, notebook computers, possibly even cellular phones, if the phone has the correct connectors, operating system and processor. These non-PC devices will be referred to as accessory devices.

Similarly, the cable 24 may not be necessary depending upon the standard used to establish communication between the two systems. If the standard used is IEEE (Institute of Electrical and Electronic Engineers) 1394, also known as ‘firewire,’ or USB (Universal Serial Bus), a cable will be needed. Other types of connections, such as wireless communications in accordance with a given wireless standard such as 802.11b, Ethernet, or infrared connections could also be made. The connectors in those examples would be of the appropriate technology to allow information to pass between the host computer and the emulation system. In some embodiments, a USB cable that can connect directly to the host computer may be the easiest and most convenient configuration. The user can connect the emulation system by simply plugging in the cable to the host computer.

In the below discussion of the operation of the invention, there will be two different operating systems or operating system versions discussed. The host computer to which the emulation system connects and executes the emulator will have an original operating system. This is the operating system under which the host computer is running when the emulator is loaded onto the host computer. The simulated operating system is that operating system being simulated by the emulation system. The two operating systems may be of different types and/or versions, as will be discussed below.

FIG. 2 shows one embodiment of a method of establishing a simulated operating environment upon connection between the memory device and the host computer. At 26 , the connection is made. Using a plug-and-play sequence familiar to most users, the host computer will display the new device as an attached memory device, with a list of executable files. The list of executable files is the various versions of the emulators available on the memory device in the emulation system. For example, the user may connect the emulation system as drive ‘E:’ and display a list of files on that drive. The files may be named so as to make the identification of the appropriate file easy on the user, such as ‘Windows XX.exe’ or ‘Linux.exe.’

The host system receives the user input and loads the version of the emulator desired, from the memory of the emulation system to the host processor at 30 . The host processor then executes the selected set of instructions at 32 . Upon execution of the selected emulator, the simulated operating environment is established on the host computer or accessory device.

The system allows the user to exactly replicate the typical computing environment in which that user operates. The user may use Windows NT™ at work. Desiring to work at home in the same operating system, the user takes his emulator and plugs it into his home computer. The home computer may have some other member of his family running a task, such as a download in Windows 98™. A pop-up window appears inquiring as to the selection of an executable file from the new device. The user selects the proper emulator. The selection and execution of the proper emulator will cause the host computer to appear to be a Windows NT™ system, even though the original operating system of the host computer is Windows 98™.

In some embodiments, the host computer may identify the proper file and execute it without interaction from the user. For example, the file may be named according to a naming convention of the primary operating system on the host computer or accessory device. The primary operating system would access the file and execute it without waiting for an input from the user.

However selected, the emulator then provides the processor with the necessary data and applications to run as if it were a Windows NT™ system. The user can now move around and perform tasks in the same environment as he uses at work. No preconfiguration or modification of the host computer is necessary to run the simulated operating system.

One concern with this approach is any possible contamination or interference between the emulator and the host computer. FIG. 3 shows a flowchart of one embodiment of a method to prevent this kind of contamination. The set of instructions that comprise the emulator will also operate to insulate the two systems to prevent any inadvertent or intentional interaction between them.

As can be seen in FIG. 3 , any type of task management available to the primary operating system will be disabled at 34 . For example, the primary operating system may be Windows 98™, as in the above example. In this operating system, it is possible to press ALT-TAB to switch between tasks running in the primary operating system. Other types of task management are available, depending upon the operating system. Conceivably, one could press ALT-TAB while the secondary operating system is running from the emulator and switch to other tasks running on the primary operating system. However, with the emulator software in place, this type of interaction may be prevented.

It is possible that the user may want some sort of interaction between the two systems. For example, the user may have worked on a file at the office that he wants to save onto his home computer. The emulator may allow some sort of user selection to define the nature of allowed interactions. In order to access the underlying system, various types of security could be required, such as passwords. However, for this example, complete insulation will be assumed.

In order to ensure complete insulation, input devices will have to have their interrupts routed to run only through the secondary operating system at 36 . Devices such as keyboards, joysticks and mice generate an interrupt or other type of signal that notifies the host processor of an input signal. Once the emulator starts to operate, all input/output signals will be routed through it to allow the emulator to enforce the insulation. This will prevent any contamination and will allow tasks running on the primary operating system to remain undisturbed.

As a failsafe to ensure insulation, an environmental shut down can be provided that allows the host system to protect itself at 38 . Inadvertent or intentional actions could cause the insulation between the systems to be breached. If that happens, the emulator will effect an environmental shutdown of the secondary operating system as shown at 38 . Otherwise the system continues to operate.

In this manner, users are provided with the ability to preserve a current operating system environment and transport it to another computer or computing device. The emulator can be connected to any computing device with a processor and the proper connector. Users can now transport their local environment with a smaller, lighter, more convenient device than a typical laptop computer.

Thus, although there has been described to this point a particular embodiment for a method and apparatus for an operating environment emulation system, it is not intended that such specific references be considered as limitations upon the scope of this invention except in-so-far as set forth in the following claims.