It involves a shim that intercepts the KERNE元2 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. 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). I think the Visual Studio team needs some additional time to stabilize their build. 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. One reason is the DirectX lib issue another is that it's looking more uncertain when 2005 will reach RTM or even RC status. NET 2005 was released, but I may change my decision and jump to Visual Studio. I had originally planned to stick it out with Visual C++ 6.0 until Visual Studio. If anyone knows how you are supposed to use the debug runtimes, I'd be interested in hearing. 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.
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. 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.
In general, Microsoft seems to be making a bit of a mess with the current DirectX SDK. NET 2003, however, you should be able to use the December 2004 SDK without problems. 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. 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. 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. 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.
0 kommentar(er)
