There are a number of terms thrown around in the world of app compat that are vaguely defined at best. Now, I’m not one to suggest that tedium is a good practice in general, but in some cases understanding the true technical definition of a term can lead to significant time savings when that definition is applied to a project.

Compatible is the most important one. What does it mean to call an application Compatible with Windows 7? (Some people refer to this as Windows 7 Compliant also.) I have found some significant variation in peoples’ understanding of this, and the wrong understanding can lead to you chasing unachievable goals.

At the most abstract, that means that it works with the target operating system. So, today you may know it is compatible with Windows XP, and you are questioning if it is compatible with Windows 7 as well. But all you’ve done here is shift the ambiguity from the word “compatible” to the word “works”, and then you think about defining what “works” means – interpreted by some, this could mean that it doesn’t have any bugs on that platform. But think about that for a second – do you really want to wait until an application has no bugs on a platform? Because, if so, you’ll be waiting a really long time – all software has bugs. So that clearly doesn’t work.

Some peoples’ perception is that there are a series of criteria to follow, and once you follow those, it’s “compatible” (and, therefore, bug free). Things like the Application Compatibility Cookbook, with its enumerated list, bolster that perception. But compatibility is not as simple as filling out a checklist. There are all kinds of things that could go wrong along the way that won’t wind up on a checklist. I have debugged an app that ended up in a race condition because of the assumption that a particular shell function would be executed on the same thread, and it no longer was (you won’t find that in the cookbook). Heck, even Solitaire had a really bizarre bug which was based entirely on computer speed (we didn’t used to have a timer on the “card cascade” if you won the game – we rendered those little cards just as fast as we could, which these days is pretty insanely fast, some would even say instantaneous). Those don’t show up on the list – and in fact there are a near infinite number of ways that an app can end up having a problem on your new target hardware and software platform.

So, my small, manageable checklist is helpful but incomplete, an infinitely long checklist is clearly no better, and bug free isn’t my goal – what are the standards that I usually apply as a matter of practical execution? I normally layer things into 3 groups:

Compatible with Windows 7: The application has no bugs which stop you from getting your work done. It may have bugs, but they don’t affect your business. In the end, this is all that matters to you! Note, however, that this also means that the only person who can verify this is you! An app may let somebody else get their work done (and, thus, to them is compatible) but the critical functionality you need might be the bit with the bug in it. The only way to tell is to try getting your work done using the application. (Incidentally, this is one of the shortcomings of static analysis – it finds bugs everywhere, and not just in the bits of the code that you use – but we’ll talk more about that in another post.) You should only invest time and money fixing the bugs that stop you from getting your work done.

Supported with Windows 7: The application is supported by the vendor on your platform. That’s fantastic, because it means that if there are any bugs which stop you from getting work done, the vendor promises to fix them. But a promise to fix them is not the equivalent of being compatible (using the definition given above) for, since all software has bugs it’s completely possible that some of those bugs will be in a place that is a problem for you. Yes, you have a path for getting them fixed, but your business is still disrupted, and that costs you money! So, I tend to view support as a great indicator (since the vendor wants to minimize their risk of high support costs), but I don’t take it as fully equivalent to my Compatible with Windows 7 definition when doing my risk / benefit computations. But, for many apps, this is a requirement right beside my compatibility requirement, depending on business criticality.

Logo Certified for Windows 7: The application is not only supported, but the vendor has passed a set of tests that ensure a high level of quality for the application. When I see a logo, I tend to see a vendor who really stands behind the product. Logo certified apps tend to crash less frequently (since logo certification necessitates tests which detect and require you to fix many causes of application crashes), and have higher quality across the bar. It’s certainly not exclusively true (you can build an extremely high quality app, and just not want to bother getting the certificate required to sign up for the partner program – the only cost you have for Windows 7), but it’s a good indicator. But logo certification tests do not prove an application bug free, so again, it’s not the functional equivalent of verifying compatibility for you, but it’s another good indicator of whether or not to fast-track an application.

It’s been a long road to get here, but the checklist is now complete. Vendor data for Windows 7 application compatibility, previously available on the web and as a downloadable Excel sheet, is finally integrated into ACT 5.5!

Here is some information on this data, courtesy of the team:

How many applications do we have data for?

We have data for around 7,000 applications. What is interesting is that there is more work than just 7,000 – each application may map to more than one app ID, and in fact we have data for around 38,000 distinct AppIDs. (Incidentally, if you don’t see data for an application in ACT but it’s on the web, this could be caused by repackaging, by interim releases we are unaware of, or a number of other things. AppIDs are very literal and require perfect fidelity input to deliver comprehensive output.)

How frequently will this data be updated?

Initially, ever 2 weeks, so make sure you sync ever so often to see the latest data. As the vendor input tapers off, we may reduce this in the future.

Will the data have complete parity with the compatibility center?

It’s the same back end, but since we use different AppIDs we have to use heuristics to match between the different AppID schemes. Heuristics, by definition, can be imperfect. Add to this the potential issues above (repackaging, lesser known versions) and this would explain any delta in the data. We’re constantly reviewing our heuristics and improving them, plus we have long term plans to consolidate on a single AppID scheme.

Will I see compatibility status for 64-bit applications?

Today, it’s just 32-bit status, as that is what ACT 5.5 supports. ACT 6.0 will support 64-bit Windows and include 64-bit compatibility status. It should be released later this year.

Congratulations to the team for achieving this long-awaited milestone! I know I have already synced up my database.