Talk:Abort, Retry, Fail?

Example of bad user interface

As someone who has seen A/R/F thrown out as the stereotypical example of confusing and/or stupid error messages, I find it puzzling that this cultural reality is not included in the article. Yes, there are concrete meanings for each selection, but the computing community as a whole has long offered this dialogue as grist for justifiable ridicule. gloin (talk) 03:16, 24 October 2008 (UTC)

I don't get this. I never found the message confusing. It just meant there was something wrong with what you were copying/running/ect. I found the error messages you get on the old macs and such where they have a bomb in message box and a hex number that relates to some sort of error code that it seemed only like three people in the world had the book that contained what that number meant in english. I mean in comparison the A/R/F message was great! No one likes an error message but as they go they don't get much better than this.--AresAndEnyo (talk) 01:33, 7 July 2009 (UTC)

Popular culture references

I would like to see the "popular culture references" section returned. I think it is interesting to see how a relatively obscure operating system error message entered the wider culture and became a relatively well-known phrase. It seems to me that wider use is what makes a simple DOS error message worthy of an encyclopedia article. —Preceding unsigned comment added by Seitz (talk • contribs)

I agree. The crossover into popular culture is definitely worthy of mention. I've restored the section, but it would be nice if it was expanded, or if more examples were added. Ae-a 13:22, 31 May 2006 (UTC)

I remember that CP/M on my good old CPC 664 displayed a similar message and I suppose that the CP/M one is the "orginal". I think, it went "(R)etry, (I)gnore or (F)ailure?". Anybody out there who remebers more? Simon A. 19:29, 10 October 2006 (UTC)

Use In Windows

Windows 95 has an Abort, Retry, Ignore error that is similar to the MS-DOS Abort, Retry, Fail. I only know of this in Windows 9x.

"Abort, Retry, Ignore, Fail?"?

I don't have an old computer handy to check for myself, but didn't the four-option version actually read, Abort, Retry, Fail, Ignore? I thought that "Ignore" came last when available. Can somebody verify this with old hardware? Matt Gies 01:17, 23 January 2007 (UTC)

I was actually pretty sure that it was Abort, Ignore, Retry, Fail?... I grew up with DOS, but then again I've never had a very good memory. Bduddy 00:52, 3 February 2007 (UTC)

