Evaluating the usefulness of the Windows Error Lookup Guide
This is not a commentary on any of the following things:
This is a
commentary on the
Windows Error Lookup Guide, it's
ineffectiveness and the troubles it has as an item of content here on
Everything2.com
JeffMagnus originally created the
Windows Error Lookup Guide in order to turn
E2 into a
documentation base (roughly quoting it's home node). There are
several things wrong with the
approach he took, in my mind, and numerous things wrong with the
information as it
currently stands (content and organization). For
brevity’s sake, the term "Windows Error Lookup Guide" will henceforth be known as
WELG.
- WELG is out of date. Content on the system should be dated in someway, and largely this is done by timestamps and references to world events, culture, or other clues as to the timeliness of the information. The WELG does not say from which database of Windows error messages it was taken. It was dated at the beginning of the year 2000, but that still doesn't give any clue, as to what is actually current in the database. Documentation needs to be kept current, or it is of little value, even archival value. Due to the sheer size of this project, the information needs to be refresed and kept current.
- WELG is incomplete. Last night I read TheBooBooKitty's Windows Error 0x00000000 - 0x0000007F
node on how a good deal of the lower numbers of Windows Errors are missing. I took some time to think about this, and decided to run an experiment overnight on my computer. The code I used was similar to that of other nodes mentioned.
This turned up the following result:
(list of errors truncated for your sanity)
Windows Error: 590627 - There is no LSA mode context associated with this cont
ext.
There were 2431 errors found!
By a hand count of the nodes on the system, I count 1444 nodes (I may have over or undercounted by a few). There are 29 Pages of fifty, one page of thirty, a page of 16, and two mishaps / non-error message nodes. That makes 1494 nodes. This means WELG is about 1000 errors short of the full current (Windows 2000 RTM) database of errors, and there is no telling how much this is going to grow with Windows XP.
How can I be sure that the information is contained with about 60% of the errors present?
- The WELG is better replaced by one of the numerous programs that look up error messages. One such node is: Single node that will obsolete the Windows Error Lookup Guide. The filler information here makes up .3% of the database. It's not a lot, but it does clutter up many of the items there. Does it get used? I'm not sure, but we notice them often in the Random nodes box. The necessity to look up Error nodes by hex value is dubious here.
*) WELG is hard to search through manually, and is easier for your local computer to do it than for E2 itself to. The error message base builds upon itself, so any program that throws a message in Windows 98, a person in Windows 2000 can look up, and for the most part, vice versa. You computer looks up the number as an index into a hash of strings, not a SQL regex to pick out the node you are looking for. Currently nodes about windows that are not WELG entries are all but impossible to find, due to the sheer saturation of titles. There's no way to sort out this specialized content from general content.
- In twenty years, will this be a useful item to archive? Sure, this is "everything", but the "stranded-ness" of the information under discussion here is great. It's a subset of the current string table, isn't of historical value because it is incomplete, as you can't see how the error messages or API's changed since Windows 3.1 (the beginning of Windows as we know it). As it stands, it's useful neither now, nor will it be useful in the future.
Everything2 has changed a lot in the last two
years, and what is
considered "
for the ages" has really
evolved and changed with it. Many old
conventions have gone out the door, and have been replaced by good, strong, and
archived information. The
Windows Error Lookup Guide is one of those old items that may have had
timely value in the past, but it's
effectiveness is quickly waning.
Should it be removed?
Until a more complete, reliable, and better-archived solution is achieved, these messages would all have to be redone by hand. Their sheer size might be an excuse to leave them as is, but similar other incomplete projects have been destroyed or given to others to finish. I’m not sure that I personally would want this project continued in the same manner.
How should it be done differently?
It would be my suggestion to include the module the error came from, when it first came into play, and possibly sample code that may trigger each message. This would be of great historical value for people looking at the system in the future, and would help people who need this information later on. Imagine if someone went in and documented all of the COBOL functions and items that older OS-es and systems had; we could have been a wealth of information, when it was truely needed.
For instance:
WEM : 0x00000000
Hexadecimal error identifier: 0x00000000
Module: none (
Generic Error)
Platforms:
Windows 3.1,
Windows 95,
NT 4.0,
Windows 98,
Windows 2000,
Windows ME,
Windows CE,
Windows XP
Decimal error identifier: 0
Windows API Error Identifier: ERROR_SUCCESS
Error explanation:
The operation completed successfully.
Comments:
Typically
GetLastError() will return zero after a successful API call, or if there are no problems encountered during an operation. Typically you will see something like:
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd);
{
int nErr;
MessageBox(NULL, "Hello", "Nice to meet you!", MB_OK);
nErr = GetLastError();
if(nErr == 0)
{
MessageBox(NULL, "Yippee", "MessageBox fired Ok!", MB_OK);
}
return 0;
}
Note, the above source code was not tested, but would be for the final node.
There are many ways to describe the
complex Windows internals, and if someone wanted to give a
programmer's
troubleshooting guide, that would be great, but as it stands, the
errors are simply not as useful as they could be.
Comments welcome.