Ben Ezzell is the author of the newly released Developing Windows Error Messages. He is also a freelance consultant and software engineer, as well as the author of more than 20 books on computer programming. Ben's books include the first titles that introduced both object-oriented Pascal and C++ (Addison-Wesley) and the complete guide to Windows NT in HELP! Windows NT (Ziff-Davis). He has also authored programming books such as 32-Bit Windows Programming (W.H.Sams) and NT 4/ Windows 95 Developer's Handbook (Sybex). Ben's other interests include puzzles, international travel, and exotic foods.

Troy Mott is co-author of Windows 95 in a Nutshell (May '98) and associate editor of O'Reilly's Windows publishing program.

Mott: Please provide us with some of your background that enabled you to write the Error Messages book.

Ezzell: The idea was floating around in the back of my mind, in part because I'd been developing an error reporting, or event reporting, system in connection with another project. Error messages, particularly bad ones, have always been an irritant, not just to me but to everyone. And, over the years, I've had to decipher a lot of bad error messages, often when trying to resolve client problems stemming from commercial applications.

Add in the fact that error messages in general are an industry joke --just ask anyone in the business -- and you'll get an immediate response, and probably an account of their 'favorite' messages.

Why this happens -- a multitude of reasons -- are recounted in Developing Windows Error Messages, so I won't try to go into this topic here.

Mott: Ron Petrusha (editor of the book) mentioned that the idea to do the error messages book happened at a lunch he had with you and Jerry Thompson (Access developer and consultant). I believe you mentioned a talk you were about to give on error messages and how you were collecting examples of bad error messages. Jerry mentioned that the worst error messages he'd seen were the ones he inserted in programs for himself, then forgot about until a customer found them. Ron then mentioned how it sounded like a good book topic, and after thinking about it a bit you said you would send Ron a proposal.

Ezzell: This account of our luncheon is fairly accurate. I would differ only in a few details, primarily that Ron said that he wanted a book on the subject and my response was immediate rather than considered. After all, I am a professional author as well as an engineer and it doesn't really take long to think about agreeing to do a book. Of course, sometimes I've wondered if it might not have been a good idea to consider a little longer, but not in this case.

As for the talk I'd agreed to give at a symposium, that failed to come off since I didn't hear from the symposium organizers again until two days before the event was scheduled to start, at which late time they finally contacted me about scheduling a flight and reservations. Unfortunately, I'd given up on them, assuming the whole thing had been cancelled or something. The result, instead of a discussion, was the book, which was a better forum for the topic anyway.

Mott: What sparked your interest or led you to writing this particular book, especially given the fact that you've authored so many books?

Ezzell: Good question. Why does anyone write a book? I guess, partially, irritation with bad error messages -- and there are certainly plenty of those around. But also, as you said, I've authored so many books and a theme running through all of them, especially the early ones, has always been writing applications for users, not for computers, so that people can use the applications instead of designing applications for the computer's convenience.

Partially, this was simply a chance to address one of the biggest shortcomings in the industry. Not the only shortcoming, of course, but certainly one of the more blatant shortcomings and one which everyone comes up against -- if not daily, certainly too often.

And maybe there's the 'scratch an author, find a critic' syndrome. Writers are rarely reluctant to speak, and especially not when its on a topic which touches them directly. Or, if you prefer, writers are irresistibly drawn to soap boxes.

Mott: Do you consider your approach to error messages unique, and if so why?

Ezzell: What do you mean by unique? If you mean the only attempt to improve on a poor industry default, then no. There have been others who have shown improved error message formats in applications, and I've cited some of these in the book, as well as demonstrating a couple of alternative approaches, including using HTML sources for event reporting.

With this caveat aside, the methods proposed, and demonstrated, may or may not be unique, but they are certainly an exception. Not to mention a blinding improvement over the standard.

The methods and standards -- and the dynamic link library supplied -- are not necessarily the ultimate solution to a very bad problem nor are they a unique solution. But they are a solution which can be used, adapted, extended and employed successfully in all facets of the industry. And I would very much like to see these adapted even if only for the selfish reason of saving me from having to puzzle through very bad error messages.

Mott: Assuming your approach is unique, how is it implemented in this book?

Ezzell: Well, after dodging the question of unique -- since this is a term subject to implementation, the implementation consists of several elements:

First is simply a practice of storing all error messages, or event messages, as formatted string resources rather than embedding error or event messages in the source code. In this fashion, application procedures load string resources to perform event reporting, in some cases using these as templates to format additional information. The point, however, is that all event messages are gathered in a single location where they can be reviewed, edited, translated if necessary, and maintained without the requirements of searching though multiple source files, and recompiling and relinking entire applications.

Second, the string resources use a formatting standard to combine several message elements in a single string for storage and access, but this is a simple provision.

Third, a dynamic link library supplies the display mechanisms using different dialog formats for the various types of error/event messages.

Last, while not a required nor completely defined element, provisions are also introduced for event recording, including user's comments. This element is incomplete for several reasons. One is that not all applications will need, or want to include, event logging. Another is that several methods of creating event logs are possible, and different applications may wish to use different approaches for different reasons. The reason for introducing the topic, however, is that maintaining and transmitting an event log can be a very important asset to the developers.

Of course, how these elements work, and why each is important and worth consideration, is a large part of what the book is about.

Mott: Can you tell us a little bit about the software (DLLs) that comes with the book and who would be interested in using it?

Ezzell: Well, I've already outlined something about the software but, basically, the DLL provides support for presenting messages and incorporates the basic elements for event logging. The DLL is offered as source code as well as the compiled DLL and is granted to the public domain, as well so that others can adapt, expand and otherwise build on the concepts introduced and demonstrated.

In order to allow the ErrorMessage.DLL -- which was written to use the Microsoft Foundation Classes -- to work with non-MFC applications and with Visual Basic applications as well, additional interface DLLs have also been supplied.

Mott: Since this is an unusual book -- not completely technical nor general, but containing several languages and tools (C/C++, MFC, VB) -- did you find it difficult to write?

Ezzell: You ask this as if implying that other books were easy to write. If that were the case, well, you know what is said about wishes and horses. However, to try to answer your question, yes, the nature of the book did impose some very different requirements and some distinct challenges, and I definitely owe Ron a large thank you for his assistance in certain areas, including creating some of the Visual Basic code examples.

Was the book difficult to write because it is a mixture of the general and technical? No, not particularly, since all books tend to be a mixture to one degree or another. The difference here is one of proportions rather than contents.

Mott: Can you tell us about other writing you've done? I understand you've written several mystery novels in addition to all of the technical books you've done?

Ezzell: One of the shortcomings in writing technical books is that they always go out of date so fast. Not because they become valueless -- I occasionally refer to books which I or others wrote a decade ago or more simply because the material is still valid and useful. But the general perception is that computer books become 'dated' rather quickly. For this reason, as well as others, I'm also interested in writing mystery fiction. A good mystery doesn't go out of date.

Or maybe that's just an excuse I use to cover the fact that I enjoy writing mysteries. Hey, everyone has to relax sometime, and a good mystery is excellent for escape from the routine humdrum of writing programs.

So, whatever the reason, I do indulge my fancy and, hopefully, may eventually find a publisher interested in something beyond my technical writing. Of course, if any of you are interested, several sample novels can be found on my web page at http://www.ezzell.org/fiction.html.

Also, I can be reached directly as ben@ezzell.org. Comments are welcome, and interested agents or publishers, of course, are especially welcome.