There is a huge amount of excitement about Windows 7, and people are looking to get moving with app compat immediately so they can start deploying Windows 7 right away! In the enterprise, however, there are a number of risk mitigation strategies that most administrators put into place, which typically includes (among other things) ensuring that the most business critical applications are supported on Windows 7 by the vendor.
We have tried to simplify the process of finding these support statements by creating a portal site, making this list downloadable, and integrating it into the Application Compatibility Toolkit. People like this so much that, an average of around infinity times a day, I’m asked when it’s going to be updated for Windows 7.
It is scheduled to be updated for GA (General Availability). That’s October 22, 2009.
What’s with the delay?
Well, a couple of reasons.
First of all, “compatible” and “supported” are two different things. What matters to most people is supported.
Before most software makers support an application, they test it pretty thoroughly to ensure that there are no significant bugs that could expose them to major risks and/or higher than acceptable support costs. This takes time. Now, we’ve been giving ISVs access to builds for quite some time, and they can use the interim builds to perform software testing and identify any significant issues which will require quite a bit of time to resolve. However, the ISV can’t even begin the thorough testing to ensure that they have a supportable solution on Windows 7 RTM until they actually had access to Windows 7 RTM. So, the same day that many enterprises were able to get that build and wanted this data, ISVs received it and could start their validation for supportability. Being able to instantaneously tell if you can afford to support your software on a given platform is asking rather a lot of any ISV. This gap between RTM and GA provides each ISV a brief window of time to perform thorough testing before customers can reasonably demand to know a support statement.
We then also leverage this time to reach out to those ISVs and find the support statement. You see, ISVs don’t have to report in to us when they make new software or create new support statements – in fact, they never have to call us at all. We tried changing the nature of this relationship once with the Works With Windows Vista logo program, and it was a colossal failure. So, in addition to an ISV needing time to test and validate something, we also need time to find these results and support statements and consolidate them into the database which you can access.
So, we both have a lot of work to do in order to get these lists put together, so much so that 3 months is really kind of stretching it. I know of several vendors already who are pushing out their supported dates for Windows 7 into 2010. What do I do when I find that? I debug their apps. It’s much easier to fix and support an app once the hard part – debugging it – is already done.
Now, compatible is a different story. If you want to be a purist, compatible means it has no bugs on the given platform. Since no bugs on a given platform is, for this purpose, the same as saying no bugs, I can safely say that there is no compatible software for any platform that has ever been made. So, we’re forced to use a different definition – compatible meaning that there are no bugs that *stop me from getting my work done* on a given platform. So, since nobody else knows precisely how you get your work done, the only person who can fairly answer that question is you.