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.
Chen highlighted an I/O error emitted when attempting to read from a drive. “Windows can’t put up a traditional MessageBox because that pumps messages and allows application code to run at a time when the rules of co-operative multitasking say that application code should not be running.”
Thus, bleating in a MessageBox was regarded as a “soft error” message.
However, other than mouse and keyboard input, which came from the user interface code, the “hard system modal error” was a hand-cranked affair. The graphics device interface (GDI) was asked to draw directly to the frame buffer “and all of the dialog behaviors are handwritten,” said Chen.
“No application code was allowed to run while this message was being shown to the user.”
One comment on Chen’s post recalled a glorious workaround that used a bent paperclip to hold down the R key for an Abort / Retry / Cancel dialog for when an I/O error was thrown due to a sharing violation – for example, when somebody else was accessing a file needed for a build.
This is a variation on the age-old trick of using Blu Tack to stop a ZX81’s RAM pack causing a reset, but that’s a different story.
16-bit Windows is long gone, and the term “hard error” was repurposed to describe critical or low-level errors in later versions, according to Chen. But there was a time, many years ago when Windows was a good deal less forgiving of external forces than it is today.
And when Microsoft said an error message was “hard,” it really meant it. ®
