Interview with Dave Allen on Windows 7 compatibility

Dave Allen works in Microsoft UK helping partners build solutions which take advantage of the latest technologies from Microsoft. He also happens to be a mate, a jolly nice chap and is  leading our efforts in the UK to help partners get their applications working on Windows 7.

I sat down with him on Thursday of last week (23rd April) and quizzed him on the thorny subject of compatibility. Check out this companion post I did on resources for getting ready for Windows 7.

When did you first start looking at compatibility issues with applications?

I was lucky enough to do nearly a year with the Windows team focused on helping ISVs get their applications compatible with Windows Vista. I travelled to over 8 countries and delivered over 15 labs. That was back in 2006/2007. A few months ago I took ownership for the Windows 7 compatibility efforts for ISVs and as part of that I am delivering a number of multi day labs.

What approach do you take in the lab?

On day one I run through what has changed between Windows XP and Windows 7, how those changes might give rise to problems and how to track down the exact cause of problems and resolve them. The rest of the week is run as a clinic where we first aim to get the application installed and then get it to run. We are normally very successful – most applications can be made to work in a day or two.

“most applications can be made to work in a day or two”

Will an application that works on Vista work on Windows 7?

In the vast majority of cases yes. I haven’t yet come across an example where it didn’t.

Will an application that breaks on Vista, break on Windows 7?

Yes, that is also the case. There are some exceptions, especially if you compare Windows 7 with Vista with no Service Pack applied. In Windows 7 we have added more shims to help applications work without change.

Can you explain what a shim is?

Rather than use my own description, I will use one given by a software engineers that used to be in the Windows Product Group.

Shim Technology is an elegant technique that is used to fool some applications into running on versions of the operating system they may not have been designed for. It’s a method of 'hooking' the Win32 APIs that are called by a particular application program. Once installed, such hooks permit developers and support engineers to install alternate (stub) functions to be called in place of the original functions. The actions taken by the stub function comprise the fix for a particular application compatibility problem.

There is no shim SDK of course, as this would be a security risk allowing a developer to override any Win32 API call. A shim developer would also need to have understanding of all of the other shims so that they would not conflict with them, so the number of developers writing shims in the Windows team is very small and it’s defiantly not for the faint hearted. I wouldn’t call myself a Harry Potter fan, but shims should be considered one of the Dark Arts.

“Shim Technology is an elegant technique that is used to fool some applications into running on versions of the operating system they may not have been designed for”

If you have not yet got your application working on Vista, should you start with Vista or Win 7

It really makes very little difference. Personally I would recommend you started testing with Windows Vista as this is the currently released version of Windows. Once you are happy with this, test on Windows 7 and any changes you need to make should be re-tested on Windows 7 when the Release Candidate is available.

What is the first thing to try if an application doesn’t work?

Well it’s normally dependent upon the behaviour, but if it just doesn’t start, I normally try to run it as an administrator or apply the Windows XP SP2 Compatibility Fix as these take just a few seconds to try out and fix the majority of problems. Then it is just a case of finding out why they are dependent on running with admin rights or what their version dependency is.

Applications can have issues just being installed on a later OS. What is it that developers keep doing wrong?

They keep hard coding version number checks into their installs. You should instead check for minimum requirements. Check if a particular version of MDAC or .NET is installed and always check for greater than not just the exact version as Microsoft normally provide backward compatibility in later versions. Microsoft also allow developers to redistribute most major components, so if something isn’t installed that you need then just package the redistributable with your MSI.

“You should instead check for minimum requirements”

Has anything changed wrt User Account Control in Windows 7?

UAC is actually a collection of technologies but most people use it to refer to the prompt you get when running as a standard user and you need to give consent to a program that needs to run elevated. I’ll stick with that description for clarity. In Windows Vista this was a binary/boolean setting, you could either switch it on or off. In Windows 7 there are 4 settings, the highest and lowest settings are equivalent to those in Vista and the 2 intermediate settings reduce the number of UAC prompts required when an admin function is carried out.

What is the one starting point you would recommend for helping a developer get their application compatible with Windows 7?

https://devreadiness.org/ is the best place as it has some great content and links to everything else you will need

And finally, what is your favourite new feature in Windows 7?

I love the new Direct Access as it means I don’t have to use VPN anymore, which is great because I’m not based particularly close to a Microsoft office.

“(With Windows 7) I don’t have to use VPN anymore”

One last though, could I grab some more time from you later in the month to drill into these a little further?

Sure. In fact the next lab is later in May and you should pop along.

Excellent. See you there.