Why not just require each application to declare what version of Windows it is compatible with?

Via the Suggestion Box, Arno Shoedl asked, "could not a lot of compatibility problems be solved by simply declaring (via manifest?) the earliest and latest version of Windows a program has been tested to run on?"

Actually, programs already declare that, sort of. Each module has a subsystem field in the header that specifies the earliest version of Windows the program will run on. There isn't a corresponding way to declare the maximum version of Windows you want to run on, however, so the manifesty thing could be done there. (There is a new manifesty way of saying what version of Windows you would like to see.)

But let's look at the bigger picture: In order to benefit from this proposed feature, an application author would have to do some extra work to declare in a manifest what versions of Windows they prefer to run on. That's already a bunch of work that gets in the way (because to an application author, any amount of work greater than zero that doesn't correspond to business logic is "a bunch of work that gets in the way"). Which means most people won't bother doing it.

So you're back to where you started.

Even if we could somehow convince application authors to get off their butts and do things that do not benefit them personally (like all the other programming taxes), that won't help all the programs out there that don't have any such manifest.

"Okay, well, let's just say that any program that doesn't have a compatibility manifest is treated as compatible with a maximum of Windows 7."

Great. Where do you put the manifest for a batch file?

There's a bigger problem, which is applications which are built out of DLLs. What if an application is manifested as "I have been tested only on Windows XP" and it loads a DLL that is manifested as "I have been tested only on Windows Vista"? Now there is no version of Windows that both the application and the DLL have been tested with together. What does GetVersion return? Even if your program doesn't have a plug-in model, you're not out of the woods. If you call ShellExecute or GetOpenFileName, the shell namespace will get loaded, and with it all sorts of shell extensions who may be manifested all sorts of different ways.

And then you have the cross-process communication problem. Suppose you drag an object out of a program marked as I was tested with Windows 7 and drag it over a window that belongs to a program marked as I was tested only with Windows XP. How do you communicate this information back to the data source so it knows "Be very careful. You're from the future. Don't tell that process about any data that didn't exist in Windows XP. You might disrupt the time stream."

Another problem, of course, is that just because a program says that it has been tested on Windows XP doesn't mean that it's actually going to run on Windows XP. There are many categories of bugs that appear only on configurations that were unusual on Windows XP but more common on later versions of Windows. (For example, "My user profile isn't in a directory called Documents and Settings.") Even if a program says that it was tested on Windows XP, that doesn't mean that running the old Windows XP operating system code is enough to keep it happy.

And of course there's the question of whether you want this in the first place. If we had introduced this model back in Windows 2000, by the time you have reached Windows 7, you could have a screen with applications that have three different visual styles: A program manifested as being tested only on Windows 2000 would have the Windows 2000 look, another program would have the Windows XP look, and a third program would have the another program would have the Windows 7 look. Even better: When Windows 7 came out, no applications would have the Windows 7 look since the manifest couldn't declare that it was compatible with something that didn't exist.

Looking at it another way, the manifest is basically a way for an application to say "Please run me in compatibility mode." But as we saw before, application compatibility layers are there for the customer, not for the program.

Bonus reading: Manifesting for Compatibility on Windows 7.

Comments (21)
  1. Dan Bugglin says:

    Not to mention pretty much everyone would want their programs to say "I can run on all future versions of Windows!" pretty much putting us back to square one anyway…

  2. Leo says:

    Firefox has this in place for extensions. It's very annoying, as I can't move to the next major release until the authors of the extensions I depend on have gone through their manifests and declared compatibility.

  3. Morten says:

    Because it is seriously borken for a program to try to predict stuff about the future? I remember a game, XXX by name, written for Win95 (AFAIR). It refused to run on 2000 because "this game is not compatible with Windows NT". D'oh. With suitable hacks it ran anyway but it was a bother. Seriously not smart to put that kind of constraints on your program.

  4. Marquess says:

    And really, isn't it the operating system's job to be backward-compatible instead of the applications being forward-compatible? Yes, Linuxers, I'm looking at you.

  5. Ivo says:

    @Marquess – the OS should be backward-compatible with well-behaved programs. A program that hard-codes "Documents and Settings" or pokes into specific controls of system dialogs is not well-behaved :)

    Of course there's nothing wrong with writing apps that depends on certain OS version. I do that all the time. However the app should still handle incompatible versions gracefully and fail in a user-friendly way.

  6. asf says:

    Lets not forget the fact that Visual Studio will not even allow you to create a program for anything < NT5 these days because it forces the subsystem version

  7. Gabe says:

    I remember that DOS utilities used to check the version of DOS they were running on and refuse to execute if it wasn't the version they were shipped with. Back before hard drives were common you couldn't expect all DOS utilities (like FORMAT and FDISK) to always be available, so it was handy to keep your favorite ones on the floppy disk you carried around with you. Since the DOS 3.3 FORMAT wouldn't run on DOS 4.0, though, you had to carry around a separate floppy for each version of DOS you expected to encounter.

  8. blah says:

    Since we mentioned DirectX…

    The best way to help compatibility is to ensure programming against interfaces instead of implementations. The rest of Microsoft could learn a thing or two from the Direct3D team. The D3D debug runtime is very good at filling buffers with garbage and validating every last function call with trace output.

    Honorable mention to AppVerifier, and the Visual C++ library team for things like checked heap, iterators, and comparators.

    The most ironic part of all this is that the first 1% of effort in automated sanity checking kills 90% of the most embarrassing blunders that Microsoft bends over backwards to maintain compatibility with. Provide developer versions of all API components. Virtual PC images of Windows with highly nonstandard configurations. Tighter integration of this stuff into the development process. And keep the most fundamental low-overhead checks in retail.

    Instead, we have important bits like the shell that contain more compatibility hacks than actual implementation.

  9. Hans says:

    Would be nice to see a program which declares minimum and maximum of user level it agrees to rum with, though.

  10. James says:

    @Gabe: But back in the DOS days, you could carry around a bootable DOS floppy with the utilities you wanted.

  11. Marquess says:

    @James Schend

    There is more than one. Boy is there ever.


    Support for Windows NT 4 has run out several years ago. Support for Windows 2000 ended this year, after the release of VS2010. I wouldn't be surprised if the next version dropped it.

  12. Skyborne says:

    "Don't tell that process about any data that didn't exist in Windows XP."

    This would also rely on the Win7 programmer *knowing* XP-land well enough to even be able to try such a thing; and that doesn't even take into account the effort required to *write* the code to be that careful.  The possible pool of developers who could, and would, do such a thing correctly is vanishingly small, even before it's pared down by the cruel reality of schedules and cost/benefit ratio.

  13. James Schend says:

    Morton: I know exactly what game you're talking about. (Unless there's more than one.)

    Their installer made the baffling assumption that DirectX would never be ported to Windows NT… what it *really* was looking for was DirectX, but instead of asking whether the system had DirectX or not, it just declared it didn't because it was NT.

    Sadly, people in web dev used to do this all the time. "I can use XMLHttpRequest because document.all exists." Uh… no. If you want feature X, check for feature X… don't check for unrelated feature Y and assume all systems that do Y also do X.

  14. Drak says:

    'and a third program would have the another program would have the Windows 7 look'

    Seems like one thought ran over another there Raymond :)

  15. James Schend says:

    @blah: You could ship all of those things, but that's not the problem– as you said, MS already has really good debug tools that cover 90%+ of the issues.

    The problem is, how do you get the slacker developers to run them? Or, how do you get the *real* slacker developers involved in the community so they know it's even something they should be doing? People who read this blog aren't the problem, it's the hundreds of thousands of programmers who aren't discussing things like this that are.

  16. Morten says:

    @James Schend: I've only ever met the one but then I'm not much of a gamer. But yes, it was the installer wot did it now you mention it.

    @Raymond: sorry, I didn't think when I put that name in (even though the franchise is quite dead). The upside is that now your blog shows up when people search for XXX. Enlightening the world one surprise at a time… ;-)

  17. Wilczek says:


    One thing crossed my mind when reading "…the Windows 2000 look, another program would have the Windows XP look, and a third program would have the another program would have the Windows 7 look…".

    When I create a button using CreateWindow the visual themes are not applied on the button. Is there a "flag" that enables visual styles on controls or rather a separate call? On the other hand, when I use MFC and CButton visual themes are automatically applied. Where is the "magic"? :-)



  18. Nemo says:

    I don't get why the visual style would have to affected by the compatibility flag.

    [You're joking, right? -Raymond]
  19. Scott says:

    Now now Raymond. Nemo will think you're picking on him. Not everyone has had to deal with versioning problems. That's why some job postings specify that you have to have dealt with it. A lot of programs never have to touch files from older versions. You have to learn the mindset to think through the problems changes cause. That's why web companies, which rarely had to deal with versioning issues, have had so many problems when they create APIs.

  20. Dave says:

    >A program manifested as being tested only on Windows 2000 would have the Windows 2000 look,

    >another program would have the Windows XP look, and a third program would have the another

    >program would have the Windows 7 look

    Wasn't there another one in there between XP and 7?  Or is that like Crazy Cousin Bob, the one we don't talk about?

    [I think 3 was enough examples. I left out the Windows 95 look, the Media Center look, and probably some others. -Raymond]
  21. 640k says:

    First rule of this blog: Don't mention vista. oops.

Comments are closed.

Skip to main content