The original definitions of "hard error" and "soft error" were for disks and go back to the early 1970s at least. A soft error was a recoverable error that could be handled by re-reading the disk sector. A hard error was a permanent disk error that could not be recovered.
Interesting they were actual graphical dialogs with bouse support in 16-bit windows, but you'd get a text-mode blue screen on Win95.
Happened a lot to me due to faulty CD-ROM drive. D: can not be read. Abort/retry/fail.
What was even the difference between Abort and Fail?
> What was even the difference between Abort and Fail?
A whole generation of computer users has wondered this.
According to Wikipedia[1], "abort" aborted the program (terminated it), and "fail" returned an error code to the program. (Which … probably has a high likelihood of killing it all the same, since a given random I/O is probably pretty non-optional.)
Wikipedia also notes,
> the message has been cited as an example of poor usability in computer user interfaces.
In DOS the infamous Abort, Retry, (Ignore), Fail was the default handling of "critical errors". Abort would terminate immediately, and fail would return control to the program with an error code.
Ahhh. I remember as a kid playing some game and sometimes this would come up. We learned that Fail would allow the game to keep running but the background for the scene simply didn’t appear (I guess that I/O was optional).
Not sure the differences, but my understanding of Windows was that it wasn't until Windows XP that they added a "Window Manager" think of like Gnome or KDE on Linux. Before then, the UI was all a wrap on top of a command line application, or so that's how I was told it was. I assume the blue screen is as minimal as it is since it usually is some hardware halt, and its much easier to render without worry about any GPU restrictions and the sort. Although the modern ones are impressive with their QR codes.
OK, so from 1985 with Windows 1.0 until 2001 with the release of Windows XP, consumer versions of Windows were built on top of MS-DOS. For the latest releases -- Windows 95, Windows 98, and Windows Me -- DOS was bundled together with Windows to make a complete operating system product. But before then, up through Windows 3.11, you had to say 'win' at the DOS prompt to get into Windows.
But the thing you have to remember is that DOS was barely an operating system. It had a rudimentary file system, support for a single process, and no memory protection to speak of at all. You could bypass the OS altogether to directly access the hardware; most DOS applications, especially games, did just that for everything except file access. So Windows actually provided a lot of operating system functionality that DOS didn't and called down into DOS routines for file access.
(In fact, you could even chainload an operating system like Linux from DOS. A program called LOADLIN.EXE let you load and run a Linux kernel from the DOS command line; combined with special file system support called 'umsdos' that overlaid Linux file semantics on top of the DOS FAT file system, this meant that you could run full Linux, from DOS, in your existing DOS partition!)
But even then -- starting in Windows 3.1 (or 3.11, I forget which) a new feature emerged called "32-bit disk access". Windows provided its own routines to handle the DOS file system while it was running, eliminating the need to call down to DOS at all. This was optional on Windows 3.x but the default on Windows 9x (including Me). So DOS was relegated to the role of a bootloader for Windows and a compatibility layer you could escape to for the old DOS programs people still wanted to run (like Doom, Duke Nukem 3D, and such).
So Windows started off as a layer on top of DOS, which was command-line driven, but once loaded it became most or all of a graphical, multitasking operating system in its own right. And it had its own, built in window manager; matter of fact it had more of one than Mac OS, in which user application code had to handle things like moving, resizing, and closing windows (for which utility functions were provided).
Windows NT, which consumer versions of Windows from Windows XP onward were built on top of, has existed since 1993 and that's its own thing, having a 32-bit fully preemptive multitasking kernel with memory protection, user permissions, and the whole bit. It was used primarily in server applications before Windows XP.
I did some debugging of a embedded RTOS program under DOS. I had compiler switches so I could compile it for the target or DOS. The latter was way easier to debug.
No worries. I keep forgetting how old I am, and that the DOS underpinnings of early Windows may be completely unknown even to those of my successors who work in computing. An entire generation has been born, grown up, graduated college and entered the workforce without having ever seen a DOS-based Windows.
The earliest Windows I used was Windows 95, I remember the "Ski Free" game or whatever it was called, been posted about it on HN a few times. It wasn't until Windows Millenium Me that I really started using a computer daily though, which was an awful OS.
Aside:
You reminded me of my first time using Linux, it was Slackware and I had to type "startx" after logging on to get to the GUI.
I still boot the GUI by hand from the shell. I love the feeling of control it gives me, like I don't have to have that stuff running until I want it. And I was a Slackware user until fairly recently. I use Void, btw. :)
Not sure what you're talking about: the window manager "like Gnome or KDE" was added in Windows 1.0. And while it was kind of a wrap on top of a command line application back then, just as it still is on Linux (I believe), Windows 95 got a completely standalone desktop/graphic subsystem which didn't ran on top of anything except HAL; console/DOS subsystem was its foster sibling, so to speak.
I guess the NT equivalent are those error popups that come out of SYSTEM and similar accounts, yet somehow manage to get on the interactive user's session display. They usually have styling that's several Windows versions out of date.
I guess "Cancel" probably returns a failure code to the caller of the API while "Abort" kills the program, similar to "Abort"/"Fail" dichotomy on MS-DOS.
I have a hard time believing this considering the flag for it in Windows is called MB_ABORTRETRYIGNORE. How old of a Windows version are we talking? Are you sure you've seen this in actual Windows and not in an altered/joke screenshot?
He writes "16-bit Windows", and it's beyond anything I can find documentation for, but he's probably right. That's like pre-1992, I think. But it's been "Ignore" for so long that it's kind of silly to make jokes about it.
My comment was too hasty (sorry) but my point was that you seemed to be asking about the behavior of something that doesn't actually exist, and in fact might never have. (?) I'm not sure where Raymond got it from, or he was just doing this from memory, but Googling around, I don't see an Abort button here:
“‘Abort, Retry, Fail?’ was the phrase some wormdog scrawled next to the door of the Edit Universe project room. And when the new dataspinners started working, fabricating their worlds on the huge organic comp systems, we’d remind them: if you see this message, always choose ‘Retry.'”
— Bad’l Ron, Wakener, Morgan Polysoft (SMAC)
Such errors were called "critical errors" on DOS. They were called critical because the app could not continue execution unless the error was resolved. Windows seems to have picked a softer name.
No, a hard error in this case is one that is triggered by a hardware interrupt and is not interruptible by the system. This is explained in the article.
It can be kind of hard to route an error that happens deep inside a kernel to an application.
Disk errors happening after a deferred write are a classic example that's still applicable today. Your process might have succeeded a write(2) into cache and exited cleanly, then when it's time to write to disk, something bad happens. There's no way to tell an application that is long gone.
But you would use unbuffered writes if you really cared. Otherwise there’s nothing actionable that can be done by the application unless there was some kind of signal or callback / APC.
I'm illustrating a real world scenario where such a mapping may not be possible.
Further, if the issue is a global problem, like filesystem corruption, it becomes even more ambiguous -- maybe that write could have worked or maybe it wouldn't, but the filesystem may just globally make everything read only and start failing writes.
So my point is that these errors were meant for catastrophic failures that don't map neatly into being handled with the process. In a modern kernel there are way fewer of these conditions than was acceptable in the early 90s. But there are a few similar things that are still common.
