Normally, I’m talking about how to fix applications here, but I want to digress and instead talk about how to help us fix things up in future versions of Windows for you.

The most frequently used application fix is a version lie. We have to lie to applications that are doing the wrong thing (explicit checks for equality), as well as applications that tried to do the right thing but implemented it wrong.

There is a new feature in Windows 7 which lets you tell us which version of Windows you are designed for. Of course, that doesn’t help you out if you’re testing for a minimum version, but if you’re testing for a maximum version (by using equality or <) then this is a better mechanism to communicate that. But, of course, it requires communication – you have to tell us what you have designed for in order for us to react to that. And you have to trust us that we’ll do the right thing. (I’d understand if you don’t.) But our hope is that you can put more of the burden on us to keep your application working, rather than taking matters into your own hand (which, in the end, is actually much harder for us since we have to figure out what everyone did independently to arrive at their solutions).

The application manifest now includes a new section, called Compatibility, for you to communicate which version of Windows you were designed for. It looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!--Windows 7-->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!--Windows Vista-->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
    </application>
  </compatibility>
</assembly>

This setting runs fairly deep. In fact, you can see that we set the operating system context. If you launch the Resource Monitor tool in Windows 7 (which just reeks of Mark Russinovich, so I know he had some hand in it), you can add a column to display the Operating System Context:

image

What we have put in place is a mechanism by which we can make specific changes to the OS, target the fixed ones at those in the current operating system context, and target the old behavior at applications designed for previous versions. We can use this metadata, if we have it, for all kinds of application compatibility solutions – from switchpoints (introduced in Windows 7) to future implementations of lightweight virtualization.

But this all hinges on people adding the manifest section to their applications. (Which, of course, means we need to work with tool vendors, including our own.)

But one question which I had:

What the f* is with the GUIDs?

We’ve just never made versioning easy. GetVersion was hard to use. GetVersionEx was easier to use, and easier to use wrong. VerifyVersionInfo was a good idea, but too hard to use.

And here we go again.

The argument for GUIDs: Nobody knows what the GUID for Windows 8 is going to be yet. Not even us. So, by using GUIDs, we prevent somebody from claiming compatibility with an operating system they can’t possibly have tested with. (Odd that we’d be so against such a thing in one group, while the IE team gives you the X-UA-Compatible option of edge to do exactly that.)

The argument against GUIDs: You’re punishing the good guys in order to prevent the bad guys from shooting themselves in the foot. If I test something on Windows 8, and add its GUID to my manifest, I’m going to get both the Windows 8 and Windows 7 fixes (since the OS will simply look at the highest version and apply all previous fixes). But, if I *only* put in the Windows 8 GUID, on Windows 7, I won’t recognize the Windows 8 GUID (since it doesn’t exist yet), and not only will I not give it the Windows 8 fixes, I won’t give it the Windows 7 fixes either. And, if the only fixes I actually needed were the Windows 7 ones, I just broke the app.

Oy. Can you tell which side of the fence I sit on? Then again, the counter to that is, if I had tested it on Windows 7, I could easily add that GUID as well, and all becomes right again. It just means that people have to understand that including any and all GUIDs from tested operating systems is important.

So, here I am writing that.

In addition to specifying the target version, you should specify every version that you’ve tested on. Right now, it doesn’t make a whole lot of difference (since Windows Vista isn’t even looking for this section of the manifest) but the more you can tell us, the more work we can do to help keep your application working in the future. And anything that can help us keep your application working into the future definitely makes everyone more happy. I’ve got my fingers crossed that this gets some uptake…