Occasionally, you may see a reference in Windows to “hard errors”, such as in this article that shows how to configure an unattended system so that it auto-answers hard error dialogs. But why is it called a “hard error”? Are there “easy errors”?
In 16-bit Windows, if there was an I/O error reading a drive, you got an error message that looked like this:
| System Error |
| Cannot read from drive B. |
|
Abort
Retry
Cancel
|
These messages were special because they were generated from inside the I/O system, below the user interface level. 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.
The code to display these special “hard system modal errors” was carefully written so as to rely only on parts of the user interface code that were re-entrant. In fact, the only user interface code it uses is processing mouse and keyboard input. All of the graphics are drawn by asking GDI to draw directly to the frame buffer, and all of the dialog behaviors are handwritten. No application code was allowed to run while this message was being shown to the user.
The opposite of the “hard error” message was the “soft error” message, which was your regular MessageBox.
These types of hard error messages disappeared from 32-bit Windows, but the name got repurposed to describe other types of critical error messages, usually low-level ones.
There’s a nonsense poem in the Unix fortune file that refers to “hard errors”. In that context, it probably means “hard[ware] errors”, and that’s the interpretation I’d have placed on the phrase before reading this article.
It is also consistent with the Windows usage meaning “low-level critical error”.
Long, long ago, when Windows 3.1 ruled the world and source control wasn't something most people had even heard of, I worked for a company that no longer exists writing software that no longer exists, and we kept all of our source code on a shared network drive. Whenever we would run a build, we'd invariably run into a sharing violation because someone else was also doing a build and was accessing a file we...
(And y’all can put down your torches and pitchforks. We did eventually spring for a license for that newfangled “SourceSafe” thing, unfortunately before Microsoft bought out One Tree Software and, again IIRC, made it available through our existing MSDN subscription.)