Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration
Reexamination Certificate
1995-11-13
2002-08-06
Banankhah, Majid A. (Department: 2151)
Electrical computers and digital processing systems: support
Digital data processing system initialization or configuration
C713S100000
Reexamination Certificate
active
06430685
ABSTRACT:
CROSS REFERENCE TO RELATED PATENT APPLICATIONS
This patent application is related to U.S. Ser. No. 08/019,600 filed concurrently herewith, for a “A Method and Apparatus for Overriding Resource Maps in a Computer System” by Dean Yu and Chris Derossi, which is hereby incorporated by reference.
DOCUMENTS INCORPORATED BY REFERENCE
The following documents are herein incorporated by reference: Inside the
Macintosh
, Volume IV, Addision-Wesley Publishing Company, Inc. (1987); and
Apple Macintosh Family Hardware Reference
, Addison-Wesley Publishing Company, Inc. (1988).
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to computer operating system boot sequences and initialization methods and apparatus.
2. Summary of the Related Technology
System Software as it's developed today is tied very closely with the particular Macintosh machines that it supports. In some cases, this makes a lot of sense since the system software has to interface with the hardware. In other cases, though, this is an artificial limitation. For example, System 6.0.5 doesn't support the Macintosh Classic because the Classic was released after System 6.0.5. However, since the Classic is so similar to previous machines, namely the Macintosh SE, System 6.0.5 would work just fine if it weren't for the check made by the boot code that prevents it from loading.
Frequently there will be changes to the hardware which require changes to the system software. In many cases, the changes needed in the system software are minor compared to the task of developing and releasing an entirely new version. But, in the past, there was no way to provide incremental changes without releasing a whole new version of system software. Thus, each new set of machines required a complete and separate software development effort.
Hardware support releases of system software are released later, and have higher version numbers than the version on which the release was based. Customers perceive that the hardware support version is superior because it has a higher version number. Customers then want the newer version, even if they do not have one of the new machines that require the new software. Exacerbating the matter is the fact that hardware support releases often supply additional functionality, causing developers and customers to want the new release for all machines. Hardware support features are required by new machines, thus new software releases are required to implement small human interface elements. For example, System 6.0.5 could not ship with Classic because “About the Finder . . .” would have called it a Macintosh SE and given it the wrong icon.
In the past, operating systems were developed with a particular processor and hardware environment in mind. System designers tailored the operating system to run on a particular processor and hardware configuration. While it has been considered good programming design methodology to take advantage of the underlying hardware architecture, the operating system was limited to the particular processor and hardware environment for which it was written. The operating systems were not portable. This was so because the operating system software had to interface with and control the computer system hardware. Although such operating systems may have operated satisfactorily on one particular type of processor, they would not run on another type of processor. As a result, prior operating systems were inflexible.
In the past, an entirely new version of the operating system software usually had to be developed for each new type machine. An individual development effort was required to code and release a new version of the operating system whenever a new processor or hardware configuration change was implemented. Such development efforts were usually very expensive and time consuming.
In order for the operating system to accommodate different hardware environments, system designers were usually forced to release a new version of the operating system when new hardware platforms became available. Many times, it did not take long for the latest version of an operating system to be upstaged by a newer version generated to accommodate a new hardware configuration. As an undesirable result of this, different versions of the same operating systems would proliferate.
Even in the absence of new hardware platforms using new machine designs, there were other changes in hardware that required changes to the system software. In many cases, the changes to the hardware were relatively minor compared to the task of developing and releasing an entirely new version of the operating system software. Nevertheless, these ad hoc efforts at system design negatively impacted engineering resources, quality control, marketing, and profitability. The proliferation of different versions of an operating system created significant difficulties for those attending to version control and documentation. The problems normally encountered in debugging software and beta testing were greatly exacerbated by the proliferation of different versions of operating system software.
In the past, attempts have been made to extend the functionality of an operating system software release by patching or implementing new functions. These functionally extensible patch files were sometimes referred to as “extensions.” For example, to add new functionality that allows an application program to play movies within a document, an attempt might be made to extend the system software functionality with an extension file. Extensions were sometimes referred to as “INIT” files, because of their file type in the Macintosh computer environment provided by Apple Computer, Inc. Extension files were patch files that relied on the system boot routine to bring up the system from a power on reset state to a fully operational state.
Patch files contained changes to system software that were called in and executed to augment system software after system initialization by the boot routine. These patch files would change code in the operating system to accommodate new machines and new hardware configurations, and to update system software in order to fix problems or add functionality after the release of a particular version of an operating system.
In addition to the above described problems, application programs that were written to run on a particular hardware platform might not run on later versions of the hardware, because the application program might not be compatible with the new version of the operating system required for a new hardware configuration different from that on which the application program was originally designed to run.
Further problems were created because the way that system programmers dealt with the inherent incompatibility between most underlying hardware architecture sometimes had the undesirable result of imposing artificial limitations on the software. Typically, a status check of the hardware configuration would be performed by the operating system during the system start-up, or boot procedure. Oftentimes, an operating system designed to run on a first hardware platform would be prevented from loading onto a second slightly different platform, when the status check determined that the hardware platform was not the one that the operating system expected. The system would halt, even though the operating system might be capable of actually running on that slightly different hardware platform. Thus, the artificial barrier created by the common practice of performing such status checks would make operating systems that were designed to run on a particular hardware platform incompatible with any different hardware platform, regardless of the similarities between the two hardware platforms. Nevertheless, such status checks were often considered to be a necessity in order to prevent computer system crashes, because of the lack of portability between most hardware platforms.
Customers were often confused when numerous ad hoc versions of system software appeared on the market with higher version numb
Derossi Christopher S.
Yu Dean T.
Apple Computer Inc.
Banankhah Majid A.
Blakely & Sokoloff, Taylor & Zafman
LandOfFree
Method and apparatus for enabling a computer system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for enabling a computer system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for enabling a computer system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2924967