Looking for business 3D? Use WPF

The world of 3D on Windows for business or scientific purposes has been in flux for many years. DirectX was intended for games and besides was for unmanaged code while Microsoft has been pushing for development to be managed code (and rumors circulate that the version of Windows after Vista won't even run unmanaged code natively). Then there was Managed DirectX (MDX), version 2.0 of which was suddenly abandoned just as it was about to get out of beta. Then Microsoft came out with XNA Game Development Studio at the end of 2007. This had three problems. First, it was for Visual Studio 2005 instead of Visual Studio 2008. OK, maybe we can live with that. Second, it was geared toward games, with the framework expecting the application to always and continuously compute the next frame. Well, I guess we can work around that. Third, it wasn't compatible with WinForms (or any other managed platform for desktops). It was on their list of features to add, but they ran behind schedule and nixed it. Big problem.

The correct and best way today to develop 3D applications for business and scientific domains on Windows is to use WPF (Windows Presentation Foundation), which is part of .NET 3.x. WPF exploits 3D acceleration hardware like DirectX and is fully accessible to C# desktop applications. And it's compatible with Visual Studio 2008 -- in fact WPF seems to be the primary reason Visual Studio 2008 was even built.

That's a screenshot of a WPF application I'm working on. The cylinder and metal cans were mathematically computed on the fly in C#, because they're such simple shapes. The hammer and chisel were designed in Blender 3D and exported to XAML. Using standard Windows mouse interaction code, the cylinder, cans, and hammer can be dragged around.

Disabling XP's check for signed drivers

It is possible to disable XP's check for signed drivers with the code
at http://openvpn.net/archive/openvpn-users/2004-11/msg00341.html

Of course, it's also possible to disable it manually via Start->Control Panel->System->Hardware->Driver Signing. But the C code from the link above allows an installer to disable it automatically. For the vertical application I maintain, I bundle every possible A/D board driver into an all-in-one InstallShield installation, and I have to use a variety of tricks to make them all install silently. This is the latest such trick.

Manifest Hell

Visual Studio 2005 SP1 has different CRT (C Run-time) and MFC libraries than non-SP1 Visual Studio 2005 does (also known as VS2005 RTM, or release to manufacturing). This can wreak havoc in light of XP's strong support for (and enforcement of) SxS (side-by-side) DLLs, which allows different applications to use different versions of the same DLL. Or, in the more complex case I encountered, a single application may end up needing to dynamically link to both the RTM version of MFC and the SP1 version of MFC.

I ran into this while trying to use some ActiveX controls out of National Instruments' Measurement Studio. Measurement Studio needed the RTM version of MFC, but my Visual Studio 2005 SP1 would only create applications with the SP1 version of MFC. And they conflicted, generating "activation context" errors.

To handle SxS, Visual Studio 2005 introduced the concept of manifest files, which specify precisely which version(s) of which DLL(s) are required. There is even a mechanism to automatically promote to using later versions of required DLLs. No matter the combination, I couldn't get my MFC application to work with Measurement Studio, because I of course did not have the source code to Measurement Studio to recompile it against the SP1 version of MFC. As one blog author put it, in the course of trying to solve DLL Hell (for the user), Microsoft ended up creating Manifest Hell (for the developer).

So my solution was to use ATL instead, and let Measurement Studio use the RTM version of MFC.

VS2005 still needed for unmanaged XP code

Visual Studio 2008 dropped the Platform SDK and replaced it with the Vista SDK. That means that to develop unmanaged code that targets both XP and Vista you'll still need to use Visual Studio 2005.

I discovered this when I couldn't find ShFolder.h in my Visual Studio2008 directory. Thankfully, I still have Visual Studio 2005 installedas well.

Don't delete components from an MSI

In an MSI, don't ever delete a component unless you plan to make it a"major upgrade" (change of both product and package GUIDs) rather thanjust a "minor upgrade" (same product GUID, different package GUID). If you try, msiexec will fail with "another version of this product is already installed". It was particularly frustrating for me because I use InstallShield to build an MSI wrapped inside InstallScript, and InstallShield was silently suppressing the error and just notinstalling anything.

To achieve the same effect as deleting the component, I just deleted all the files within that component instead, and that worked fine.