What is probably the most common question I get regarding application compatibility?
"Can you just give me a list of all of the applications that work on Windows Vista?"
Sounds easy, huh? Well, it's not quite that easy.
First of all, there is the obvious problem of claiming that any software works at all. If anybody can come up with a full proof way of proving that any piece of software at all is bug-free, then that person is going to be very rich indeed. Even if we fully test software as we would use it, that doesn't mean we use it how you would use it. If I use some CAD software to design houses again and again and it works flawlessly under a huge amount of testing, what happens if the bugs exist when you use it to design something very small (like a screw) or something with a lot more vertices, such as a piston engine? We just don't know.
You would be surprised at how many "compatibility problems" I have investigated where, after uncovering the root of the problem, I can say definitively that the software could have never worked on any operating system. Sure enough, we run it on their current operating system, and it doesn't work there either.
Since you can't effectively just have people imagine how to use something and test it that way, our idea was to enhance any testing and bug submissions that we investigate with a community feature, which we added to the Application Compatibility Toolkit. But it turns out that this was harder than it seems. Why?
Well, first of all, people want this data when they're getting started. So, while we would exchange your votes for other peoples' votes, most people would perform this exchange before they had voted for anything. So, you'd exchange your "I don't know yet" vote for what we had out there. And how many people would go back at the end to send up their votes after they were done testing? Well, quite a few actually, but not as many as everyone would like. So that's one challenge.
But the bigger problem is that the majority of enterprises don't really much care if it works or not if, when something does go wrong (remember, works doesn't mean bug free), they call the vendor and the vendor will just hang up on them if you're using Windows Vista. They want "works" and "supported".
(This is another conversation I have a lot. "Can you figure out how to get this to work." "I see that this software directly controls your company's finances - if it takes some shims to work, are you really going to want to run it that way?" "Oh, no, it has to be supported." "Then why are we bothering to fix up this version?")
So we had another idea that we thought was quite clever. We already had infrastructure in place to allow our partners to certify an application as Certified for Windows. So, why not just leverage that. But, instead of making you pass a set of quality and reliability criteria that needs to be verified by a third party vendor (oh yeah, and that costs money), why not just let the partner self-certify that it works and that they'll support it on Windows Vista? Let's make it so easy that everybody of course would do it.
Except, of course, they didn't. We did make it super easy, but we were a middle man that not every partner saw as necessary in the equation. They already have a relationship with you, why do they have to tell us? And it probably smelled a little "official" what with the standardized logo and all. So, despite being a pretty good idea, it didn't get the uptake it needed to be super useful either.
Two good ideas, and still not a whole lot of data. Hrph.
So, we had another idea. If not enough people are coming to us, we'll go to them. So we hired some folks to go ferreting around vendor web sites looking for statements of support. Hey, we're the ones who have the shiny new OS, we're happy to do the legwork. And that's what we're still doing. Taking the existing Works With and Certified For data, and for the rest, scouring our partners' web sites looking for support statements. If they have one saying the support Windows Visa, we'll tell you about it, and give you a link so you can go and see it yourself!
And hence http://www.appreadiness.com/default.aspx was born.
(We have also added a new Community section to appreadiness.com to try and capture some of this.)
But, if you're not using ACT, you can get 2 out of 3, and we're still working on it. We're working really hard to push out any data we can to help you out. There's no reason for everyone to do the same web searches - we'll do it once, and let you get it from there.
One caveat I would add - there are no stipulations on what can go on this list regarding the configuration they support. The developers could say it's supported on Windows Vista only if running as full admin with UAC disabled. They could say it's supported on Windows Vista only if you run with a certain security policy. And, if your standard image doesn't allow you to run this way (say you are targeting a standard user desktop, which a lot of people are now that we have so much great support for standard user mitigations in Windows Vista) then perhaps you don't want it supported *that* way - you'll want to read the support statement we link to in order to really understand it.
How are we doing? Is this the list you want? When we get this fully tied in with ACT, are we getting closer to what you need? Is this list enough? How could we do better? In an ideal world, exactly one person would have to investigate compatibility, and the rest of the world could leverage that knowledge. I don't think we'll ever get to the ideal, but I think we're a lot closer now to keeping this at a minimum and letting you just verify the scenarios that are important to you as well as assessing the level of vendor support.
Because we want to give you "the list." Even if it's hard work.