Microsoft veteran demystifies Abort, Retry, Fail? DOS error

One option might nuke code from orbit, another puts fate in hands of programmers

Do you Abort, Retry or, Ignore or Fail? We've all been there, hesitating above the keyboard and wondering just what demons will be unleashed by hitting "I". But what is actually happening behind the scenes?

Retired Microsoft engineer Dave Plummer has taken to YouTube once again to confess his role in the DOS operating systems prompt of doom and reveal the origins of the options.

What, exactly, is the difference between Abort and Fail? Retry seems obvious enough and Ignore carries with it the same badge of shame as a Visual Basic programmer's use of On Error Resume Next, but Abort and Fail raise a few questions in some of our minds.

Plummer's take is from the MS-DOS world and he confided: "It's a bit of a secret club, really, for those of us who actually know what it means…"

"Deep within COMMAND.COM, which is the core program of MS-DOS, there is something known as the Critical Error Handler," he continued.

When something really bad happens, such as a disk error, things come to a screeching halt and the operating system needs guidance from the user regarding what it should do.

"In other words," he said, "MS-DOS knows something serious is going down and it doesn't know how to handle it. So it's going to give you, the wise and all-knowing computer operator, the decision on how to proceed."

In this case, you get four choices: Abort, Retry, Ignore or Fail.

Most people would likely jab R for Retry in the vain hope that their document might be saved before giving up with a despairing A for Abort.

Although many might think Abort would simply abort the current operation, it actually aborts the entire program or, as Plummer put it, "terminates it with great prejudice," leaving no possibility for any clean-up or graceful end. If a file is half-written, tough – it'll stay half written.

Retry retries the operation, although Plummer shared a little more from the days of CP/M and the use of a sensor to check if the floppy drive door was open or closed. "If you tried to read or write to disk when the drive was open, it'd just hang and wait for you to close the door," he said, which in turn opened the door for disk swapping during operations.

The IBM-compatible kit running MS-DOS, however, might not have such a sensor. "For one," said Plummer, "the disk change logic in the IBM PC was not fully implemented, thereby either saving IBM a few pennies on every machine in circuitry, or more likely, making it so that they could source the drive more broadly, thereby saving a few pennies on each machine that way."

So what to do? The answer was a virtual latch sensor based on whether everything had been OK with reading and writing for at least two seconds. "So the virtual latch was really telling not if the disk was ejected or open, but rather, whether it could be assumed to still be there," said Plummer. And the two seconds? Based on how fast the MS-DOS gang could change disks (they couldn't do it in less than two seconds).

And then there was the situation where one might be trying to write to a write-protect floppy. The user would have an opportunity to remove the tab or swap the floppy before trying again.

Those were the days, and an example where Abort would perhaps not be the best option.

Plummer also held his hands up to being the author of the scenario where Retry might be the only option. Unsurprisingly, it's related to his work in the dark art of disk caching; a user might save their work, which went to the cache, then exit the program. And then, when the cache was being written, a disc error might occur.

Abort made no sense – there was no program running. "Ignore could very well corrupt the entire filesystem structure of the hardware itself," said Plummer. So there were just the options of a Retry or a reboot open to the user.

Ignore was a risky proposition in its own right, seeing as it made MS-DOS effectively lie to the application and insist all was well, while the operation silently failed. Still, as Plummer noted: "Sometimes the perfect is the enemy of the good, and if you can get back 99 per cent of your text file by ignoring the error… in certain circumstances ignoring the problem was the best option."

Let the programmer that has never had their code swallow the odd exception or two in pursuit of "good" rather than "perfect" fling the first stone.

That said, over the life of MS-DOS the number of things that could be ignored dwindled. Disk errors (such as leaving the floppy door open) couldn't be skipped anyway, and as hardware progressed problems became less frequent. "By the time of MS-DOS 6, there were hardly any Ignore cases left."

Which brings us on to Fail. This placed your fate squarely in the hands of the application programmer. All it does is allow the operation to fail and report back an error code. It is then up to the application itself to deal with it as it sees fit. Assuming there was some error handling in place.

The days of MS-DOS seem a terribly long time ago, and floppy disks have mostly been shunted off to the magnetic media drawer in the sky. But, regarding the definition, Plummer observed: "Better late than never." ®