¶DirectX 9 December SDK and VirtualDub
Quick note to those of you experimenting with the VirtualDub source code, or otherwise are working with Visual C++ 6.0: the December 2004 update of the Microsoft DirectX SDK is not compatible with VC6. In particular, attempting to link against the DirectX libraries results in missing symbol errors caused by dependencies on symbols only available in the Visual Studio .NET runtime libraries. I think the missing symbols are related to buffer security checks -- these shouldn't be causing problems since VirtualDub only needs the GUID tables and the interface definitions, but it is. This means that if you are compiling VirtualDub with Visual C++ 6.0 (the official compiler) you will need to stick with the November 2004 Update SDK instead, as that one will still work. If you are using Visual Studio .NET 2003, however, you should be able to use the December 2004 SDK without problems.
In general, Microsoft seems to be making a bit of a mess with the current DirectX SDK. The DirectShow documentation and debug runtimes were simply taken out of one of the DX9 SDK refreshes, and then the DirectShow docs popped up in the Extras package, but the debug runtimes were nowhere to be found. Then the DirectShow debug runtimes were added back into the December package, but with no installer or even instructions on how to safely install the debug DLLs. A number of the DLLs are protected by System File Protection, so they can't simply be replaced, and I'm reluctant to simply disable SFC and stomp the existing drivers since some of the files are kernel drivers. If anyone knows how you are supposed to use the debug runtimes, I'd be interested in hearing.
I had originally planned to stick it out with Visual C++ 6.0 until Visual Studio .NET 2005 was released, but I may change my decision and jump to Visual Studio .NET 2003 beforehand. One reason is the DirectX lib issue; another is that it's looking more uncertain when 2005 will reach RTM or even RC status. I downloaded the October CTP of VC++ Express and discovered that (a) it bombed every time I hovered the mouse cursor over a toolbar button, and (b) a freshly created Hello World project would fail to link with a manifest error. I think the Visual Studio team needs some additional time to stabilize their build. The third reason is that I finally found a solution for the butt-slow debug output window in VS.NET 2003 (and to the less-serious debug engine performance problem in VS2005). It involves a shim that intercepts the KERNEL32 imports of WaitForDebugEvent, ContinueDebugEvent, and ReadProcessMemory in NATDBGDM.DLL and buffers up to 0.2s of debug output for roughly a 20x improvement in debug output throughput. It's crude, but it works.