Moving people off of older browsers onto newer ones is something we have been pushing hard for at Microsoft. The latest version of IE is significantly more secure than older ones, and way more interoperable. (Who really wants to develop 2 websites when they really only want one – one for some crusty old version of IE, and another for everything else?) However, historically, upgrading the browser had a very pronounced install experience – it felt like a really big deal, and was pretty scary. My mom, who by now has been trained not to install stuff as her default reaction, isn’t going to be aggressively looking for an install. She would get left behind on such an install.

So, to help reduce that friction, we’ve announced that we’re going to help keep people up to date automatically, to remove that install experience.Details are here: IE to Start Automatic Upgrades across Windows XP, Windows Vista, and Windows 7.

Now, my area of concern is the enterprise, where I also want you to have a modern browser, but I want you to have the chance to validate that you won’t have productivity failure when you do. So, we provide tools to block the install of Internet Explorer 9, Internet Explorer 8, or Internet Explorer 7 until you are ready. (Please, don’t forget to get ready – particularly if you are blocking IE7!) This will block the automatic upgrade, as well as the Windows Update suggestions.

What this will not stop, however, is web advertisements. And because we care about IE adoption, it turns out we advertise rather a lot. Users running older browsers, if they head over to microsoft.com/ie, will find this:

So, even though we stop users from automatically having an upgrade, we’re still putting the idea in their heads. And there is an advertising campaign which I’ve recently heard a couple of customer comments on: the web slice for the IE add-on center.

Here’s what it looks like if you are up-to-date:

But, if you are running an older version of the browser, it will suggest upgrading to the new one:

The feedback I’ve been hearing from the couple of customers who have reached out is that they want to block their users from seeing these advertisements and choosing to upgrade. How do they do that?

First, to point out where we see this – this is a default web slice, so the folks who notice it are those who run a lot of clean machines, so it’s far more visible to those in IT who look at clean builds than it is to end users who have had some time to customize.

It turns out that it’s super easy to block the impact of advertisements for IE9 and stop that upgrade:

Make your users non-administrators.

Not only is it easy, it’s the only effective way to do it. Even the blocker toolkit won’t stop a determined administrator of the computer. It’s inherently self-contradictory to ask how to limit a set of users to whom you have granted unlimited power. I worked with one customer who was sure that everyone was running IE6 and that nothing else would work. But, since they had local admins, some investigation led us to discover that they had an entire continent running an updated version of the browser, and that despite this they were still in business on that continent!

Which, of course, leads to plan #2:

Let ‘em.

Hey, if they’re admins anyway, you can be sure that there is all kinds of stuff on there that you haven’t explicitly approved of. (In my travels, I’ve come across one and only one software inventory which did not contain “World of Warcraft.” I’m just sayin’…) If they call helpdesk, just update the script to check the version of the browser, and ask them to downgrade if it’s not your standard and they want support. Otherwise, consider it free testing. What do you think happened to the customer’s perception of the risk of moving to the latest browser after they discovered that an entire continent already was? It went way, way down. If they are admins, they can do what they want, and no group policy is going to stop them. (Have you ever tried to block a policy from doing something? It takes under a minute – if you are an admin.) Pretending you are in control of local admins is not the same as actually being in control. If you need to actually be in control, see the first bullet above – making users non-admins.

Of course, some customers would prefer more options, and IE is, as usual, extremely friendly to the administrator. Another thing you could do:

Turn off favorites bar

Yep – if you make the favorites bar go away, then the web slices go away also. (It’s off by default in IE9 anyway, so perhaps it’s UI training?)

You could also block the URL, but that seems a tad drastic to me. You could also go after whacking the file - after all, it's just a shortcut called Web Slice Gallery sitting in the Favorites Bar subdirectory of the user's Favorites folder. A bit primitive, but it would get the job done.

In the end, it’s just an advertisement, but it’s a fairly visible one. The administrator will always be in control of that upgrade decision. If I can help you with web site readiness, I’m happy to do so in order for you to move forward as well!

