Microsoft veteran demystifies Abort, Retry, Fail? DOS error 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 …
Abort isn't necessary because the program should deal with errors, not go loopy and then need to be killed. Ignore isn't necessary because it's just corrupting something, instead the program should let you save on another disk.
That was the early MS-DOS era, when OS calls were made setting up CPU registers and calling INT 21H (and a few others). Languages didn't have usually exception management (think Go...), .COM executable had to stay withing 64K of code (which could be half the RAM you had....), and everything was much more primitive.
Anyway, now that I know the difference between Abort and Fail I can sleep better. Maybe a better wording would have had help "Abort application" - "Fail operation and continue" would have helped, but messages were usually quite short back then, especially when everything was hand-written in assembler...
I've never noticed other 80s operating systems giving a plethora of options, just the more usual Retry and Cancel (Fail) and errors were tested for in the program.
And even if memory is so tight, it doesn't take much to do the worst-case option - print "Error <number>", tidy up, and exit.
I'm sure Dave Plummer and the MS-DOS developers had good reasons for doing what they did.
It's a little condescending to just show up and claim that you know better than them.
I also used to have the "Everything that I don't understand is easy" attitude, but we should try to be better than that.
In fact CP/M-86 was almost automatically built by DR using the 8080 to 8086 translator. A company made a sort of copy (somehow) of CP/M 86 and MS bought that company. They only edited/re-wote later versions. So originally no sub-directories. I forget if they came with 2.11 or 3.2. The MSDOS 3.3 was the first decent version. DOS 4 & 5 poor. Next useful upgrade was 6.22, which maybe was last standalone version.
MS did later sell Xenix for the 286 before they had MS version of OS/2 (1989 after IBM & MS split on OS/2). Maybe that's why NT version numbering starts at 3.1 in 1993?
The DOS 7.x only came with Win 9x, which unlike earlier NT 3.1 and NT 3.5 wasn't a true self contained 32 bit multitasking OS. Win9x ran DOS code natively on DOS and 16 bit Windows code natively. NT used WoW so 16 bit api calls used 32 bit API and all 16 bit code ran on the NTVDM.
IBM crippled desktop computing for a decade by choosing 8086/8088 cpu family simply because CP/M applications could be quickly ported instead of the many available true 16 bit CPUs with flat addressing instead of ghastly 64K segments to allow 8080 code porting. Partly they only wanted to compete with Apple 6502, CP/M etc and not innovate or compete with their own products. Zero innovation in the catalogue build 8088 based IBM-PC.
The first version of MS-DOS that I'm aware of was 1.4, it is an almost exact copy of CP/M. DOS 2.x added some "Unix like" file calls to supplement CP/M's software interrupts but still kept the SWI mechanism for backwards compatibility. DOS3.x added additional file operations so that MS-DOS could work with discs shared over a network.
...and there's your problem. Thise CP/M vectors were retained far beyond their useful life because of backward compatibility. Harmless seeming except that some clever programmers had figured out that the way to access these locations was by wrapping around the 1MByte maximum address space -- they'd use a positive offset of a high memory location to access the base of memory. When the 286 appeared it had a larger address space so the problem was kludged by the so-called "A20 switch" which kept this address line low until changed just after the processor entered paged mode. I hate to think how much was sacrificed on the alter of backwards compatibility.
Backwards compatibility is sort of the red thread through all (except NT?) Microsoft OS. Unfortunately. With all nasty side effects. Oh and the inefficiency coming with it as well.
Just so your boss can cling on to his ancient mail program and his word processor (exp)...
To be fair, exp was a great and powerful and advanced program.
I hate to think how much was sacrificed on the alter of backwards compatibility.
"MS-DOS has been described as little more than a glorified program loader that serious programs spend more time circumventing rather than using" (InfoWorld 24 Jun 1991). MS even tried to do a multitasking version of MS-DOS and then abandoned it, while other personal computer OSes around the time just ran rings around what MS-DOS could do - single tasking (Atari TOS, RISC OS, Finder) or multitasking (Amiga).
By the way, MS-DOS later on had a switch to turn off the prompt and always Fail and the program would then manage the error. So that, I think, means I'm right despite the downvotes, because even MS finally realised it was a mess. :)
"There never was a MS-DOS version of 1.4"
I have a copy that is labeled 1.4. It was an OEM version that was built to run machine control software. Near as I can tell, it is essentially identical to DOS 1.25, but with a couple hardware specific hooks in the kernel.
There were many such odd-ball versions. The oldest I have claims to be the 0.96 Pilot build version of IBM PC-DOS on the hand-typed floppy label (internally it reports as version 1.0). I know it's real because it came from the actual pilot build IBM PCs that the company I was working for at the time was asked to help evaluate for IBM.
Likewise, my Bridgeport CNC came with what claims internally to be PC-DOS 3.26b, but to all intents and purposes is actually DOS 3.3 ...
> Maybe that's why NT version numbering starts at 3.1 in 1993?
It went like this:
Windows 1.0 -> Windows 2.0 -> Windows 3.0 -> Windows 3.1 -> Windows 95 -> Windows 98 -> Windows ME -> Trash
Windows NT 3.51 (Kernel build from Scratch, apps/shell from Windows 3.1) -> Windows NT 4.0 (NT Kernel, apps/shell from Windows 95) -> Windows 2000 -> Windows XP -> Windows Vista -> Windows 7 -> Windows 10 -> Windows 11
So true. I always said that the IBM PC combined the worst features of the Apple ][+ and the Model 1 TRS-80 - and the best features of neither. All-in-ones such as the NorthStar Advantage, the Intertec Superbrain, and countless others were the future trend, until IBM saddled the world with its crippled PC that took us back to Model 1 TRS-80 days - 3 ugly boxes connected by cables. At least the TRS-80's components looked like they belonged together, IBM's did not. Why IBM didn't go with the 68K family has always frustrated me. Even for an 8088 based system, it was crippled - the chip was good for 8MHZ, IBM used 4.77 as their clock speed. Tiny floppy drives that couldn't even hold a memory dump, a bad clone of CP/M that made TRS-DOS look good, a hole in the memory map for video (Just like a TRS-80), bastardized or ignored industry standards, the list of fail goes on.
To make it worse, the "serious" Microcomputer users of the day (Largely S-100 systems, but there were others) laughed at the PC as the toy it was, so the early adopters were from the Apple and TRS-80 worlds - and they brought their amateur hour programming practices with them. This kept the PC realm crippled for at least 10 years, by the time "serious" Microcomputerists (were forced to) migrated to the PC, these practices were firmly entrenched, and it took many years to purge them from general acceptance.
Often the issues were intertwined between the hardware of the era and competency of the user. The hardware was rather primitive by current standards. Many issues could not be handled all that nicely back then on any desktop computer. As a percentage, users were more technically savvy back then. Many of us early adopters were STEM types who had some vague familiarity with computers already. The OS designers to some extent relied on this background and understanding, possibly naively. Being STEM types many of us were more willing to poke around into the OS and the hardware.
You are dealing with a very different era in the 80's and 90's were many did not have a computer either at home or at work. Those that had one at home were often technically minded.
Really till DOS 2.11 or DOS 3.3, one designer, Gary Kiddall in approx 1974. He offered the idea of a personal desktop computer based on 8080 to DEC when Intel (where he worked) wasn't interested. They weren't either, so he founded Digital Research. He was never going to be a Steve Jobs or Bill Gates, because they were good at business and using other people's ideas, so ultimately DR faded away despite CP/M 86 on PC, DR-DOS, GEM GUI and later CP/M 80 reborn on the Amstrad PCW series.
Which is why every language has some method of detecting a specific error and ignoring it. You can check the error code you want to ignore and do nothing with it. You can catch an exception and drop it. If there is a possible error condition for which you really do nothing, you have lots of ways to deal with that. The key word here is "specific". If you don't want an error to trip up your program because it's not relevant, then look for that one. Don't just assume that any error that comes along will be that one.
Error handling is boring, but critical. I can't count the number of poorly written programs or scripts that can't handle the most basic of unusual cases. Scripts that don't get as many command line arguments as they wanted, but instead of printing an error and exiting, they try to run hundreds of lines printing no such variable errors while trashing the environment they're in. Or libraries that throw exceptions because they frequently mess up and programs that catch and ignore all of them because they don't want to clean up but can't be bothered to find a library that works properly.
Or when you are like me and install DOS 6.22 in Qemu one sunday morning for fun. Then fiddle with freeing up as much conventional memory as possible to let you run a game that you just pkunzipped from a shareware CD-ROM image that you have, only to find that you now know why turbo buttons were invented and why you should have uses DOSBox in the first place.
This post has been deleted by its author
The first challenge is getting stuff onto the VM Image.
Windows 98 is bad enough. I managed in the end to get stuff onto it by enabling the FTP service on my NAS and using the command line ftp client. The Windows Explorer client didn't work. From there I was able to obtain some USB mass storage drivers and use an SD card to transfer stuff across.
I don't think MS DOS comes with an FTP client, or even network drivers, so I guess you would have to build floppy images in your host operating system and attach them to the VM.
Oh yes it did. I used to run a series of networked DOS machines back in the 1980's, and my first file server was a 286 with a 20MB hard disk. 1Mb/s network speed via co-ax RG58 (IIRC) and it was fantastic, compared to 5 1/4" floppies anyway.
I moved on to use Artisoft Lantastic in the Win 3.11 days, which ended up being purchased by MS and incorporated into Win95.
What a time to be alive ...
In the mid 90s a document went round purporting to introduce "Windows for Weegies". As a Glaswegian myself I can testify that it was spot on: "My Files" became "Aw mah shite", "The Internet" became "Porn an that" and - my favourite - "Yes/No/Cancel" dialogue boxes became "Aye/Naw/Fuck off" which I think accurately reflects how most users see the,
"It's a bit of a secret club, really, for those of us who actually know what it means…"
and
"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."
How am I to be a wise and all knowing user, if microshit keeps the information to itself.
stupid c*nts.
When do we get treated to the explanation of why dos6 memmaker was crapper than a simple analysis of the output of 'mem -c' and manual editing of config.sys and autoexec.bat? That's when I first realised just how shit they were.
Can somebody at Microsoft explain this "error message"?
I once tried to start the cluster service on an NT 4 box that had been brutally removed from its previous place of residence when we acquired the company that owned it.
The service failed to start and helpfully displayed a dialog box that simply said "November".
I'd still like an explanation why "A TrueType font caused a general protection fault in module setup.exe" was thrown at me when installing windows... Uh... 98? one night. Legit original discs and all. Sort of drove home the point that I would rather not deal with that shyte any more, and grow up, and fsck up my machine all by myself, using the dangerously powerful possibilities Linux offered....
Probably a corrupt font. Windows, for reasons only known to the architects, doesn't display fonts. It executes them. That's right, kiddies, truetype fonts are executables, in the .DLL format. A corrupted font file could (can?) cause a GPF. There were kernel-space exploits based on this.
C'mon, people! MS-DOS wasn't an actual operating system, it was just a glorified program loader. Why on Earth would you expect it to do OS-ish things?
Besides, we all knew what that error message meant in the early '80s ... it's not like DOS was difficult to take apart to see what made it tick.
Remember the late '80s/early '90s so-called "Undocumented DOS" books that were, basically, just re-writes of FAQs from Usenet?
When i was young and stupid, around dos 6.22 i took a hex editor to command.com and found the error message "bad command or file name" i replaced this with "I love you martin truely" because it had the same amount of letters. Dos still worked, but it did not take long for my mind to see the error "I love you martin truely" and to recognise it was "Bad command or file name" for me dabbling in linguistics and semiotics it was a learning experience.
I'll tell you this, a DOS HEX editor is why I've been married to my wonderful lady for 32 years!
I used to hack games, sometimes for fun and sometimes to...help ( ahem) distribution. Anways, I'd use my Hex editor to put messages and my girlfriend's name in all sorts of places in games she'd like, then drop the game disks off to her each night after my work night shift ended. She loved playing all the games just to see where I'd left the silly messages to her!
Must have worked, we're both still in love and still both nerds!
it was even MORE fun to change an error message on a university time-sharing computer, especially when the sysop knows you did it but instead of accusing, asks for your help to fix it back...
error message was: "Program lost. Sorry"
new error message: "Program lost. Tough Shit"
(as i recall the flat file with the messages had fixed length records, and both fit within a single record)
"You wouldn't happen to know how to fix this would you?"
keeping a straight face, worthy of Simon. "Well, I think that is stored in a file.. oh here it is! Looks like fixed length records. Let's write a quicky BASIC program on the operators console to fix it. You should be able to blah blah blah oh looks like it worked!"
Inspired by a Hackaday post about Raspberry Pi palmtops I put some batteries in my DOS-based HP handhelds the other day. Sure enough, I soon encountered "Abort, Retry, Fail." And sure enough, I didn't know what to respond. (I think "Abort" got it to stop trying to access the memory card with a dead battery.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
