The first time, the problem was that the game was hanging on launch on a second machine. I had thought, bah, it's just an outdated video driver. Sure enough, the installed video driver was ancient, and I updated it, but still no-go. Eventually I ended up running the game under ntsd.exe and discovering that the game was stuck in a QueryPerformanceCounter() loop. It seems that the programmers that wrote the game figured that the 64-bit LARGE_INTEGER returned by QueryPerformanceCounter() always counted up at somewhere between 1-4MHz and hardcoded that fact in a weird way that the game hung in a speed regulation loop when run on an AMD Athlon. I just ended up hacking out a branch instruction in the EXE to fix it.

The second time, different game, checked the video driver again, no go. The symptom was a silent crash to desktop shortly after the game launched -- pretty user unfriendly, but not unusual for a game. I ran it again under NTSD, and I got a call stack with a module called ixvpd.dll on the stack. No clues on a web search. I checked the game vendor's website, and all I found was a lame "codec patch" that apparently "fixes" a codec compatibility issue by uninstalling ffdshow and avisplitter. (Sigh.) ixvpd.dll didn't have a version description block, but a strings search did reveal that it was a decoder of some sort, and renaming it did fix the problem. It turned out to be a poorly written DirectShow-based video codec that came with the software package from a webcam that my dad no longer uses, so I uninstalled that and that fixed the problem proper.

If you think about it, with issues like these, it's no wonder that average people just throw their hands up in the air and say their computer's broken. It's hard enough to tell what's going on if you are a programmer, much less if you're not.

stdext::hash_set... sucks.

See, Visual C++'s Standard Template Library (STL) is based on the implementation from Dinkumware, and has the following prototype:

template<class Key,
         class Traits = hash_compare<Key, less<Key> >,
         class Allocator = allocator<Key> >
class hash_set;

Notice two things about this hash set implementation: it takes a less-than predicate, and it doesn't take an equality predicate. What the frick kind of hash table requires a less-than predicate??? And we're not talking about a predicate for the hash code here, but a less-than comparison operator for the whole key. It defeats one of the main advantages of a hash container, since IMO it's often easier to write hash and equality predicates instead of a less-than predicate, as long as you aren't dealing with floats. I've never seen a hashed container that required this -- not in SGI-STL/STLport, not in Java, not in the .NET Framework. As you might expect, this means that VC8's hash_set is a pain in the butt to use and is slow. Thankfully, C++ TR1's unordered_set follows the SGI-STL/STLport path rather than Dinkumware's.

I haven't really had a need for a full blown hash_map or a hash_set in VirtualDub, but I'm thinking that if I do, I'll be better off writing my own....