In the run-up to any operating system release, we start to see a lot of “world tour fever” and Windows 7 is no different. Windows has a huge partner ecosystem, and we want to make sure that we at least stand a fighting chance of helping you get it done by at least getting a little bit closer to where you are – and that involves collecting a few frequent flier miles.

June looks to be USA month, and I saw this come across my email, so I figured I’d share it. The Developer and Partner Evangelism (DPE) team is holding 4 events in June for ISVs:

June 1 – Mountain View, CA

June 8 – Reston, VA

June 15 – Alpharetta, GA

June 22 – Waltham, MA

If you’re interested in an opportunity to work with some of our engineers to test your application on Windows 7 (and get some help debugging it if it doesn’t work), you can register here:

http://www.msregistration.com/Win7USA

I’m not doing any of these myself, though I’ve done these events in Taipei and Tokyo and they’ve always been very enlightening and can start a great dialog. I hope some of you are able to attend!

ComputerWorld did a story on shims featuring my session from TechEd North America – check it out: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9133382

A while back, I posted about my experiences running at High DPI. Running Windows 7, I’ve been running High DPI for many months now, and I can no longer imagine going back. I had no issues with the technology.

So then I got brave. Yesterday, I decided to pull the trigger and set up my wife’s laptop with Windows 7 RC, and configure her with High DPI so that she wouldn’t change the resolution down to 1024 x 768 any longer. It took her about 10 seconds to find an issue with it.

“Why is everything so tiny on the login screen?”

Ah, yes. One unfortunate side-effect of having High-DPI be a per-user setting is that now you don’t have that setting apply to the login screen any longer. This was clearly unacceptable to my wife, so I had to root around and find some way to fix this. I figured I’d share in case it’s interesting to anyone else.

I went to the key:

HKEY_USERS\.DEFAULT\Control Panel\Desktop

And I added a LogPixels DWORD value, and set it to 0x78 (120 decimal) to set the DPI to 125% (120 DPI) on the login screen. Worked a treat.

Allow me to describe the typical scenario for a first time user for the Application Compatibility Manager component of ACT 5.5:

Get an inventory, press send/receive, discover that you don’t find as much data on there as you expected, then send an email to an alias (that I’m probably on) which either questions whether you’ve done it right or accuses us of being some variation of useless and/or incompetent. Then, you give up on the feature and feel indignant.

So, let’s review that history to get some perspective, and then talk about what we’ve done to improve things in ACT 5.5.

We know that we don’t want everyone to have to go to every vendor site in the world and look up everything that they own. Plus, you could discover that it isn’t supported, but what if you don’t care, and you just want to know if it works? So here’s what we came up with.

Plan A:

Let’s make a level of logo certification so darned easy that absolutely everybody would do it. We’ll call it Works With Windows Vista, and *all* you have to do is tell the world that you support the app on Windows Vista. Boom – you’re done. No third party testing, no checks to write for that testing, no requirements to meet. You support it, and we’ll tell your customers that you do. How easy is that? Everyone will do that, won’t they?

As it turns out, not so much. Based on the inventory I have of around 50 machines, it looks like it’s pretty much Microsoft and the Google Toolbar who will do that. Yikes. That’s … not … quite … everybody …

But not to worry, we have a plan B! (No, really, we did! We anticipated that there was some probability of failure!)

Plan B:

Hey, even if vendors don’t some to us in droves, we can still get the IT Pros of the world to share their experiences, right? We may not know if the application is supported, but at least we have some sense on whether people think it works or not, right?

But, as it turns out, human nature applies to … humans. Drat. What did the first person who hit sync find? That’s right – nothing! So, how much of a debt to “society” do you think this person felt? After they have voted on all of their applications, we’ve got to convince people to hit sync one more time, even though that time (the time that matters to the next person to come along) can do *absolutely nothing* for the person who is helping that person. With no sense of debt, it turns out this doesn’t happen very much. Unless, of course, you think 10 people using Adobe Reader is rather a lot (personally, I’m guessing their market penetration is slightly higher).

Well, crap – that’s strike 2. And we didn’t have a plan C.

The comeback

