Patrick Elliott wrote:
> These specific ones, probably not. But, I would have loved to have some 
> sort of "sane" explanations for error codes back in Win 98, when 
> something blue screened do to a DLL getting hosed, or other glitches, 
> which is a similar situation.

Not too similar. In the event logs, the program is running correctly and as 
expected, and it inserts information about its progress into the log. In the 
BSOD, something has crashed and nobody is really sure what or why, so 
generating a meaningful message above the level of the machine's state isn't 
  really possible.

For example, I worked on a machine once where the OS didn't use any floating 
point instructions. If it got a floating point exception while in kernel 
mode, all it could do was dump memory and reboot. There wasn't any 
reasonable diagnostic beyond "this can't happen." If it happens, there's 
some other assumption far away that was violated to cause it.

> Yeah. Less of a problem now, but I still wish some times that the error 
> codes you get from their software was a bit clearer, or that even if you 
> know what the code means, it wasn't so much like modern car mechanics, 
> where you know the "general" area of the engine that broke, but its not 
> always clear *which* of three parts are involved, or even if its not 
> just a sensor glitch, and all of them are OK. lol

When it breaks, it's not always obvious to the programmer why it broke, so 
giving a meaningful error message isn't always possible. If the programmer 
knew why it broke, they'd have fixed the problem instead of giving an error 
message.

Log entries aren't error messages. They're success messages. If success is 
what you're expecting, you don't need to look at the log records.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message