There are good reasons why applications may need to know what version of Windows they running on. Some things work differently, such as Unicode on Windows 9x vs Windows NT series; some features may need to be enabled or disabled; or at worst the application may need to close because it just does not work on certain versions of Windows.

Naturally enough, there is an API call for this purpose. Two in fact: GetVersion and GetVersionEx.

Trouble is, they lie. There are three characters in this drama. Let’s call them Nanny Microsoft, Good Developer and Bad Developer.

The problems start with Bad Developer, who writes an app that requires (let’s say) Windows 2000 or XP. These versions of Windows (and Server 2003 as it happens) have a major version number of 5. So Bad Developer writes an app that checks for a major version number of 5. If it is anything else, the app says “Goodbye” – maybe during setup, maybe at runtime, or maybe both.

Enter Nanny Microsoft with a brand new edition of Windows. The major version number is now 6. Bad Developer’s app won’t run, because 5 != 6. Customers are unhappy. No problem, says Nanny Microsoft. The silly Bad Developer should have written the app to check for versions equal or greater to 5. We’ll fix GetVersion so that in certain circumstances it returns a major version of 5 even when it should return 6.

In which circumstances, you wonder. That’s when it gets unclear. Could be one of the compatibility modes. Could be when specific known applications are calling the API. Here’s a past case (not Vista, though I haven’t checked) that gives special treatment to apps called either setup.exe or launch.exe.

So Nanny Microsoft “fixes” GetVersion to lie, Bad Developer’s app works, and everyone is happy.

Everyone that is except Good Developer, who wrote an app that really does need to know the version of Windows. Good Developer’s app is failing because customers are running it on versions of Windows it does not support. Good Developer’s code checks the OS version dutifully, but it gets the wrong result because of the work Nanny Microsoft did on behalf of Bad Developer.

The snag here is that Microsoft can’t introduce an API call like GetRealVersion. If it did, Bad Developer would call it and make the same mistake, and then GetRealVersion would end up dishonest as well.

Is Bad Developer bad?

In reality, Bad Developer may not be happy with Nanny Microsoft either. How can any developer lacking psychic powers know whether or not their app will run on a later version of Windows? Nanny Microsoft is taking a chance here – balancing the desire of customers for maximum compatibility with the desire of developers for maximum safety.

Vista compatibility confusion

Vista seems to have more compatibility switches than ever before. There is UAC (User Account Control) with its registry and folder virtualization, as well as 6 “compatibility modes” for versions of Windows from 95 to 2003, and other settings like “Disable visual themes” or “Run in 640 x 400 screen resolution”.

I understand why these switches exist, yet there is a downside. Developers with apps already deployed have no control over whether users choose to run their apps with or without a compatibility mode, or even whether Nanny Microsoft has done something special just for them.

I recall talking through a particularly mysterious problem with a user on one occasion. This was in Windows XP. Somehow, one of the compatibility modes got switched on for the app that was failing. Naturally the resulting errors gave no clue as to the cause of the problem.

I hope that somewhere in the depths of MSDN is a clear description of what all the compatibility modes actually do.

This application might not have installed correctly

This brings me to a feature of Vista I really dislike. You install an app, and at the end a dialog pops up asking you whether it installed correctly. This happens before you have run it, so the correct answer is, “I haven’t a clue.” Nevertheless, Vista wants you to reinstall with “recommended settings”. What settings? I assume one of the compatibility modes above, but I’m guessing.

I always assure Vista that the app installed just fine. I’d rather troubleshoot specific issues, than have apps install with unkown compatibility switches in operation.

DIY GetVersion

If you are a Good Developer (which I presume), then you know not to trust GetVersion. The official advice is to try not to care about the Windows version. If you need to know about a particular feature, check for that feature. 

Good advice, but what if you do want to know the version? I’ve done a snippet of code for PCW for this, but can’t post it yet. It’s not difficult though, provided you are happy with an implicit “or higher”: find some feature that you know is only on that version of Windows, and check for that.

Now that the holidays are over, here’s some hardcore tweakery for Visual Studio 2005 developers. Visual Studio 2005 includes a completely new build system based on XML build files and a standalone build utility called MSBuild. Visual Studio project files are in fact MSBuild files. Open them up in a text editor and you’ll see that they begin like this:

<Project DefaultTargets=”Build” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>

You can also build entire solutions from the command line. Just open up a Visual Studio 2005 command prompt (an easy way of setting up the correct path and enviromental variables), navigate to the project directory, and type:

msbuild yourapp.sln

This is NOT dependent on Visual Studio, since MSBuild is actually part of the .NET Framework redistributable package. This means you can take your project files and build them on machines that don’t have Visual Studio installed, which can be handy for servers.

But what if you want to edit the solution build file? Curiously, solutions are defined in .sln files which are not msbuild files. When you run MSBuild against an .sln file, it actually creates a new in-memory build file for compilation, making it hard to edit.

This is where the tweak comes in. If you define the enviroment variable msbuildemitsolution, then MSBuild generates the solution build file and leaves it there for you to edit. It is given the name yourapp.sln.proj. For the next build, you can run msbuild against this file directly, thus incorporating any manual changes.

Why it works like this, who knows? Still, it’s an intriguing tip and as you can guess I didn’t discover it by accident. I got it from Sayed Ibrahim Hashim’s excellent blog. He is the author of the MSBuild/ClickOnce book Deploying .NET applications. I haven’t seen the book, but I recommend the blog if you want to know more about msbuild; the book is likely good as well.

Dare Obesanjo says 2006 is the year Microsoft gave up on consistent UI. It’s a follow-up to a post by Mike Torres in which he identifies inconsistencies in various new apps from Microsoft this year. One thing they all have in common is that traditional menus are deprecated, either hidden by default (IE7, Windows Media Player 11) or not available at all (Office 2007).

The reason this is happening is the influence of the Web. The Web gives designers a lot of freedom over how applications are designed, especially in conjunction with Flash. The Web also forces app developers to find some alternative to the traditional menu bar, since it has a page model rather than a window model. Standard desktop apps with File and Edit menus now look dated.

Microsoft has embraced the new designer religion, with the innovative Office 2007 UI, the Expression range of designer-oriented tools, and the Windows Presentation Foundation which gives far more freedom to UI designers.

Nevertheless, Microsoft has slipped up here. The differences that Torres identifies are bewildering to users. I predict that the company will settle on some specific approach (probably the Office ribbon) and try to enforce it throughout. Visual Studio with a ribbon UI?

It means developers have a tricky choice to make with new applications. Broadly:

1. Stick with tried and tested menus and toolbars until things settle down.
2. Adopt the ribbon, facing the sign-or-don’t-sign dilemma.
3. Do your own thing, after all everyone else does.

For an in-house app I’d suggest (1). Menus and toolbars work pretty well, everyone knows how to use them, and most important, it is a lot less work. Further, when non-designers try to take a design-centric approach, the results are invariably ugly.