Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1999-11-10
2003-10-07
Cabeca, John (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C345S215000, C345S215000, C707S793000, C711S161000
Reexamination Certificate
active
06630946
ABSTRACT:
BACKGROUND
1. Field of the Invention
The invention relates generally to computer systems that concurrently execute plural application programs on a preemptive multitasking basis.
The invention is directed more specifically to multitasking systems wherein the execution of a given application program may become frozen or may otherwise halt unexpectedly and for which it is desirable revive the frozen/-halted application program at least partially so as to enable nonvolatile saving of work product produced so far by the frozen program. The invention is directed even more specifically to the problem of how to appropriately save work product items of a just-revived application program.
2a. Cross Reference to Related Patents
The disclosures of the following U.S. patents are incorporated herein by reference:
(A) U.S. Pat. No. 5,911,060 issued Jun. 8, 1999 to Scott Elliott, and entitled, COMPUTER METHOD AND APPARATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM; and
(B) U.S. Pat. No. 5,974,249 issued Oct. 26, 1999 to Scott Elliott et al, and entitled, ZERO FOOTPRINT METHOD AND APPARATUS FOR EXPANDING ALLOCATED MEMORY SPACE OF A PROCESS USING A VIRTUAL MEMORY AREA.
2b. Cross Reference to Co-Pending Patent Applications
The disclosures of the following Co-pending, U.S. patent applications (each owned by the owner of the present application) are incorporated herein by reference:
(A) U.S. Ser. No. 08/938,204, filed Sep. 26, 1997, by inventor Scott Elliott and originally entitled COMPUTER METHOD AND APPARATUS FOR ACCESSING AN APPLICATION PROGRAM WHICH HAS BECOME UNRESPONSIVE TO MESSAGES FROM THE OPERATING SYSTEM OR INCURRED A FATAL ERROR, which application later issued as U.S. Pat. No. 6,009,258; and
(B) U.S. Ser. No. 09/275,171, filed Mar. 24, 1999 as a divisional of U.S. Ser. No. 08/937,629, filed Sep. 26, 1997 by inventor Scott Elliott and originally entitled COMPUTER METHOD AND APPARATUS FOR UNFREEZING AN APPARENTLY FROZEN APPLICATION PROGRAM BEING EXECUTED UNDER CONTROL OF AN OPERATING SYSTEM.
2c. Copyright Notice
This application includes one or more listings of computer programs. The assignee of the present application claims certain copyrights in said computer program listings. The assignee has no objection, however, to the reproduction by others of these listings if such reproduction is for the sole purpose of studying it to understand the invention. The assignee reserves all other copyrights in said program listings including the right to reproduce the corresponding computer programs in machine executable form.
3. Description of Related Art
Multitasking computer systems may be characterized as those that allow multiple programs to execute in overlapping fashion so that it appears the programs are all running at the same time.
Preemptive multitasking systems may be characterized as those in which an operating system (OS) has supervisory control over the concurrently executing programs and the OS limits the length of time that each given application program has for using system resources such as a CPU (Central Processing Unit) or other data processing means.
Examples of preemptive multitasking OS's include Microsoft Windows95™, Microsoft Windows98™ and Microsoft Windows NT™, all of which are available from Microsoft Corporation of Redmond, Wash. These OS's also permit multi-threaded execution of programs. In multi-threaded execution, a program begins executing as a first, main thread and optionally generates ancillary threads that run concurrently and interact with one another through exchanges of semaphores.
During execution, a given application program may encounter an unexpected problem which halts its normal execution either in a main thread or an ancillary thread. Examples of causes for such problems include those in which: (a) the program attempts to access restricted (privileged) or unavailable areas of memory areas, (b) the program makes calls to unavailable system functions or services without the ability to handle such unavailability, (c) the program jumps into a nonsense stream of execution code, (d) the program invokes a no-time-out wait for an event that never happens, (e) the program enters into a deadlock embrace, and so forth. This is a nonexhaustive list of possible causes.
When such execution-halting events occur, artisans sometimes refer to the halted program as being ‘stuck’ or ‘frozen’ or ‘crashed’ or as having encountered a ‘fatal error’. Different flavors of these terms are sometimes associated to one class of cause as opposed to another. Here, the terminology ‘frozen application’ will be generically applied to any and all situations in which the user of a given application program reasonably believes the program is stuck and therefore prevents saving of work product irrespective of the exact cause and irrespective of whether that belief is accurate in fact.
The end-user (e.g., novice user) of a computer system typically doesn't care what the specific cause is that has led him or her to believe that they can no longer save work product. Such a user instead generally recognizes the ‘frozen’ condition as an apparently sudden refusal by the given application program to respond appropriately to keyboard strokes or to mouse clicks or to other user interface interactions (which interactions can include voice commands, hand gestures, and so forth).
The presence of a frozen program does not generally pose a major problem to the overall operations of a preemptive multitasking system. In such systems, other, concurrently-executing application programs can continue to run in normal fashion even though a given application has actually become frozen or has actually crashed (as opposed to situations where the program is fine and the user merely believes it has become stuck). The end-user continues to have access to operating system services and to the resources of non-frozen application programs. (For example, in a Windows95/98™ environment the user may hit the Alt-Tab key combination to switch to the next task.) The user may choose to simply end the tasking of the apparently-frozen program and to thereafter restart the program afresh from its basic start-up state.
Sometimes, this close-and-restart_afresh option is not an attractive one for the end-user. It may be that the end-user did not, or believes he did not, save to nonvolatile memory (e.g., to hard disk), a segment of work that he/she last performed with the application just before the given application became frozen. Closing-and-restarting the frozen program afresh may mean that the unsaved work may be lost forever. Many hours of work may have to be painfully redone to reconstruct the state of the application just before it apparently became frozen. In some instances, the pre-freeze state of the application may represent non-replicatable work product such as data that had just been captured and/or transformed in real-time.
To remedy this predicament, various un-freezing techniques have been developed. These try to revive the frozen/crashed program at least to a sufficient level such that unsaved work product may be accessed and saved either wholly or partially. Examples of such un-freezing techniques include those disclosed in the above-cited patents and patent applications.
No currently known revival technique is 100% effective for all possible forms of application program. One may make an analogy to attempts to revive a human patient by CPR (cardio-pulmonary resuscitation) after the patient suffers a cardiac arrest. In some cases, the patient is fully revived. In other cases, the patient is revived but still suffers from serious complications. And in yet further cases, even heroic attempts to revive the patient regretfully prove unsuccessful. In so far as reviving a frozen application program is concerned, the end goal is not to keep the application program alive and working as long as possible, but rather to keep it alive long enough so that vital, but still unsaved, work product can be saved.
One un-freezing technique tests the apparen
Carr K. Jeffrey Percy
Elliott Scott C.
Bautista X. L.
Cabeca John
Fliesler Dubb Meyer & Lovejoy LLP
Symantec Corporation
LandOfFree
Methods for automatically locating data-containing windows... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods for automatically locating data-containing windows..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods for automatically locating data-containing windows... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3129146