So, given that things weren’t shaking out quite the way we had planned (we hadn’t expected both ideas to fail quite as spectacularly as they had), we had to scramble to come up with Plan C. If the vendor wasn’t coming to us, and the people at large weren’t either, well heck – we’ll just hire some people to do the exact thing we were trying to spare you from: just browse one vendor site after another looking for support statements. So that’s exactly what we did. We threw all of that together into a website called appreadiness.com, and eventually we made a website that actually looked nice (like I said, the first go-around was our rush job because it simply wasn’t an option to have nothing) called the Windows Compatibility Center.

http://windows.com/compatibility

That works great when you want to know about one application, but what about when you need to know about all of the apps you have? Searching one at a time is better than searching one at a time on every vendor web site, but not by much.

So, we make things available to download – you can find “the list” here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9df23606-7276-4ce2-8993-143e101ddbcd&displaylang=en

One great big giant Excel sheet with everything we’ve looked up so far, and you can fuzzy match against them.

Initially, it was a crusty old one from appreadiness.com, but now we’re updating it regularly (hooray!). 8000 apps and counting.

ACT 5.5 Improvements

ACT 5.5 does that Excel sheet one better: it now automagically pulls in all of that vendor data and matches it up to your applications! (It’s most of the way done now, too – we just got this lit up in time for a demo at MMS.) So now, you can benefit from the group of folks whose job it is to do the searching on vendor web sites so you don’t have to.

We also revisited Plan B, because we still think that has a place (not everyone needs support for all of their apps, but it sure would be nice to know if it worked or not). Some of the biggest complaints we got?

“Even if I say not to send my vote on an app, you would send the fact that we have the app, and its mere existence is a trade secret.” Fixed – we now don’t even send the fact that you have it. (Of course, that also means you don’t get any vendor or community data, but if its very existence is a trade secret chances are it’s not commercial software anyway.)

“Wait – who are you quoting above that knows it sent the existence of the app? What is this thing sending anyway?” Fixed – you now have the option to preview the exact XML that we’ll send up, and you can inspect it thoroughly and audit what it’s sending to ensure that it’s kosher before you go syncing with a web service.

Are we there yet? Not completely – it still takes a lot of effort, because there is no one source for everything that is known anywhere on earth about any given app. But we’re trying to close that gap in ways that make sense to you. Keep giving us feedback, because we are listening, and reacting just as quickly as we can!

About a year ago, at TechEd IT Professionals 2008, Josh Hoffman and I were in a bloggers panel together talking about Windows Vista. (Windows what?) Afterwards, he came up to me and asked me if I could put together an article on application compatibility for IT Professionals someday for the magazine. Well, I sat on the idea for a while, and eventually decided to write something about managing the project, and then write a second article about shims.

Of course, before I got to writing about shims, my buddy Chris Corio approached me about writing an article on ACT, and I suggested doing a deep dive on internals for the new 5.5 release.

So, I never actually finished up that shims article, but the other two are published just in time for distribution here at TechEd 2009. You can read the online version here:

http://technet.microsoft.com/en-us/magazine/dd799202.aspx

The ACT 5.5 article, in particular, addresses questions that I end up being asked all the time. What’s really going on with those agents? What data are they looking for, and how? I’ve been giving talks on some of these internals lately (most recently at MMS) and it appears as if people are excited to finally have this information in their hot little hands.

Farewell, Josh, and Godspeed. It’s been an honor working with you. (Now, of course, I have absolutely no idea how to submit that shims article when I get around to writing it, since I always just shot email to Josh directly. And so it goes.)

Those of you who write application installers using Windows Installer may have noticed a bit of a change in the behavior of version checking in Windows 7 – if you happen to be doing your version checking from a custom action. Let’s have a look.

If you’d like to follow along, here’s what you need to do. Open up Compatibility Administrator. Expand the Applications tree (this could take a minute), and then start typing Windows Installer to quickly scroll down to this entry.

First, you’ll notice a few things which we expect. We’re shimming up msiexec.exe (meaning we’re shimming up every MSI package in the world) with WRPDllRegister, WRPMitigation, and WRPRegDeleteKey. These are all of the Windows Resource Protection shims – so if you have an installer that tries to overwrite kernel32 with some really ancient version, for example, it’ll get fixed up instead of failing.

There’s NonElevatedIDriver – that’s an InstallShield fix, for MSIs created by InstallShield. So far, so good.

Oh.

And there’s VistaRTMVersionLie.

Whazza – huh? (Double takes are completely appropriate here.)

