§ ¶Windows SDK fun
I finally broke down and bought a new laptop... not that my old one was broken or anything, but I wanted something a little lighter than the 17" Inspiron I had before, and also something with a bit more CPU support than SSE2. The new laptop is a Latitude D830 with a 2.5GHz dual-core Penryn, which means I can now play with SSE3, SSSE3, and SSE4.1.
Well, now that my development environment is set up.
The stability of Windows, and the rate at which I install software, has slowed to the point that I generally don't reinstall Windows except in the event of a major hardware change. As a result new machines are an opportunity for me to wipe the slate clean. The problem in this case is that I had forgotten about the current mess that is the Windows SDK situation. Specifically, the migration of the DirectShow SDK from the DirectX SDK to the Platform SDK (now the Windows SDK), is still broken. VirtualDub now requires the DirectShow SDK to compile due to WDM capture support, so this is a bit of a showstopper. Unfortunately, that's not the only problem.
In a nutshell:
- dxtrans.h is missing from both the current Windows SDK (Windows Server 2008 + .NET Framework 3.5) and the current DirectX SDK (March 2008), and it's required by the DirectShow headers. Microsoft is considering fixing this in the Windows 7 SDK.
- Starting with the Vista version of the Windows SDK (v6), there is a conflict between intrinsics definitions in winnt.h and VS2005's intrin.h that causes a compile error if both are included.
Sigh.
After screwing around with this for about ten minutes, I got tired of it and just went back and installed the same Windows Server 2003 SP1 and DirectX August 2007 SDKs that I had on my old laptop. I shouldn't be changing base SDKs in a point release, anyway. Still, it bothers me that the Windows SDK versioning situation is so fragile; it's a bit annoying to explain to someone else how to build VirtualDub.
Of course, even after all of this, I haven't even gotten to checking the x64 build yet. My desktop has been on the fritz lately (nForce4 based motherboards suck), so I haven't actually been able to test the 64-bit build of VirtualDub in a while. In theory I can dual-boot into Vista64 now and get both my Vista and x64 testing done, but we'll see how that goes....
Comments
Comments posted:
On most x64 capable machines, VMWare Workstation will allow you to run a 64-bit client on a 32-bit host. Before I switched to x64 completely I used it quite a bit to keep for my 64-bit testing. Lot better than rebooting. There is a processor check utility on this page where you can make sure your processor supports this before installing everything.
http://www.vmware.com/download/ws/driver..Michael Sartain - 13 04 08 - 19:33
I've used virtualization before (I'm still bitter at having bought Virtual PC and then watching it languish under Microsoft), but one rather big problem is that you don't get true 3D acceleration under VMWare. Aero Glass won't work at all, and the 3D acceleration that's supported for user space application is marginal at best. Running VirtualDub without Direct3D acceleration enabled in Vista kinda sucks because with WDDM drivers GDI and DirectDraw are totally unaccelerated.
Performance tuning under a VM is also sketchy. I've experimented with VMWare Player in the past, and while it's miles ahead of current versions of VPC for smoothness, it's still not something I'd trust. I've also never tried running VTune under a VM, which I consider absolutely essential for optimization (CodeAnalyst can sometimes be a poor replacement).
Phaeron - 13 04 08 - 21:25
Yep, agreed on all those points. Just thought I'd mention it because I'm doing software rendering and found VMWare great for quick build sanity checking without rebooting. But you're right - when I needed to run VTune or do real perf testing then I had to suck it up and boot into x64 native. You also can't have more than 2 cores with VMWare which can hurt depending on what you're doing.
Michael Sartain - 14 04 08 - 01:48
I had the exact same problem, the 1st solution was to comment the confliting entries in "intrin.h", that solved the problem but was lazy solution, so after I had some time a hacked into "winnt.h" (made a backup) including there "intrin.h" (restored version) and removing the offending entries. There is also another problem with the new SDK, in VirtualDub system lib, we have to change the 1st line in "stdafx.h" to #define _WIN32_WINNT 0x0500.
brunof - 17 04 08 - 07:18
I just wanted to second the annoyance with the missing dxtrans.h in the Windows SDK. I eventually found it by going to a DirectX sdk from a few years back. But ya its a total headache.
Eric - 04 05 08 - 07:09
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