Well, 640k should be enough for everybody. (Sorry, couldn't resist!) --Dachannien^Talk_Contrib 18:33, 16 February 2007 (UTC)

The MS-DOS 3.20 manual specifies "Abort, Retry, Ignore?". As far as I remember, it was "Abort, Retry, Ignore, Fail?" in later versions. -86.137.136.182 11:26, 9 September 2007 (UTC)

NPOV

Yes this is serious. The meanings of Abort Retry and Fail in this message were actually disntinct. Abort would cause the program to return a TRUE value, fail would cause it to return a false value, and retry would simply retry the operation to see if something changed(like a disc being placed in a drive). Again, I'm totally serious about this concern. i kan reed 00:58, 14 March 2007 (UTC)

You're joking, right? If there's a factual inaccuracy in the article then state your reason here and make the change. I see no POV issues at all --DrFod 15:42, 27 March 2007 (UTC)

No, I'm sadly not joking. And no, it's not regarding factual inaccuracy. The tone of the article is actually somewhat hostile. I know it's silly, but that doesn't mean it's not a concern. i kan reed 15:44, 27 March 2007 (UTC)

"Hostile"?! To whom or to what?! 62.189.217.87 15:54, 28 March 2007 (UTC)

Hostile to the message itself. It asserts bitterness in people without so much as a source on the subject. Now that you mention it, I'm worried I might have caught bureaucracy from too many unprotected AfD's... i kan reed 03:34, 30 March 2007 (UTC)

Well please change the article then so the NPOV tag can be removed. Gillyweed 11:17, 1 April 2007 (UTC)

I agree with 'Ikanreed' the article seems overly harsh on the error message design. See my message above under poor user interface or something.--AresAndEnyo (talk) 01:36, 7 July 2009 (UTC)

Rewrite

I just rewrote the bulk of this article. The previous version did not cover the why-and-how behind this infamous message at all. Also, the critical error handler could be invoked for write as well as read, and even for non-disk errors, although that was very rare.

I've tagged my own content as potential original research. A lot of this I know from years of experience. I have probably read about most of it at some time or another, but it's been a long time since DOS, so I can't cite specific sources, which we really should have. Hence my tag. If anyone can find sourcing, that would be fantastic.

Regards, —DragonHawk (talk|hist) 23:06, 29 July 2010 (UTC)

I think there could be some more explanation of how bad this is. Blaming it on "primitive character oriented UI" is very misleading. The MSDOS behavior was wildly inconsistent: a missing file does not produce this popup, despite the fact that the user could "fix" it by changing the disk in the drive. It would have been trivial to have the functions fail in the same way that a missing file did by returning an error to the program. They did not do this because they wanted old CP/M software to work without changes and CP/M instead hung forever when the disk drive was open, they tried to "improve" this but were extremely paranoid about back-compatibility so they did not do the obvious thing of telling the program that the operation failed. It was fairly easy to replace the handler but in fact the design was very horrible, in that changing the handler to be "return an error from the system call" required unwinding the stack rather than any obvious return value.Spitzak (talk) 19:48, 16 August 2010 (UTC)

That's even more original research than my existing commentary. And decisions about backwards compatibility are always a compromise; if they did what you preferred they would break existing software. Find a reliable source which agrees with your reasoning and I'll even write the article for you, but if we're going to get into "They should have done this", we really need sources. —DragonHawk (talk|hist) 15:25, 17 August 2010 (UTC)

I am attempting some fixes that have no original research, except for my clear memory of having to do some nasty trick to make the interrupt act like "fail" and finding that in magazine articles indicating that it was by far the most common fix for this. I still do not like mentioning the CLI, as too many people seem to think that it would be "user friendly" if only the message was in a nice proportional font in a pop-up dialog box, when in fact that has NOTHING to do with how "user friendly" it is.Spitzak (talk) 20:34, 17 August 2010 (UTC)

Changes 17 Aug circa 19:50

Okay, so, we have this:

It could have returned an error back to the program, similar to how it would act if the disk was in the drive but the file not found, however most programs at this time simply exited and thus the user could not fix the problem and continue. DOS tried to make this possible without requiring the programs to be rewritten.

I have some problems here:

1. Relying on the default critical error handler, in and of itself, was not "broken". Why write your own routine to prompt when the OS provides one already? Programs were "broken" when they did not handle the "Failure" status properly, not because they didn't provide their own handler.
   1. In particular, the default critical error handler was used by DOS itself, in the various internal and external commands. These programs weren't "broken" because of that; there was nothing to "fix".
   2. I'm not sure I buy that "Not handling 'Failure'" had anything to do with CP/M heritage; here in 2010, programmers aren't any better about not checking return status.
   3. You argue that telling the program the operation failed is the obvious thing. I don't see that as obvious. Why require every program to write their own routine to say "Hey, you forgot to close the disk drive"?

Programs typically responded to "file not found" by allowing the user to type a new file name. They would respond the same to this error, allowing the user time to close the drive door.Spitzak (talk) 21:21, 17 August 2010 (UTC)

1. I suppose it could be argued that the default critical error handler itself is broken, because the UI is not novice-friendly. That's kind of where I was going with "User experience". But again, please read up on original research and verifiability. I'm already unhappy with how much of this article is unsourced, and I wrote a lot of it! But if we are going to go that route, I think you should expand the "User experience" section. The "Background" section is attempting to explain the environment, not critique the design.

I think your description of why this is user-unfriendly is excellent.Spitzak (talk) 21:21, 17 August 2010 (UTC)

1. There's a difference between "File not found" and a critical error. "File not found" has no solution. Nothing the user can do will make the file appear. (Remember that DOS is a single task.) The user can correct a non-ready peripheral, which is the general theme of a critical error.

Wrong. "File not found" is fixable by changing the disk to one that has the file on it!Spitzak (talk) 21:21, 17 August 2010 (UTC)

I wrote this while you were commenting above, so I will comment there, too. I do think historical perspective with regards to CP/M you mention should be treated, but I'm not familiar with that aspect, so I think your input is valuable. —DragonHawk (talk|hist) 20:42, 17 August 2010 (UTC)

Replacing the default handler

User:Spitzak: From this edit, I gather you believe that replacing the default critical error handler was something which was intended to be done globally, for all programs. That is not my understanding. Individual programs were expected to provide their own critical error handler if they wanted to provide a different UI vs DOS. For example, a program which operated in a "full screen text" mode might not want that ugly DOS error prompt appear in the middle of their text. So they replaced the default critical error handler with something that fit their own UI. Yes, there were things that globally changed the default handler to always return "Fail" (I remember using one on a BBS, so that critical errors didn't stop the system), but that wasn't the only use. I'd daresay it wasn't even the most common use. Any program which wanted to trap critical errors had to do this. Since just about every DOS program had to provide its own UI, I think program-specific critical error handlers must have been done a lot. Certainly I used plenty of DOS programs which provided their own UI for things like disk errors. —DragonHawk (talk|hist) 21:14, 17 August 2010 (UTC)

No I believe programs were intended to provide their own handler. I am not sure what I wrote that implied otherwise. I think MSDOS even put the pointer back to the default after program exit so a global replacement was only possible with TSR.

Any program providing anything other than a trivial prompt and wait-for-key had to unwind the call stack and return to the program's space where further DOS calls were possible. Therefore the only useful result was "fail" as this is the only one that returned to the program space. Most handlers would skip the MSDOS fail return because it did not work on early MSDOS and because they wanted to preserve the useful information in the registers about the error.Spitzak (talk) 21:27, 17 August 2010 (UTC)

Background section

Above, User:Spitzak wrote: I still do not like mentioning the CLI, as too many people seem to think that it would be "user friendly" if only the message was in a nice proportional font in a pop-up dialog box, when in fact that has NOTHING to do with how "user friendly" it is.

Consider that in 2010 (and moreso going forward), most computer users have probabbly never even *seen* a DOS prompt. The idea of a "command line interface" is going to be totally unknown to most people. The purpose of the "Background" section is not to critique or justify the design of anything; it's an attempt to explain what DOS was like to people who grew up on GUIs. That's all. You're reading way too much into it if you think it's trying to "defend" DOS. • Hmmm, come to think of it, what I should really do is get some screen captures of the DOS and/or the "Abort, Retry, Fail" prompt and put that in the article. That would also help provide context. I'll work on that. —DragonHawk (talk|hist) 21:19, 17 August 2010 (UTC)

I moved it to a more appropriate location. The original location really read like "omg it was a CLI and that is why it was unfriendly!". Believe me, "Abort Retry Ignore" in a pop up box with the most beautiful antialiased font and shaded buttons is still unfriendly.Spitzak (talk) 21:29, 17 August 2010 (UTC)

Take two

We're back to this again. User:Spitzak, can you please explain why it is unacceptable to describe what a CLI is? —DragonHawk (talk|hist) 22:50, 18 March 2011 (UTC)

Because you continuously write it as though the CLI is to blame for the bad design. This leads to the opinions of many that if it was just a pretty pop-up dialog with antialiased text that it would be "good".Spitzak (talk) 22:58, 18 March 2011 (UTC)

No. At no point do I say, "This is why it was bad". I'm not describing causes or attributing reasons. Please explain how it is that defining what a command line is automatically means I'm blaming the command line for the usability problems. You repeatedly raise this straw-man argument of pop-up boxes and antialiased fonts. I haven't even *mentioned* that, anywhere in the article. The only person to bring it up is *you*. Please address what is *actually written*.

The "Background" section is for background information about the nature of computing at the time. That's why it explains what DOS was, what a critical error is, what an interrupt is, and what COMMAND.COM was. Actually, it could do a better job explaining what an interrupt is. I'll work on that.

If you can explain how defining what a CLI is therefore means that I'm saying a GUI (which is not even mentioned!) would be better, I will happily address those concerns. So far, all you've done is delete the text repeatedly.

—DragonHawk (talk|hist) 23:07, 18 March 2011 (UTC)

I still feel that anybody understanding that article is well aware that MSDOS was command line oriented. I really feel that is irrelevant, as A,R,I would pop up during programs that took over the screen and did menus. The real reasons for it are the need to be compatible with CP/M (where on most machines a disk missing from a drive would make the call to open a file block until a disk was inserted, therefore a lot of software assumed that the only possible result for creating a file was an opened file).

It certainly was Abort, Retry, *Ignore* in the version most users see. By the time Microsoft added "Fail" most software that took over the screen had also replaced the handler, so users did not see this anywhere near as much. I do remember that faking "fail" was a real pain in MSDOS2 and required unwinding the stack through the MSDOS system, a kludge that was very unstable and Microsoft was forced to remain compatible with the dozens of methods software used to fake this.

I think the important points are:

• Doing "Fail" ALWAYS would have been a much, much, much, much (...) better solution and could have been done even on a "primitive command-line-oriented system" as you call it (which is the real reason I do not like that text). This would not be incompatible with CP/M software, as it would simply act as though the file was not found, which I cannot think of any examples where this would be worse than the program crashing immediately. This is an inexcusably bad design by Microsoft.
• This is an excellent example of cryptic error messages. The information it presents is perfectly accurate but has nothing to do with what the user wants to know or wants to do. This is a design problem that still exists today. Lots of programmers just think if the errors are "pretty" and antialiased and non-modal and have "help" buttons and other crap that it is fixed, but it is not at all. "Abort, Retry, Ignore" would be equally bad no matter how beautiful the pop up error box is. This is the other reason I don't like that "command line oriented" text.

Spitzak (talk) 19:26, 5 May 2011 (UTC)

Include link to famous "Abort, Retry, Ignore" parody of The Raven?

Should there be a link to the "Abort, Retry, Ignore" parody of The Raven? http://www.annoyances.org/exec/show/article09-122 It seems to be fairly well-known in hacker culture and conveys the despair of a user who can only really choose "Retry" in order to prevent work loss. 91.86.58.191 (talk) 21:06, 14 September 2010 (UTC)Alexander

Weighting down the R key

Anyone want to add anything about the occasional practice of placing an object on the R key to provide a continual stream of retries? (Usually to overcome a poor-quality or dying floppy, where repeated retries may eventually produce a good-enough read.) -- SheeEttin (talk) 05:40, 4 March 2011 (UTC)

Where's the reliable source? Where's the notability? Wikipedia is not an instruction manual i kan reed (talk) 17:44, 17 May 2011 (UTC)

Abort didn't always work that way.

I looked at prior versions of the article stating that Abort behaved like Retry on some systems, which is not necessarily true. However, both Abort and Retry did return to the same message "Not ready reading drive –". In these cases the Fail option would return to a prompt. There are newer versions in which both Abort and Fail would return to a prompt. mechamind90 20:00, 23 August 2011 (UTC)