What makes a hard error hard? Microsoft vet tells all Microsoft veteran Raymond Chen has taken us back to the era of 16-bit Windows and the definition of a "hard error" compared to something a bit softer and easier. During the era of Windows 3.1 and its ilk, Microsoft was faced with the challenge of throwing up an error message that would be so modal that nothing else would run …
I remember working with a company that had "updated" it's applications from the RSX11M environment to the Windows 3.1 customer world, creating a lot more new customers and starting to see the new Windows environment. But the positive side of the problems was that the programmers creating the new Windows programs (based on their original PDP assembler code) saw the error environment and worked well to describe it and fix it permanently ever since then after fully understanding what had happened.
Just an example that errors can be very helpful - teaching the programmers things that they had not previously thought about. And are normally fully solved.
However, at the same time Microsoft also perverted the meaning of error messages in some of their own applications. For example, any time that the likes of Microsoft Word or Excel failed due to random reasons, usually poor code, the exception was trapped and the modal error message "Out of memory" was shown. Not that this is much more useful than the current endemic crop of poor quality coders who do no error checking whatsoever and instead propagate everything up the exception stack so rather than a simple and useful "file X does not exist", an unintelligible low level exception is shown instead (nothing is logged, of course, which makes it even harder to work out WTF went wrong after the event).
Hate this kind of thing:
try:
␣␣␣␣f = open(filename)
except Exception:
␣␣␣␣print("error opening file")
␣␣␣␣sys.exit()
Hate, hate, hate.
Maybe some programmers think that the appearance of a message from the default exception handler makes their code look “unprofessional”, or something? Me, I quite happily intercept only the exceptions I actually care about, and let the rest go through to a default application crash. Then I look at the logfile to see if there’s anything else I need to worry about. Much simpler that way.
Compared to the pile of shite that Windows is today.
Granted, the BSODs are much fewer are far between, but shoddy updates still fill the news channels.
Not so much where Linux is concerned.
I wonder if the stability of the architecture has anything to do with it ?
Google is famous for prioritizing new features over maintenance, but I doubt it's quite different at any other big tech. It won't matter if New Clippybot has some obscure fatal condition if you ask it for the weather at precisely 7:15am that BSoDs millions of computers, what matters is Microsoft pushed it out and got to show it off for shareholders.
Some of us still enjoy our wobbly windows.
Is that not what you meant? Surely all the good modern OSes keep the GUI as a modular, replaceable layer separate from the OS kernel, don’t they?
Inside ye old Macintosh System file (those who used to be familiar with ResEdit would know), there were a pair of “DSAT” resources. I believe this stood for “Deep Shit Alert Table”. Basically, if the system was so borked that a normal error alert could not be displayed, then this mechanism would kick in. That is what displayed the “Sorry, a system error has occurred” box, complete with the cute little comic-bomb icon.
Unless you had MacsBug installed. (And didn’t all of us inveterate Mac hackers have that installed?) Then that would gain control and display its debugger prompt, and let you mess around. And maybe—quelle horreur—try to resume execution!? Perhaps after skipping over one or two errant instructions?
Many years ago, I was tasked with troubleshooting a Windows 3.1 machine running an Oracle6 database in DOS protected mode. Troubleshooting for hours, I tried resizing the virtual memory in control panel. Completely clobbered the filesystem, rendering it unbootable.
And speaking of filesystems, 10 years later we had had a development database on Win2k which went down and the database wouldn't start. I was able to reboot, but when I went to recover the database, I found entries from the alert log embedded inside the system tablespace.
That kind of horror is due to corrupted file tables. FAT/32 is exceptionally susceptible to such things where allocated blocks on the disk are, usually due to a crash or system restart, assigned to multiple file streams. The result is that chunks in the middle of one file being overwritten by another.
NTFS is less susceptible to this, but definitely not immune to it. Immunity requires very careful and clever consideration of the file structure and the algorithms in use that manage it which is in place in other file systems, just not NTFS to the same degree. Such designs have to balance performance, which is often raw speed but also storage space, bandwidth and multithreading, with integrity and there's always some trade-offs somewhere.
Bringing deeply suppressed memories of Win 2.0 and Win 3.0 programming.
Four Yorkshiremen aside if you were to tell coders today of the details of programming Win2-3 they would be insane to believe you. Real mode and 286 protected mode were truly horrid. Win3/386 might have been better but I was in therapy by then.
At least with Unix virtual memory things stayed where they were put in a process' flat memory.
I "grew up" at least into the computing world of PC on DR DOS. Then forced by MegeShiz to use the MS OS because a change in the kernel blocked DRDOS from executing programs written only for MS DOS. MSDOS had dozens of revisions attempting to do what DRDOS did for PCs. IF memory serves me MS had 26 revision to DRDOS's 3 in just one year. I used DRDOS Gem Desktop at least a year before MS purchased the license to use it as the basis to WindNOs. Gem Desktop worked pretty much flawlessly compared to MS first 30 versions of WindNOs. MS corp culture was get it out the door and we will fix it later. Still seems the same when updates roll out and a week later there is a revision to the update. And heaven help you if you have an old machine that just keeps working until that drive failure and MS can't afford to keep the old OS & updates on their servers. I wonder how many are using an XP to run a 20+ year old flatbed scanner because it will still do books, magazines and other large sizes that are more than a standard sheet of paper?
I wonder how many here started with a TRS-80 Color Computer version #1? Hours of writing code to do simple things programs automatically do for you today. Having to go character by character to find an error that did not produce results that the piece of paper next to you showed so clearly what the computer should come up with. First with DOS then the beginning of HTML.. Whole websites built character by character. TG for the porn industry supplying the funds to make better programming programs and drive the need for video card upgrades. Finally small integrated storage devices vs the cassette tapes in an additional large cassette player. How many had to change the backup tape every morning in case there was a server failure that day? Ya I realize a 5 1/4 floppy wasn't small like today's 1+TB hard or USB drives but compared to a pile of cassette tapes holding your precious hours of work they were life savers. How about the 8.3 file naming restriction?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
