OS multi boot integrator

[0002] 1. Field of the Invention

[0003] The present invention relates to the field of computers and, more particularly to an operating system (OS) multi boot integrator.

[0004] 2. Description of the Related Art

[0005] The use of computers, especially the personal computer (PC) has become widespread. The computing power of the PC, whether coupled to a network or operating as a stand-alone device, has increased significantly with the development of new computer architectures. Newer operating systems (OS) have been developed to take advantage of the ever increasing computing power.

[0006] A computer operating system is a collection of software programs which control the execution of application programs running on the computer. Typically, an operating system manages the interaction of the computer hardware and software running on the computer by providing services to the software applications such as resource allocation, scheduling of tasks, data management and input and output (I/O) control. The loading of an operating system into the computer's memory is known as “booting” the OS. The reloading of an operating system (typically performed after resetting the computer) is known as “rebooting” the OS.

[0007] A computer user is free to purchase and install an operating system that differs from the one installed on the computer when it was purchased. Today, there are numerous commercially available operating systems to choose from including, but not limited, to MS-DOS, UNIX, LINUX, OS/2, WINDOWS 3.x, WINDOWS NT, and WINDOWS 95.

[0008] Although these operating systems perform similar tasks, and many are capable of running the same application programs, each operating system has its own strengths. Sometimes a user wishing to capitalize on the strengths of these operating systems will install more than one OS on the same computer. Commercially available software utilities aid a user in installing additional operating systems on their computers. These utilities also allow a user to choose which operating system to boot while a computer is being powered-on or reset. The capability to boot different operating systems on the same computer is often referred to as an OS multi boot or multi booting.