That’s right, we’re shimming up the Windows Installer application to give it a Windows Vista version lie. What does this affect? Any DLL custom action you implement that does a check to GetVersion(Ex) is now going to think it’s getting Windows Vista instead of Windows 7. Do not pass go, do not collect $200, you’ll think you’re on Windows Vista.

However, any application that uses the MSI tables and takes a look at the VersionNT property will be told the correct version of Windows. So, on Windows 7, VersionNT == 601. Just like you’d expect.

From a pragmatic perspective, this improves the overall compatibility of installers on Windows 7 to a huge degree. We did this to systematically fix apps that refuse to install on anything greater than Windows Vista. And it succeeds at this spectacularly.

From a "bonus side effect” perspective (if you like to think that way) – it does serve the effect of pushing people towards using the declarative method of checking versions in the MSI tables, which is our recommended way of checking for specific versions.

Not only is it recommended, it’s the only sensible API we have for checking a version. The others are really hard to get right. How would you check to see if a version is greater than or equal to a specific version? Well, GetVersion returns something really strange until you yank it apart (Windows 98, for example, is 0xC0000A04). How obvious is this?

dwMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));
dwMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion)));

OK, so that’s a little silly, and GetVersionEx has a structure that simplifies this. But even with the OSVERSIONINFO structures, you can do things wrong. For example, say you want to check and see if somebody is using at least Windows XP. You could easily do that as:

if (osvi.dwMajorVersion == 5 && osvi.dwMinorVerison == 1) {…

And of course that will do the trick while Windows XP is the only thing around that it works on, but as soon as we release a new version of Windows, it breaks. But let’s say you’re trying to get it right, and you ordered one of those fancy computers whose keyboard actually has a “greater than” key – you could still lose the logic. I’ve seen this many times:

if (osvi.dwMajorVersion >= 5 && osvi.dwMinorVersion >= 1) {…

That’ll work on Windows XP, break on Windows Vista, and work on Windows 7. It’s the wrong logic. Here’s what you’d have to do:

bIsWindowsXPorLater = ( (osvi.dwMajorVersion > 5) || ( (osvi.dwMajorVersion == 5) && (osvi.dwMinorVersion >= 1) ));

And now we’re complex again.

BUT – with the MSI tables, you can actually use the > key with ease. VersionNT >= 501 will work for Windows XP or greater – for anything we release into the future.

It’s declarative, so you can see the check. It’s easy to get it right. It’s got a lot going for it. Nevertheless, I’ve still seen a lot of people doing things like:

VersionNT = 500 OR VersionNT=501 OR VersionNT=502 OR VersionNT=600

I wonder what they’re going to do for Windows 7?

Now, of course, from the ivory tower we’re always saying “don’t check versions” and we don’t hear the cries that you have to. In the end, it’s a business decision, and I don’t begrudge anybody for saying they can’t afford to test and support something indefinitely on every permutation of system. That’s hard to do. I know you’re going to check for versions. But, there’s an arms race between app compat and the people who want to do the checks. There has even been a suggestion that we *never again* change the version of Windows. I think that’d be downright silly. There are valid business reasons to know what you’re running on.

For example, I’ve got a conversation with a customer going on right now where they work on Windows XP, fail on Windows Vista RTM, and work on Windows Vista SP1. Stuff like that happens. (And, since they were checking from a custom action, they were refusing to install on Windows 7, because they thought they were going onto Windows Vista RTM, where they were known to fail. Ouch.) Ideally, this would use the MSI tables to exclude known bad versions, rather than the unknown.

What I’d like to see is a way to declare supported versions in addition to known bad versions. A known bad version should be blocked – let’s be sensible here. But an unknown version, well if you let it install smoothly, then depending on your relationship with the customer would that indicate a suggestion of support? If it could give some sort of warning “note: this operating system is not supported” but still run, then app compat doesn’t need to come along and remove the launch condition or custom action or verlie the entire framework just to keep apps running.

I get what you’re going for, but I also get that people want their apps to work unless there’s a technical reason why they don’t work. Even if they’re unsupported. Because, for some people, that’s OK. Particularly consumers, many of whom don’t have a lot of money right now to be buying new stuff. Just dazzle them with amazing new features, and they’ll buy it, but people don’t like buying stuff just because you said “don’t work on the fancy new OS that your new laptop came with.”

And so it goes.