Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration – Loading initialization program
Reexamination Certificate
1996-01-26
2001-02-20
Courtenay, III, St. John (Department: 2755)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
Loading initialization program
C710S200000
Reexamination Certificate
active
06192471
ABSTRACT:
FIELD OF INVENTION
This invention relates to computer system utility programs. More specifically, this invention relates to an apparatus and method for creating an operating environment for operating computer system utility programs.
BACKGROUND OF THE INVENTION
Various utility programs, for example some diagnostic utilities, are fully and correctly operable only when all aspects of the computing environment are known and all system resources are available without restriction. For example, a memory diagnostic utility typically tests memory by writing bit patterns to all or a substantial proportion of memory, reading back the written bit patterns and verifying that the bit patterns read are the same as the bit patterns that were written. However, a computer system typically operates under control of an operating system, a master set of programs which controls a computer system and, thus, restricts write access to various locations in memory.
An operating system which is activated by bootstrap loading from a disk drive may be called a native operating system. The file system of the master set of programs making up the native operating system may be called a native file system.
Operating systems, such as Windows™ and OS/2™, provide a known environment and make system resources available by establishing a virtual environment for running utilities. The virtual environment invoked is typically called a DOS box. Unfortunately, DOS boxes are a virtual environment and do not furnish a control environment for the physical computing environment. Rather than furnishing access to the entire physical system, an operating system often interprets or ignores various instructions that are executed by the utility.
One example of a limitation of DOS boxes arises in the Windows NT™ operating system. Windows™ traps input and output (I/O) operations. The Windows™ operating system also is known to restrict the I/O operations of utility programs.
Conventional methods for performing utility functions without interference from the operating system include bootstrap loading a special operating system that is established for the purpose of running utility functions. In other systems the operating system is established in conjunction with utility programs so that a utility is allowed access to particular system resources. A computer system manufacturer can address also some of these problems by creating a separate partition on the disk drive, loading the utilities onto the separate partition and encrypting the utility programs so that the utility programs cannot be executed by a casual user.
Another conventional technique for establishing a utility operating environment which avoids these restrictions involves creating a separate bootable partition on a disk drive and subdividing the disk drive storage area into smaller units allocated to specific tasks, including the utility operating environment tasks. However, this technique requires inflexible and constant reservation of portions of a user's physical disk drive.
Several problems arise from this unrelenting reservation of storage resources. First, if a computer user repartitions and reformats the storage system without properly re-establishing the utility environment, the utility programs cannot be reinstalled without unloading all data on the storage system and appropriately reestablishing the proper partitioning.
A second problem arises if a computer system user accidentally or inadvertently deletes the program files which make up the utilities. Files which make up the utility partition are typically large files with names that are obscure to the computer user. A computer user running low on storage resources may delete the large, space-consuming, obscurely-named utility files without understanding their importance. Restoring deleted utility files is difficult and expensive because the files often include multiple megabytes of information which must be written onto a transfer media such as multiple floppy disks. The transfer media and the time needed to write appropriate files to the media are expensive for a manufacturer providing the programmed media and for the computer user. Furthermore, the utility files are typically restored by transferring information on multiple floppy disks, perhaps a dozen disks, to a hard disk drive, a very time consuming task to the computer user.
A third problem is that the computer user cannot easily make use of the disk drive space used for the utility environment in an emergency situation.
What is needed is a technique for furnishing a known operating environment in which all resources of a computer system are fully accessible and the storage resources for implementing the operating environment can be removed and reinstalled easily upon user command.
SUMMARY OF THE INVENTION
In accordance with the present invention, a system which builds an operating system-independent environment for executing utility programs is created by establishing a virtual drive that resides on a physical disk drive within the native file system of a native operating system. A virtual drive is a set of files on a physical disk drive that is configured to emulate a physical disk drive. The virtual drive can be deleted by a computer user and similarly can be re-established by the computer user. The virtual drive is bootable and activates an operating system that makes all system resources accessible to the utility programs and also allows the computer user to use the disk space that is allocated for the virtual drive, if desired.
In accordance with one embodiment of the present invention, a method of executing a utility program on a computer system includes steps of reserving a region of a native file system for usage as a virtual disk drive and executing a virtual disk drive reboot command that designates the virtual disk drive as a bootstrap device. The reboot command invokes an interceptor in response to the reboot command. The interceptor relates a location on the virtual disk drive to a location in the native file system and intercepts disk accesses to the virtual disk drive, directing a disk access location to a native file system location.
In accordance with a second embodiment of the present invention, a method of executing a utility program on a computer system includes steps of reserving a region of a physical disk drive for usage as a virtual disk drive, bootstrap loading an operating system which designates the virtual disk drive as a bootstrap device and intercepting disk accesses to the virtual disk drive and thereby directing a disk access location to a corresponding physical disk drive location.
In accordance with a third embodiment of the present invention, a utility program operating on a computer system having a processor, a memory and a hard disk drive includes a virtual drive reservation routine which reserves a region of the hard disk drive as a virtual disk drive, an interceptor which intercepts a disk access directed to a location on the virtual disk drive and directs the disk access to a corresponding location on the physical disk drive and a reboot command which requests the virtual disk drive as a bootstrap device. A bootstrap routine responds to the reboot command by invoking the interceptor.
Many advantages are attained by the methods and programs discussed hereinabove. One advantage is that utility programs have access to all system resources without hindrance from an overlying native operating system. Another advantage is that the native operating system and the virtual drive are mutually independent and noninteracting so that performance of the active operating system is not influenced by the inactive operating system. A further advantage is that the virtual drive appears to a computer user simply as a single file. Multiple obscurely-named utility files are transparent to the user.
REFERENCES:
patent: 5128995 (1992-07-01), Arnold et al.
patent: 5131089 (1992-07-01), Cole
patent: 5153577 (1992-10-01), Mackey et al.
patent: 5371871 (1994-12-01), Spilo et al.
patent: 5754821 (1998-05-01), Cripe et al.
patent:
Overfield Anthony L.
Pearce John J.
Courtenay III St. John
Dell USA LP
Koestner Ken J.
Skjerven Morrill & MacPherson LLP
LandOfFree
Operating system independent system for running utility... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Operating system independent system for running utility..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Operating system independent system for running utility... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2588716