[0009] Having more than one operating system on the same computer is not without its problems. One problem arises when a user installs an application program, such as, for example, a “browser” for the INTERNET, on a PC operating with a first operating system (OS #1). The user sets up communication and user settings for the browser, uses the browser and saves a few bookmarks for interesting sites found while browsing the INTERNET. The user subsequently boots his computer with a second operating system (OS #2), but cannot use the browser since it was installed for OS #1. The user would have to re-install the browser for OS #2 and then set up the communication and user settings for the newly installed browser. The bookmarks for the browser installed for OS #2 would have to be updated to include the bookmarks saved for OS #1.

[0010] If the user operates the browser installed for OS #2, and modifies any settings or bookmarks, then the user would have to boot the computer in OS #1 and manually update the browser's settings and bookmarks to keep the browsers settings consistent between OS #1 and OS #2. This takes time and can lead to mistakes particularly for applications which are far more complicated than a browser. More complicated applications, for example, may be too difficult for a user to integrate in an OS multi boot environment. Accordingly, there is a desire and need to automatically integrate application programs and their settings between multiple operating systems installed in an OS multi boot environment.

[0011] Similar problems arise when a user attempts to coordinate the user interface, settings and preferences of the multiple installed operating systems. Any setting that were changed for OS #1 would have to be manually changed for OS #2 (after a reboot). Likewise, settings that were changed for OS #2 would have to be manually changed for OS #1 (after a reboot). This also takes time and may lead to mistakes particularly for a user unfamiliar with computers. Accordingly, there is a desire and need to automatically integrate the settings and preferences of multiple operating systems installed in an OS multi boot environment.

[0012] The present invention provides a method to automatically integrate application programs and their settings between multiple operating systems installed in an OS multi boot environment.

[0013] The present invention also provides a method to automatically integrate the settings and preferences of multiple operating systems installed in an OS multi boot environment.

[0014] The above and other features and advantages of the invention are achieved by a computer implemented method of monitoring and integrating changes made to a computer system having a plurality of operating systems installed thereon. The method monitors and records changes in accordance with user preferences for a first operating system. When the computer is booted for use with a second operating system, the method integrates into the second operating system and associated programs the changes made during operation of the computer with the first operating system.

[0015] The foregoing and other advantages and features of the invention will become more apparent from the detailed description of the preferred embodiments of the invention given below with reference to the accompanying drawings in which:

[0016] FIG. 1 illustrates the OS multi boot integrator method of one embodiment of the present invention;

[0017] FIG. 2 illustrates an exemplary computer system for implementing the one embodiment of the method of the present invention;

[0018] FIG. 3 illustrates in flowchart form an exemplary OS multi boot integration process performed by a method of the present invention;

[0019] FIG. 4 illustrate an exemplary monitor processing performed by a method of the present invention; and

[0020] FIG. 5 illustrates an exemplary user configuration processing performed by a method of the present invention.

[0021] FIG. 1 illustrates the OS multi boot integrator method 150 of one embodiment of the present invention. As will be described below, the method 150 is preferably operated on a computer system having an OS multi boot capability, that is, the computer system has more than one operating system installed therein and is capable of booting any of the operating systems upon a power-up or reset condition. In addition, the method 150 may also be operated on a computer having one OS that is connected via a network to a second computer with a different OS.

[0022] It is desirable for the method 150 to be initiated as soon as the booted operating system becomes operational and that the method 150 remains running for as long as the system remains on. This may be achieved by any technique available to the OS that has been booted. For example, a computer system booted with WINDOWS 95 could initiate the method 150 from a “startup” group (a startup group contains application programs to be executed every time the OS starts).

[0023] The method 150 includes OS multi boot integration processing 200, monitor processing 300 and user configuration processing 350 tasks (described in detail below with reference to FIGS. 3-5). FIG. 1 shows the three tasks 200, 300, 350 being performed in a parallel manner (i.e., all running at the same time), but it must be noted that tasks 200, 300, 250 can be performed sequentially or in any other manner allowable by the booted OS. In addition, it must be noted that the method 150 does not have to be split into the three identifiable tasks 200, 300, 350 illustrated in FIG. 1 and that any number of tasks can be used to perform the present invention.

[0024] Referring now to FIG. 2, the OS multi boot integrator method 150 of the present invention runs on a programmed general purpose computer system 100. The computer system 100 includes a central processing unit (CPU) 102 that communicates with an input/output (I/O) device 104 over a bus 130. Additional I/O devices 106, 120, 122 are illustrated, but are not necessary. The computer system 100 also memory 108, read only memory (ROM) 110, and may include peripheral devices such as a floppy disk drive 112 and a compact disk (CD) ROM drive 114 which also communicate with the CPU 102 over the bus 130. It must be noted that the exact architecture of the computer system 100 is not important and that any combination of computer compatible devices may be incorporated into the system 100 as long as the OS multi boot integrator method 150 of the present invention can operate on the system 100 as described below with references to FIGS. 3-5. Moreover, the program for CPU 102 which causes it to implement the method 150 of the present invention may be stored in memory 108, ROM 110, CD-ROM 118, floppy disk 116, a hard drive or any other medium capable of storing a program. During execution of the program it will be loaded into the main memory of the CPU (not shown). All of these devices communicate with CPU 102 as is well known in the art.

[0025] The CPU 102 performs any logical and mathematical operations required by the method 150 of the present invention, such as data manipulation and comparisons, as well as other arithmetic and logical functions generally understood by those of ordinary skill in the art. The memory 108 is used to store data and program instructions required to implement the method 150 of the present invention and can be comprised of conventional random access memory (RAM), dynamic random access memory (DRAM), bulk storage memory, or any combination thereof, as generally understood by those of ordinary skill in the art. In addition, the memory 108 will contain at least two installed operating systems allowing the computer system 100 to have a multi boot capability. The I/O devices 104, 106, 120, 122 are responsible for interfacing with an operator of the computer system 100 or with peripheral data devices such as a hard drive or other device (not shown) to receive or distribute data as generally understood by those of ordinary skill in the art. Typical I/O devices include a keyboard, mouse, and display.

[0026] Any conventional technique can be used to install the multiple operating systems into the memory 108. Currently, there exists numerous commercially available utilities for such purposes. These utilities, such as V Communications'SYSTEM COMMANDER, for example, will also provide the capability to selectively boot one of the operating systems out of the memory 108 and into the main memory of the CPU 102 (not shown). Typically, the utilities provide some form of menu or instruction screen to allow a computer user to choose which OS to boot and if the user does not choose an OS to boot, the utility will boot a “default” OS. It must be noted that the technique used to install or boot the operating systems is not important and the invention should not be limited to any specific technique.

[0027] Referring again to FIG. 1, a brief description of the method 150 of the present invention will be provided. A detailed description will follow with references to FIGS. 3-5. To aid in the discussion, “OS #1” will be used to refer to one installed operating system while “OS #2” will be used to refer to a different installed operating system. It must be noted that the method 150 of the present invention will operate regardless of the booted OS.

[0028] Briefly, and presuming that OS #1 has been booted, the monitor processing 300 will record changes made to operating system settings files, user applications, data files and any newly installed or uninstalled application programs. Operating system setting files are files used by the OS to manage the hardware, software and user preferences. An example of a typical operating system settings file is a registry file used by WINDOWS NT and WINDOWS 95. When OS #2 is booted, the OS multi boot integration processing 200 will examine and integrate the changes recorded for OS #1. Meanwhile, the monitor processing 200 will record additional changes made to system settings, data files, etc. for OS #2 (so these changes will eventually be integrated into OS #1). The user configuration processing 350 allows the user to determine the level of integration (i.e., the types of changes to be integrated between the multiple operating systems).

[0029] The changes made for the monitored OS will be recorded in a “record change” file which is accessible by the method 150 of the present invention regardless of the booted OS. As will be described below with reference to FIG. 4, the record change file will include only the information which the user has selected to be monitored. For example, if the user is only interested in whether new applications have been installed, then the record change file will only include information concerning new installations. It may also be desirable for the record change file to include an operating system identifier (OS ID) to determine which operating system has undergone the change. This will prevent changes made under OS #1 from being deleted if OS #1 is rebooted prior to OS # 2 being booted. If there are three or more installed operating systems, for example, the OS ID will be useful to ensure that all of the operating systems are integrated with the recorded changes.

[0030] FIG. 3 illustrates one example of the OS multi boot integration processing 200 performed by the method 150 of the present invention. Presuming OS #1 is currently booted, the processing 200 will examine the change record file (step 202) to determine what changes were recorded by the present invention for OS #2 (and any other installed OS). Once the change record file has been examined, the processing determines whether a new application program was installed (step 204). If no new application program was installed for OS #2, or if the user has chosen not to have newly installed application programs recorded, the processing continues at step 214. If it has been determined that a new application program was installed for OS #2, an application installation routine is initiated (step 206). The application installation routine will alert the user that a new application program was installed for OS #2 and prompt the user if this application program should be installed for OS #1 (step 208). The application installation routine will coordinate the following steps required to properly install and setup the new application program.

[0031] At step 210, it is determined if the user wants to install the new application program. If the user decides not to install the new application program, the processing continues at step 214 to determine if any file changes for OS #2 need to be integrated. If the user wishes to install the new application program, the application program is installed in the same directory as it was installed for OS #2, if the application program allows it, or in a new directory if the application program does not allow a second installation in the same directory (step 212). In addition, any user settings, data files, etc. required by the newly installed application program (for OS #1) will be copied from the settings, data files, etc. saved for OS #2. Thus, the application program will be installed to run on both OS #1 and OS #2 and will also be configured the same. Once the application program has been installed and setup, the processing continues at step 214 to determine if any file changes for OS #2 need to be integrated. It must be noted, that although not shown in FIG. 3, the processing 200 would check the record change file for additional newly installed application programs and loop through steps 204 to 212 to install and integrate them.

[0032] At step 214 it is determined if any “data” file changes made for OS #2 need to be integrated for OS #1. Data files can be application program files such as bookmarks for an INTERNET browser. If no data file changes need to be integrated, or if the user has decided not to integrate data file changes, the processing continues at step 220 to determine if any OS settings file changes need to be integrated. If there were data file changes, the processing determines and modifies any OS specific references so that they reference the current OS (216). That is, any data file change pointing to OS #2 or otherwise setup for OS #2 would have to be verified that they could be suitable for use with OS #1 and then modified to reference OS #1. Once the data file changes are modified for OS #1, they are copied into the appropriate OS #1 data file (step 218). In addition, where possible, the data file it self will be copied into the appropriate directory for OS #1. Once the data file changes have been integrated, the processing continues at step 220 to determine if any OS settings file changes need to be integrated. It must be noted, that although not shown in FIG. 3, the processing 200 would check the record change file for additional data file changes and loop through steps 214 to 218 to integrate them.

[0033] At step 220, it is determined if any OS settings file changes made for OS #2 need to be integrated for OS #1. If no OS settings file changes need to be integrated, or if the user has decided not to integrate OS settings file changes, the processing 200 completes. If there were OS settings file changes, the processing determines and modifies any OS specific references so that they reference the current OS (step 222). That is, any OS settings file changes pointing to OS #2 or otherwise setup for OS #2 would have to be verified that they could be suitable for use with OS #1 and then modified to reference OS #1. Once the OS settings file changes are modified for OS #1, they are merged into the appropriate OS #1 settings file (step 224). It must be noted, that although not shown in FIG. 3, the processing 200 would check the record change file for additional OS settings file changes and loop through steps 220 to 224 to integrate them. At this point, the OS multi boot integration processing 200 is completed. It must be noted that the processing 200 could be configured to prompt the user every time a change is going to be integrated if so desired.

[0034] FIG. 4 illustrates one example of the monitor processing 300 performed by the method 150 of the present invention. Presuming OS #1 is currently booted, the processing 300 will continuously monitor and record changes so that they may be integrated into OS #2 (and any other installed OS). At step 302, the monitor processing 300 determines what should be monitored by examining user monitor settings (described below with reference to FIG. 5). As stated earlier, the user decides the level of integration. The user's decision is stored away in a user monitor settings file. Depending upon the user monitor settings, the processing continues to steps 304, 306, 308. The three steps 304, 306, 308 are illustrated as being initiated in a parallel manner (i.e., all running at the same time), but it must be noted that they can be initiated sequentially or in any other manner allowable by the booted OS. In addition, it must be noted that the processing 300 does not have to utilize the three steps 304, 306, 308 as illustrated in FIG. 4 and that any number of steps can be used to properly monitor changes in OS settings files, data files and newly installed application programs.

[0035] In step 304, the processing 300 watches for changes in the OS settings files. Changes are determined by examining and storing the current settings for OS #1 upon initiation of the monitor processing 300. In addition, the user monitor settings are examined to determine if any specific OS setting files should or should not be monitored. If an OS settings file that the user wishes to be monitored is changed, these changes are recorded and subsequently placed into the change record file (step 310).

[0036] In step 306, the processing 300 watches for changes in the data files. Changes are determined by examining and storing the current settings for OS #1 upon initiation of the monitor processing 300. In addition, the user monitor settings are examined to determine if any specific data files should or should not be monitored. If a data file that the user wishes to be monitored is changed, these changes are recorded and subsequently placed into the change record file (step 310).

[0037] In step 306, the processing 300 watches for newly installed application programs. Newly installed application programs are determined by examining and storing the current application programs installed for OS #1 upon initiation of the monitor processing 300. If a new application program is installed, the appropriate information is recorded and subsequently stored into the change record file (step 310). It must be noted that the monitor processing 300 can prompt the user every time a change has been detected. This gives the user a chance to integrate changes that were not previously desired and a chance to not integrate changes that were requested to be monitored.

[0038] FIG. 5 illustrates one example of the user configuration processing 350 performed by the method 150 of the present invention. Presuming OS #1 is currently booted, the processing 350 will allow the user to decide the level of integration between OS #1 and the other the installed operating systems. The processing 350 begins by allowing the user to enter a configuration mode (step 352). This can be accomplished by any technique. For example, the processing 350 may be setup to detect a specific character sequence (via keyboard entry) as an indication that the user wishes to enter the configuration mode. In addition, if the OS multi boot integrator method 150 of the present invention utilizes graphical user interface (GUI), a window or menu option can be provided and used to input when the user wishes to enter the configuration mode.

[0039] Upon detection that the user wishes to enter the configuration mode (step 352), information regarding the level of integration and monitoring the user desires is input and stored into the user monitor settings file (step 354). As noted earlier, the user decides what information should be integrated and thus, monitored. The user can decide to integrate all changes, some changes or no changes at all. The user can decide, for example, to integrate all changes to OS settings files, while choosing not to integrate newly installed applications.

[0040] For example, the user can broadly decide whether to integrate new application program installations, changes in the OS settings files and data files. Once this decision is made, the user can decide whether there are specific OS settings files or data files to monitor and integrate (or not to integrate). In addition, the user configuration processing 350 can be configured to allow the user to control prompts and displayed information. In addition, the processing 350 can utilize a “default” integration level allowing the user to set an integration level that has already been setup. As stated above with reference to FIG. 4, the information stored in the user monitor settings file is used by the monitor processing 300 which monitors and records only the information requested by the user.

[0041] It must be noted that the OS multi boot integrator method 150 of the present invention can be utilized on a computer having one OS that is connected via a network to a second computer with a different OS. For example, a user logs onto a networked computer running OS #1 and the method 150 of the present invention. The user installs an application program and then logs off. The installation is recorded by the present invention (as described above with reference to FIG. 4). The user subsequently logs onto a second computer on the same network executing the present invention, but running OS #2. The method 150 detects the newly installed application program and prompts the user if it should be installed (as described above with reference to FIG. 3).

[0042] It must be noted that the exact information saved and recorded by the present invention is dependent upon OS and type of applications being installed which may vary. In addition, it must be noted that the present invention can be used to monitor and integrate additional changes to a computer system, such the as deletion or unistallation of program application, and is not to be limited data files, OS settings files and newly installed application programs. It must be noted that the present invention can be setup to confirm selections and responses made by the user if so desired.

[0043] It must be noted that the present invention is implemented as a program which gets executed on a computer system. The invention can be written in different computer languages for different computer systems. The present invention can be stored on a hard drive, floppy disc, CD-ROM or other permanent or semi-permanent storage medium. The program embodying the present invention can also be divided into program code segments, downloaded, for example, from a server computer or transmitted as a data signal embodied in a carrier wave as is known in the art.

[0044] While the invention has been described in detail in connection with the preferred embodiments known at the time, it should be readily understood that the invention is not limited to such disclosed embodiments. Rather, the invention can be modified to incorporate any number of variations, alterations, substitutions or equivalent arrangements not heretofore described, but which are commensurate with the spirit and scope of the invention. Accordingly, the invention is not to be seen as limited by the foregoing description, but is only limited by the scope of the appended claims.