Abort, Retry, Fail?: Difference between revisions
→In popular culture: rm unref/trivia |
→Description: academic source on issues |
||
| Line 33: | Line 33: | ||
A program could install its own "critical error handler" while running,<ref name="AoA"/> and many of the more sophisticated programs (in particular full screen programs) did so in order to avoid the messages disturbing the display. Some programs faked the missing "Fail" response in DOS 2.0 by jumping back to the calling program, skipping the return stack in DOS. This was a risky hack as it relied on the stack layout and skipped cleanup operations in the operating system.<!-- Mark of the Unicorn software did this, probably others --> |
A program could install its own "critical error handler" while running,<ref name="AoA"/> and many of the more sophisticated programs (in particular full screen programs) did so in order to avoid the messages disturbing the display. Some programs faked the missing "Fail" response in DOS 2.0 by jumping back to the calling program, skipping the return stack in DOS. This was a risky hack as it relied on the stack layout and skipped cleanup operations in the operating system.<!-- Mark of the Unicorn software did this, probably others --> |
||
==Usability== |
|||
The error messages has been described as being an example of poor [[user interface design]]. A user want to save her work would not want to abort fail, and this be stuck in an endless loop of pressing 'R'. One scholar commented that the message had three issues: |
|||
# It provided the user with little choice,. |
|||
# It was compulsive to retry. |
|||
# Users are fully aware that the consequences of aborting or failing would be to be unable to save one's work.<ref>{{Cite book | url = https://books.google.com/books?id=SbREAAAAQBAJ&pg=PA82| title=Human Law and Computer Law: Comparative Perspectives|last =Hildebrandt| first= Mireille| last2 =Gaakeer| first2 =Jeanne |date=2013-05-23| page=47-48| publisher =Springer Science & Business Media| isbn=9789400763142| language =en}}</ref> |
|||
===Modern systems=== |
===Modern systems=== |
||
Revision as of 20:46, 22 June 2018
 | This article possibly contains original research. (July 2010) |
