Vista Support

Supporting Vista has been a pain in the royal ass.

Version 10.0 of Zango's toolbar and advertising client is due out next week.  Our dev teams in Bellevue, Montreal and Tel Aviv have been working on this release since last November, and by far the biggest headache in the entire dev schedule has been supporting Vista.  These days, Vista users make up about 5% of the folks coming to Zango.com.  That's not a huge number, but because we can't support them, it doesn't take a math genius to figure out that we're leaving money on the table.  So we're rushing to get them support as quick as humanly possible.

 Now, of course, we've all known that Vista was coming for a long time, and if you cared to make the argument that, really, we should have been ready back in January when Vista shipped, I'd have to agree with you.  There are three main reasons why it's taken us this long.

1. We got started too late.  At some level, this was intentional: from last June through November, our client dev team was focused like a laser on integrating the different Hotbar and Zango product offerings in a way that would actually make us some money – and I'm proud to say that we succeeded nobly.  But it left us rather behind on our roadmap.
2. It was harder than we thought.  Nobody on our team had ever supported Vista before, so nobody had the slightest clue how difficult it would be.  (Is it bigger than a bread box?)  It shouldn't be any big surprise to learn that our estimates were fairly optimistic.  Back in November, we thought we had a reasonable chance of rolling this thing out in February or March.
3. We threw too much in.  We couldn't quite stand the thought of waiting four months without any user-oriented features, so we decided to add the ability to cross-promote content across our brands.  That may have been the right call, but it added another two months to a project that was already larger than it should have been. 

So why has Vista support been such a pain?  The biggest problems, and the most headaches, have resulted from the new security model. In Vista, each process gets launched with either a "High", "Medium" or "Low" level of protection.  By default, unless you turn off User Account Control, all processes are launched at the "Medium" level of protection.  But because IE has been subject to any number of severe security holes over the years, and because Microsoft apparently doesn't think that will go away anytime soon, IE (by default) will run in "Protected Mode" for any URL from the Internet zone.  Microsoft has a fairly detailed discussion of Protected Mode here.

Here's just one example of why this is such a pain.  Long ago we architected our search assistant to run in its own process.  This master process (ZangoSA.exe) communicates with a DLL loaded in IE, and periodically uses the IE COM interface to launch ads in new instances of the browser, sized and positioned correctly.   The problem is that on Vista, ZangoSA.exe runs – and necessarily runs – at a medium integrity level. And because IE's Web Browser object is an activate-as-activator object, the browsers ZangoSA.exe creates with CoCreateInstance() also run at medium integrity. When a browser created this way navigates, and figures out that it should be running in Protected Mode (but it isn't), it hands the navigation operation to an instance of IE that is running in Protected Mode – creating such an instance if one doesn't already exist. At this point control over the navigating browser is lost.  No, honestly, this is how it "works".

Fine, we thought: we'll just create the browser in Protected Mode to begin with, there will be no need for the aforementioned bait-and-switch, and the problem will be solved. Well after scouring the posts on MSDN and working with Microsoft we discovered that starting IE in Protected Mode via CoCreateInstance() isn't possible today. You can start IE running as a low integrity process this way, but IE running with low integrity and IE running in Protected Mode are not the same thing: even a low integrity instance of IE does the bait-and-switch to an instance in Protected Mode.

Suffice to say, the good folks at Microsoft hadn't precisely thought this one through.  Sigh. (I recently wrote about the dangers of feeling self-righteous.  All that applies here.) They swear that it'll get fixed in the next release of IE – an assurance which isn't as helpful as you might think.  We came up with a workaround eventually (IELaunchURL()), but it's ugly, shows a nasty flash of IE before resizing it, and in general doesn't behave like we'd want.  We'll keep looking for a better solution, but we're going with this one for right now.

So: I was able to explain the above in about three paragraphs.  But figuring this out – and figuring out that there wasn't any solution down this path – took the better part of a month.  And when you add in all the other security issues (typically, bizarre IE dialog boxes offered up in strange situations, sometimes reproducible, sometimes not), and all the code that suddenly crashes under Vista that never crashed before, or breaks due to the new security model . . . and that's at least two months out of our seven month project.

A part of me understands why Microsoft made the changes that it made in Vista.  But a heads up to anyone else out there: supporting Vista isn't like moving from Windows 2000 to Windows XP.  This is a new OS, from the ground up, and the fact that it uses what looks on the surface like the same API shouldn't fool you.  Vista represents a change at least as substantial as when MS moved from Windows 3.1 to Windows NT, and you should expect a similar level of compatibility issues.

The good news is that we're now at release candidate status.  Unless we find something else substantial over the weekend, we'll be releasing next week.