Cupboard

Sucka MC (Win32 Logging Misery)

As part of a distributed system I'm developing for my job at IBM Research, I've written a Win32 application that sits in the background and communicates with a Java program via TCP. I wanted to add some logging to it, just to keep tabs on the various nefarious things it has to do. I figured, "Win32 has to provide some standard API for writing to the event log." I was right. But it's a huge drag. It's very featureful, and provides for localization, and has a great deal of flexibility for customized categories of events, but it's egregiously difficult to hack, and far too heavyweight for "casual" logging.

In order to write to the event log you must take the following actions:

• Create a text file with the extension .mc. This file contains elaborate textual representations of event categories, event types, and such.
• Compile this file with the message compiler, MC. This results in the creation of a header file which exposes the event categories and types as constants (using the C preprocessor), and a .rc file containing the "compiled" messages.
• Build either your main executable or a stand-alone message dll with the .rc file linked in.
• Create the appropriate registry entries to point the event logging service to the appropriate dll or exe file.
• From within your application, you may at last call the ReportEvent() API function.

By contrast, here is the procedure in POSIX:

• Call the syslog() function.

I found a well-written tutorial on adding the MC step to your build at The Code Project, and scrupulously followed the instructions. Unfortunately, I was never able to log an event of my design; I always get the message

The description for Event ID (0) in Source (MyApplication) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Service started.

I would have thought that it was my fault, but many applications (such as Apple's new iTunes for Windows, and several of Microsoft's own programs) show the same bogus message in the event log. So: it's b0rken, and screw it.

My solution? There is a simple API call, OutputDebugString(), which will spit out its single string argument in whatever debugger is running. This would be useless for monitoring of production code if it weren't for the redoubtable SysInternals, who have made freely available a program which intercepts the output produced by that method, and can even receive debugging output from any network-accessible machine. That means I can sit in my cave at IBM and watch other people using my program in their caves.

What children are like.

My wife forwarded me this message from a friend:

A couple of weeks ago I ran into a friend of mine, she was with her little boy, who when I said "let's see how tall you are"  he came right up to me and measured his height across my chest, and copped a quick feel.  His mom apologized, and went on to tell me this story - they were at the beach with a friend of hers, who is quite well endowed, and is actually a dancer in Texas.  Her son, Dakota, snugged up on this large breasted woman's lap, pulled out the top of her bathing suit, looked down, and said "I love you" to her.  They are like that from birth.

Now that's a specification.

I was browsing the Javadoc for JSR 166 (Doug Lea's excellent util.concurrent package, slated for Java 1.5), when I encountered this wry caveat in the documentation for the new System.nanoTime() method:

Differences in successive calls that span greater than approximately 292 years (2⁶³ nanoseconds) will not accurately compute elapsed time due to numerical overflow.

You have been warned.