"Abort, Retry, Fail?" is a computer error message found in the DOS operating systems, which prompts the end-user for a course of action to follow. The message has been used as an example of poor usability design in computer user interfaces.
Background
In CP/M, attempting to read a floppy disk drive with the door open hung until a disk was inserted and the disk drive door was closed (very early disk hardware did not send any kind of signal until a disk was spinning, and a timeout to detect the lack of signal required too much code on these tiny systems). Many users of CP/M became accustomed to this as a method of managing multiple disks, by opening the disk drive to stop a program from reading or writing a file until the correct disk could be inserted.
A primary design consideration for the DOS family of operating systems (such as MS-DOS, PC DOS and DR-DOS) was that software written for CP/M be portable to DOS without changes. Even the first IBM PC had hardware that told the operating system that the disk drive door was open, but returning an error to software trying to read the disk would break the ability to manage disks this way without such changes. Still, it was desirable to improve the experience, in particular by giving the user a way to get out of the hang without having to find a disk to insert in the drive. The prompt was invented for this reason.
Description
A missing disk (or disk drive door opened) was defined by DOS as a "critical error" and would call the "critical error handler".[1] The default "critical error handler" was part of COMMAND.COM[1] and printed the "Abort, Retry, ..." prompt, then waited for user input. Other problems (in particular, a checksum error while reading data from a disk) were also defined as a "critical error", thus causing the prompt to appear for reasons other than a missing disk or opened disk drive. Users could press a key to indicate what they wanted to happen, available options included:[2]
- Abort (A): Terminates the operation or program, and return to the command prompt. In hindsight, this was not a good idea as the program would not do any cleanup (such as completing writing of other files).
- Retry (R): Attempt the operation again. "Retry" was what the user did if they could fix the problem by inserting a disk and closing the disk drive door. On early hardware, retrying a disk read error would sometimes be successful, but as disk drives improved, this became far less likely.
- Ignore (I): Return success status to the calling program or routine, despite the failure of the operation. This could be used for disk read errors, and DOS would return whatever data was in the read buffer (which might contain some of the correct data). "Ignore" did not appear for open drives or missing disks.
- Fail (F): Starting with MS-DOS/PC DOS 3.3, "Fail" returned an error code to the program, similar to a "file not found" error. The program could then gracefully recover, perhaps asking the user for a different file name. This removed the biggest problem with the prompt (which earlier was known as "Abort, Retry, Ignore?") by providing an option that did not crash the program or repeat the prompt.
A program could install its own "critical error handler" while running,[1] and many of the more sophisticated programs (in particular full screen programs) did so in order to avoid the messages disturbing the display. Some programs faked the missing "Fail" response in DOS 2.0 by jumping back to the calling program, skipping the return stack in DOS. This was a risky hack as it relied on the stack layout and skipped cleanup operations in the operating system.
Usability
The error messages has been described as being an example of poor user interface design. A user want to save her work would not want to abort fail, and this be stuck in an endless loop of pressing 'R'. One scholar commented that the message had three issues:
- It provided the user with little choice,.
- It was compulsive to retry.
- Users are fully aware that the consequences of aborting or failing would be to be unable to save one's work.[3]
Modern systems
Hard disks and larger removable media such as Zip drives made the need to manage multiple disks obsolete, and thus made the prompt useless. It was gradually replaced with code that acted like "Fail" immediately. DOS 3.3 COMMAND.COM provided the startup option /F in order to force the default critical error handler to return "Fail" on all errors. Starting with version 4.0, the alternative command line processors 4DOS and NDOS supported /F and the corresponding CritFail=Yes directive in 4DOS.INI/NDOS.INI as well. The option was also supported by the COMMAND.COM of PTS-DOS 6.51 and S/DOS 1.0, as well as by DR-DOS 7.02 and higher. OpenDOS 7.01, COMMAND.COM provides a similar feature with /N (described as "do not install a critical error handler") which is still supported in newer versions. Most other operating systems, such as Linux, always act like "Fail" in all cases.
Windows produces a immediate "Fail" for actions such as opening a file using a "E:" prefix when no disk is in the CD drive. As of 2017[update] Windows 10 can still generate a similar prompt, although in a dialog box and with a more comprehensive error message. The choices are similar but renamed: "Cancel" (to the user this is similar to "Abort" but technically it is a "Fail" with a different error code), "Try Again" (instead of "Retry") and "Continue" (instead of "Fail"). This may be supported by the drivers for some removable media when a file is opened with a full volume name or the disk is removed while the file is open.
In popular culture
In 1993, Neil Howe published 13th Gen: Abort, Retry, Ignore, Fail?, a sympathetic book about the culture of Generation X.[4]
In 1996, White Town released an EP entitled >Abort, Retry, Fail?_.[5]
PC Magazine has used the term as the title of its column highlighting humorous computer-related errors.[6]
See also
References
- ^ a b c Randy Hyde (29 September 1996). "19.1.3: Exception Handling in DOS: The Critical Error Handler". The Art of Assembly Language Programming. Archived from the original on 6 February 2010.
{{cite book}}: Unknown parameter|deadurl=ignored (|url-status=suggested) (help) - ^ "Action Taken on Abort, Retry, Ignore, Fail (67586)". Microsoft Knowledge Base. Microsoft. 16 November 2006. Archived from the original on 8 July 2010. Retrieved 18 April 2009.
{{cite web}}: Unknown parameter|deadurl=ignored (|url-status=suggested) (help) - ^ Hildebrandt, Mireille; Gaakeer, Jeanne (23 May 2013). Human Law and Computer Law: Comparative Perspectives. Springer Science & Business Media. p. 47-48. ISBN 9789400763142.
- ^ Howe, Neil; Bill Strauss (1993). 13th Gen: Abort, Retry, Ignore, Fail? (1st ed.). New York: Vintage Books. ISBN 978-0679743651.
- ^ "Abort, Retry, Fail?_ Your Woman". discogs. Archived from the original on 15 October 2011. Retrieved 18 April 2008.
{{cite web}}: Unknown parameter|deadurl=ignored (|url-status=suggested) (help) - ^ Louderback, Jim (3 May 2006). "PC Magazine's Extreme Makeover". Archived from the original on 8 February 2009. Retrieved 27 July 2008.
{{cite web}}: Unknown parameter|deadurl=ignored (|url-status=suggested) (help)