The hobgoblin of little minds

A few thoughts about consistency, of course (Pace Emerson. let’s not limit ourselves to merely foolish consistency…).

Ahem. Programming geekery ahead…

While my company stays on the up-and-up when it comes to software licenses, we aren’t large enough to purchase them in the kinds of quantities we always need. Right now, for instance, we are unable to downgrade some netbooks from Vista to XP for an upcoming deployment of our software. While we’ve tested our software on Vista, we haven’t yet done as comprehensive a job of it as our XP testing. So, with great trepidation, we installed two versions of our software on these Vista machines and did some cursory acceptance testing. One version worked, one didn’t… and the exception being thrown was a particularly terse and unhelpful one (“An error in the application.” – that’s the whole exception message) from Managed DirectX. We use DirectX in both apps, and in the exact same way in both apps, so… WTF?

To make things better… neither version of the app throws any exceptions when installed on XP. So… WTF²?

For those of you unacquainted with debugging, modern development tools allow you to compile your code in debug mode or release mode. In debug mode, extra information is embedded in the executable that allows you to examine in great detail how the application works – at the penalty of decreased performance. When you ship releasable code, those extra symbols are stripped out and the application runs more efficiently. As a result, once your app is installed in production your options for debugging are pretty limited.

Still, ya dance with the one what brung you… and with what limited tools I had at my disposal, I could see… nothing. Nada. Zip. We’re trapping the error, so it isn’t even being written to the system logs (not that the logs would help much with such a terse message – it would add a cryptic HRESULT code, but that’s about it).

Many elements in our software have accompanying audio files, but some don’t. If they don’t require audio, we use a placeholder file, a properly formatted but empty media file. We also test for an audio file’s existence, in order to avoid an I/O error. The debug tools revealed nothing wrong: the file exists, the media object was being instantiated properly, the DirectX API was being invoked properly… WTF³?

After several hours of pulling my hair out, I decided to rename our existing empty audio file and replace it with a new empty file. Just to cover my bases, I re-ran the troublesome app version before replacing the placeholder file – and it ran just fine.

Go figure. It seems that while Managed DirectX on XP treats an empty audio file as a file with zero duration, the exact same Managed DirectX assembly on Vista appears to treat it as a missing file.

I musn’t be one of Emerson’s ‘great minds’ – foolish inconsistency like this drives me crazy. If only the kobolds and hobgoblins of consistency afflicted software developers more often…

Leave a Reply