Richard Grimes on EventLog

The following are comments made by Richard Grimes on Dan Fernandez's Blog.

In the past I have written a lot of C++ code to use and manipulate the NT event log. The API was inherited from OS/2 and it is a little arcane and was in need of a replacement. I wrote several articles about programming the event log using the Win32 API and one of these was in the MSDN library. Essentially, the application provides a resource only DLL with format strings that have placeholders. These format strings are localised. The DLL is registered on the machine that reads the messages. The application merely has to provide the ID of the format string and the strings for the placeholders. The advantage of this mechanism is that the event log files are kept small and that *localisation is performed by the reader*.

The usual configuration is that when an event log file fills up it overwrites old messages, so it is important to make sure that the relevant messages in the log are read before they are overwritten. If the messages in the event log are large then you have less chance of doing this.

However, the localisation aspect is the most important. I worked on the error reporting in a distributed application used at 500 sites (something like 5000 machines) in several countries across Europe. Using the event log a machine in France, for example, could log a message and the user could read it in French, when the event log files were sent to the support centre in England the event messages could be read in English. How elegant is that?

Now let's look at how System.Diagnostics.EventLog does this. Well it provides a single resource DLL *for all applications*. This DLL has 65,000 format strings that look like this: %s, that is there is just one placeholder so that the application has to provide the entire string. This means that the messages are long (which brings up the issue of event log files filling up) and it means that localisation has to be performed *by the application*. Note that no crystal ball is provided. The application has to guess the culture of the reader, and by default the current locale of the application is used. So in my distributed application that would mean that the messages would be reported in French, and I would not be able to read them in English. The application could chose 'culture neutral' strings (ie US English) but that would mean that the French users would not see the message in their language.

The .NET EventLog class does not use the event log the way that it is designed to work. FYI it works in *exactly* the same way as the equivalent class in VB6, which makes me suspicious as to whether the C++ code used in the VB6 runtime was converted to C# and recompiled. I filed a bug about this in the beta and got a dismissive response from the developer stating that people have large hard discs and so could use large event log files. This showed a lack of understanding about the event log. In Whidbey, the EventLog class has been extended to allow you to use a message format DLL, but the damage has already been done.