Developers, and the people responsible for the productivity of those developers, have long known that code reuse was something we should aspire to.

Don Box, in his seminal book Essential COM walks through the progression we made in the Windows world around code sharing. I strongly recommend reading through the entire work (which I won’t reproduce here), but I’ll summarize the first few pages:

Writing everything from scratch is too expensive

First we have to overcome developer resistance to code developed by somebody else (which remains a struggle sometimes). But we achieved this, and the C++ language made this easier. Now, we could share code as libraries which you could re-use by simply calling into the classes that provided the functionality you wanted. Great news! But eventually we ran into a little problem…

Having a unique copy of this code for every app consumes too many resources

There was a time when we didn’t have 1TB hard drives and 8GB of RAM in our computers – we had to be parsimonious with these resources, and having many copes of a particularly useful library meant that we weren’t using these resources as wisely as we could. So, along came dynamic linking, which allowed us to share the same copy from disk, as well as to leverage tricks in the memory manager to back multiple instances in application virtual memory with a single instance in computer physical memory. Great news! But then we run into a bit of a problem…

There is a lack of standardization at the binary level

Once you try to link against a dll compiled using a different development environment, you may run into important differences, such as differences in how name mangling is implemented. That makes it difficult to have truly universal components! Plus, while C++ supports syntactic encapsulation, it doesn’t support binary encapsulation, and your application must know everything about an object layout in order to instantiate a class. No problem – we can solve that by dividing interface from implementation (they are joined by C++) so the layouts won’t change.

Carrying on (reading the remainder of the story is left as an exercise to the reader – a very valuable exercise), Don discusses runtime polymorphism, object extensibility, and resource management, to eventually engineer COM.

So, why I am talking about COM? Because I’m seeing something very parallel happening right now in the world of web applications…

Writing everything from scratch is too expensive

Developers are finally embracing this fact, and starting to reuse more than ever. We see this when people use weblog software to communicate, rather than writing HTML. We see this when people buy software which generates ecommerce sites for them. But, most analogously, we see it when developers opt for reusable libraries others have created to save themselves a lot of time re-implementing the basics. So, rather than write everything from scratch, more and more developers are using libraries such as jQuery. Great news! But eventually we ran into a little problem…

No, we didn’t run out of RAM or hard drive space (we’re in the cloud, baby!), but something else happened…

Having a unique copy of this code for every app introduced too much security and compatibility risk

If you recall back in 2004, you may remember the bug in GDI+ which affected a lot of applications. Now, had this been linking against a single copy, we could have just patched the operating system. But, alas, GDI+ is redistributable, so not only did we have to patch the OS version, but every application which chose to redistribute GDI+ had to ship its own updates. How many of those are there? Nobody knows for sure! By redistributing it, you know that you have it, and that it has a compatible version to your application, but you also take on complete responsibility for managing somebody else’s code as part of managing your application!

Alas, this is exactly the state we are in for web applications. If you choose to redistribute a library, such as jQuery, you are also choosing to take responsibility for keeping it updated. It turns out that there are a number of bug fixes you would probably benefit from. More importantly, browser support keeps changing. As new browsers are released, new bugs are surfaced and fixed.

The customers I work with are enterprise customers, and as a general rule enterprise customers love to standardize on things. If you standardize on an older version of jQuery, you’re limiting your ability to perform a browser upgrade without applications failing on the new browser. (If you swap out jQuery, you also have the potential for the application to fail because of jQuery incompatibility, though that probability appears much lower in my experience.) Even if there isn’t a mandated standardization effort, there is almost never a programmatic, organizational effort to track and update implementations of jQuery, and therefore this comes up regularly as app compat issues with block IE9 upgrades

How will we solve this one? I have no doubt that we will, given how systematic the potential problem is and the importance to developers and the industry in solving it. I suspect there will be several steps along the way, we’ll eventually come up with an elegant solution that at least one person can actually understand, and some even bigger change in technology will disrupt that work and we’ll be on to the next big thing. But, for now, you are accountable for managing this.

Are you aware that you are accountable, and are you managing it?