Patent Application
20070234086
When a user attempts to shut down an operating system, such as the Windows XP brand operating system by Microsoft Corporation of Redmond, Wash. or the Mac OS X operating system by Apple Computer, Inc. of Cupertino, Calif., certain applications possess the ability to cancel or indefinitely block shut down. When shut down is temporarily blocked by other applications, the user experience can be unpleasant as the user may not be provided with any system generated indication of what is going on and shut down is obviously delayed.
As an example, in the Windows XP brand operating system, when a user has an unsaved document in an application such as Microsoft Word and attempts to shut down his computer, Word will display a dialog box prompting the user as to whether he desires to save the document. Assuming that Word is hung or not responding, Windows then occludes the first dialog box with a second dialog box asking the user whether he would like to end the application now (immediately) and lose any unsaved data. If the user chooses to end the application now the application closes and another running application, if one exists, will generate a similar pair of dialogs until all applications have been terminated. If the user chooses not to end the application now, the application continues closing on its own. Once completed, if the user has other running applications, the process repeats itself for each application until all the applications close. Then the system finally shuts down. From the aforementioned description, shutting down the operating system can be frustrating, tedious and most certainly longer than desired. Additionally, the applications that block the operating system shut down often do not explain to the user what task the application is currently performing or why the application is blocking shut down.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in any way to limit the scope of the claimed subject matter.
Aspects relate to providing a scheme and graphical user interface for shutting down an operating system. Some aspects include a computer readable medium storing computer-executable instructions for performing a method for shutting down an operating system. In certain aspects, the method includes receiving a command to initiate operating system shut down, and determining an application that is delaying the shut down. The application may provide delay information, for example, a message describing a non-interruptible task currently being performed (e.g., burning a CD). After a system shut down has been initiated, a list of running applications may be displayed, along with delay information provided by the applications for delaying the system shut down, thus allowing the user to make an informed choice whether to continue with the operating system shut down.
Certain other aspects relate to setting delay information associated with an application. An application may set a delay reason by communicating with the operating system prior to performing a task that should not be interrupted by a system shut down. After the completion of the task, the application may then remove the delay information previously set, thus configuring the operating system not to delay any subsequent system shut down based on this task.
In other aspects, a graphical user interface is generated for assisting the user in shutting down the operating system. The graphical user interface according to some aspects includes an application region identifying at least one instance of an application that delays shut down, along with delay information informing the user why the application is delaying shut down. Other aspects include a shut down object, which responsive to selection causes the operating system to terminate some or all running applications, and a cancel object, which responsive to selection causes the operating system to cancel shut down.
The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the accompanying drawings, which are included by way of example, and not by way of limitation and in which like reference numerals indicate similar elements.
In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.
Illustrative Operating Environment
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as ROM 131 and RAM 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like is presumed, and the system can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Any of various conventional web browsers can be used to display and manipulate data on web pages.
Illustrative Aspects
The following aspects will focus on a Windows based operating system. It will be understood, however, that aspects of the invention will apply similarly to other operating systems including, but not limited to, Mac and Linux based operating systems.
There are two types of GUI applications, those that can have a top level window and those that cannot. In a computer running the Windows XP brand operating system an application that has a top level window is an application that is capable of being represented by a button in the task bar, and an application that does not have a top level window is an application that is not typically represented by a button in the task bar. In the Windows XP brand operating system, an application can set a visibility flag, and if the flag is set to false, the window is considered “hidden;” a hidden window can never be displayed on the desktop and thus cannot have a visible top level window. Specific examples of applications in the Windows XP brand operating system that do not have a top level window include Windows services applications such as the Windows Search Service. Applications which do not have top level windows may be thought of as transparent to the user in that they are running in the background unnoticed. A non GUI application is a command line or console application, which cannot make use of the operating system APIs that allow applications to provide the UI features commonly associated with the operating system such as buttons, scroll bars, multiple windows, formatted text, etc., found in Windows XP brand operating system. Also, the non-GUI application cannot be represented in the task bar in a Windows XP brand operating system.
If no GUI applications are running (step 220: no), for example if the user has closed all the open applications 135 prior to initiating shut down, the operating system proceeds to automatically terminate the remaining running non GUI applications. In step 225 a system message requesting shut down is sent to all running non-GUI applications, if any. If there were any running non GUI applications (e.g., command line applications), then they are terminated in step 275. According to one illustrative aspect, the operating system may wait up to twenty seconds and then terminate all non GUI applications irrespective of whether they responded to the request. This allows command line applications, which assent to the request, to save any necessary data and perform other cleanup as necessary. In one aspect with multiple running non GUI applications, a system message may be sent to a first running non GUI application. The first non-running GUI application will be shut down after receiving a response assenting to shut down in a predetermined time period (e.g., twenty seconds) or after the predetermined time period has elapsed. This sequence can be repeated for each running non GUI application until all are terminated. Alternatively, the system message can be sent to each running non GUI application in parallel and the operating system, if it has received a positive response from each running non GUI application within a predetermined time period or after the predetermined time period has elapsed, may commence termination of all applications. According to another illustrative aspect, step 225 may be eliminated such that all running non GUI applications are terminated in step 275. Next, shut down continues in step 290 until completion. The above sequence of steps allows the operating system to automatically terminate any running non GUI applications.
If at least one GUI application is still running (step 220: yes) then in step 230 the operating system 134 sends one of the running GUI applications a system message (e.g., WM_QUERYENDSESSION in a Windows XP environment). The system message indicates to the application that a system shut down operation has been requested and requests the application to shut down. If there are multiple running GUI applications, the operating system may choose the order by which the applications will be processed, that is which application will first receive the system message. Schemes for deciding which applications to process first include: 1) starting with the application on top of the Z-order, 2) which open application is most likely to block or veto shut down or 3) any other heuristic associated with the applications. APIs exist in Windows brand operating system, which may be utilized to formulate a desired heuristic. In an alternative aspect, an API can be provided which allows the applications to set the order in which they wish to shut down such that shut down is carried out accordingly.
While this description discusses aspects involving sending the system message requesting shut down to applications serially in this scheme and processing each application accordingly, it will be understood that in other aspects the system message may be sent to each running GUI application contemporaneously and the applications may be processed based on the order in which they respond to the request or each application may be processed as soon their response to the system message is received.
Next in step 235, the operating system 134 determines whether the GUI application has vetoed shut down by negatively responding to the system shut down request, blocked shut down by not responding to the request, or accepted shut down by responding positively to the shut down request. If the application positively responds to the shut down request (an “Accept” response to step 235), then in step 240, the operating system 134 terminates the application and control returns to step 220 to process any other running applications 135.
If the application does not respond to the request and is blocking shut down (a “block” response to step 235), then in step 245 the operating system 134 determines whether the application is hung or if the application is purposefully not responding to the shut down request. An application is hung when the application has failed to respond to any system messages within a predefined period of time. An illustrative time period is five seconds. In an illustrative implementation using a Windows XP based operating system, the operating system determines whether the application is hung using the IsHungAppWindow( ) API. The API monitors whether the operating system 134 has received responses to any system messages in the last five seconds. If an application is hung, then the system terminates the application in step 240 and control returns to step 220.
Some applications 135 will respond to a shut down request almost immediately while others may take several seconds, and yet others may purposefully not respond as they continue with other data processing or the like. Applications 135 may want to conclude processing before assenting to shut down. For example, enterprise software applications, OneNote (by Microsoft Corporation of Redmond, Washington) and other applications which automatically save data to a network server before exiting a network may take two to three seconds to respond to a system message requesting shut down. Five seconds or a time period consistent with the amount of time it takes most applications under typical operation to respond to the system message allows most applications to be terminated normally leaving only those applications which are hung or which have purposefully not responded to the shut down request. An application may not respond to a shut down request, that is block shut down, because additional data processing may still need to be performed or for other reasons. Applications 135 generally block when they know they will respond eventually, but are not ready to respond yet. For example, if Microsoft Word or Notepad have unsaved data and are asked to shut down, they may block shut down because they would like the user to indicate whether she would like to save the data. Word and Notepad know that they will respond “OK to shut down” eventually, but only after the user has indicated what she would like to do with the unsaved data.
If an application is not hung (a “no” response in step 245) or the application vetoes the shut down request (a “veto” response) in step 235, then the application is delaying shut down. In response to a “no” response in step 245 or a “veto” response in step 235, the operating system 134 determines whether the GUI application has any visible top level windows in step 250. An application may veto a shut down request for any reason it likes such as that it requires more time to complete processing such as when the application is performing an activity in the “real world” that cannot be interrupted. For example, when a CD-burning application is in the middle of writing to a CD, it cannot be interrupted. If interruption were allowed, the CD would be rendered useless. Consequently, a CD-burning application would typically veto shut down in this case. An application being used to drive a mechanical precision tool in the middle of a complex, non-interruptible operation might also veto shut down for the same reason.
If the application has no visible top level windows, then the operating system 134 may determine if the application has registered delay information, such as, for example, a delay reason string, to block the operating system shut down in step 255. In certain aspects, operating system APIs may be provided to allow applications to proactively indicate that shut down should be delayed because the application is performing a task that ought not to be interrupted by a system shut down request. The application may provide a delay reason string to provide more information about a task currently being performed by the application or a current application state. In one possible operating system API, an application may register a string value to be presented to the user after a shut down request is initiated, allowing the user to decide whether to continue the system shut down. For example, a CD-burning application may register a delay reason string stating, “A CD burn is in progress,” or a media center application may register a reason string stating, “A TV show is being recorded.” Both GUI applications with top level windows and GUI applications without top level windows may register reason strings to explain why they are delaying operating system shut down. While the delay information is often referred to as “reason strings” or “delay reason strings,” aspects of the present disclosure also support displaying non-strings. For example, a task status bar, progress chart, or other graphic and/or image may be displayed instead of a text string.
In step 250, if the application has a top level window, then a blocking (and vetoed) application user interface (UI) is displayed in step 260. An illustrative blocking (and vetoed) application UI is shown in
If the operating system 134 determines in step 250 that an application has a visible top level window, or determines in step 255 that the application has submitted a delay reason string, then the blocking (and vetoed) application user interface (UI) is displayed in step 260 for that application. According to one aspect, the blocked (and vetoed) application UI takes up a full display screen. With a full screen UI, the display is less cluttered than with existing blocking application Uls in the Windows XP brand operating system and the Mac OS X brand operating system. In Windows XP, in response to a shut down command a blocking application UI including a dialog box is displayed, which overlays the blocking application window and the remainder of the windows in the Z-order on the user's desktop. By removing this clutter, the user experience may be enhanced as the user will be less confused and able to clearly focus on the blocked application. Although a full screen UI may be advantageous, a partial screen UI is considered to be appropriate as well.
An illustrative full screen UI is shown in
After the UI is displayed, the system waits for the user to select the “Cancel” button or “Shut down Now” button in step 270. If the user selects the “Shut down Now” button, in step 280 the operating system terminates all remaining running applications including the subject GUI application irrespective of whether any application may block or veto shut down and without saving any data. Although not shown, the UI may include a message that indicates that selection of the “Shut down Now” command will cause all unsaved data to be lost. Thereafter, the shut down process continues until completion in step 290. In response to the “Shut down Now” command, all GUI applications can be instantly terminated and all non GUI (command line) applications can be informed shut down is underway and be terminated if they do not immediately initiate shut down. The “Shut down Now” button allows the user to automatically force shut down of all applications with a single click or selection avoiding the need to individually shut down each application. This may reduce user frustration and simplify the shut down operation for many users. If the user selects the “Cancel” button in step 270, in step 295 the operating system cancels shut down and returns the UI to the shell, e.g., the Windows desktop in a Windows based operating system.
Ultimately before the completion of steps 250, 255, 260 and 270, a blocking application may send a response to the shut down request. In this instance, system operation is interrupted and if the application assents to application shut down, control shifts to step 240 where the application is terminated or if the application vetoes the shut down request, the process continues or alternatively, control could return to step 235.
Nearly all the applications that a user may be concerned with, primarily those with unsaved data, have top-level windows. By automatically terminating non GUI applications and GUI applications that do not have top-level windows and have not registered a delay reason, the number of blocking applications that are brought to the attention of the user can be significantly reduced. As such, the time required for system shut down and the associated user aggravation and frustration may be reduced.
In step 520, the application receives a shut down request, for example, a WM_QUERYENDSESSION message in a Windows XP or Windows Vista environment. The shut down request indicates to the application that a system shut down operation has been requested and requests the application to shut down. Certain applications may have a shut down request handler, for example, a WM_QUERYENDSESSION message handler, designed to execute code in response to a shut down request and/or to respond to the request. In this example, in the optional step 530, the shut down request handler of the application issues a delay reason query to retrieve a previously submitted delay reason string, if one is currently registered for this application. The delay reason query may be implemented, for example, with an operating system API that returns a string value corresponding to the currently registered delay reason string for the application. By examining the results of the delay reason query, the application may determine that it has no currently registered delay reason, or alternatively that it has an outdated delay reason that no longer accurately describes the currently executing task. Thus, in step 540, the shut down request handler may update this information, for example, by registering a new delay reason by building and passing in a reason string value to the operating system API. Thus, the application may change, by registering or un-registering delay reason strings, the information that will be displayed to the user regarding the system shut down delay by the application. For example, when burning a CD, the CD-burning application might provide not only a simple reason message (e.g., “A CD burn is in progress.”), but may also include additional information such as the completed percentage or estimated time remaining in the CD burn (e.g., “30 seconds until task is complete.”). Thus, although this UI component and related APIs often refer to a “delay reason,” aspects of the present disclosure permit the delay reason to be user-configurable. For example, an application may choose not to register a reason in the delay reason, but may instead place task status, user information, or other application-related information to be displayed as text and/or graphical images displayed to the user in a delay reason field.
After setting a current delay reason string, the application may now send a negative response to the shut down request in step 550. This may allow an application to indicate that it should delay system shut down and subsequently appear in the delay shut down UI with the registered delay reason to provide the user an accurate current description of the task being performed by the application.
According to certain aspects, one of the benefits that may be realized includes the reduction of the types of applications that may block or veto shut down. Also, certain aspects may improve the user experience associated with applications blocking shut down and may remove some of the more confusing aspects associated with the shut down user experience.
While illustrative systems and methods as described herein embodying various aspects of the present invention are shown, it will be understood by those skilled in the art, that the invention is not so limited. Modifications may be made by those skilled in the art, particularly in light of the foregoing teachings. For example, it will be appreciated that the operating system 134 may also cause the delay reason string to be output via speakers 197 in the form of speech, where a number of reasons are either stored in and retrieved from RAM 132 corresponding to the various reasons shut down may be blocked, or the processing unit 120 may generate speech from the delay reason string. In addition, each of the elements of the aforementioned aspects may be utilized alone or in combination or subcombination with elements of the other aspects. It will also be appreciated and understood that modifications may be made without departing from the true spirit and scope of the present invention. The description is thus to be regarded as illustrative instead of restrictive on the present invention.
