The Virtual Life: IE At Arms Length

The IE team was kind enough to invite me to a small launch party last night, and while there I ran into someone who was asking how you do “real work” on IE. It’s a strange enough thing for a webdev to say, but the setting made it that much more interesting. I guess there’s a whole generation of webdevs who would like to put their heads in the sand and pretend that IE doesn’t exist. Getting to a productive point when debugging hard problems on IE requires a good toolchain. Here’s my setup.

The basic pieces are:

  1. A high-end mac laptop, stuffed to the gills with RAM and a fast HD. Sadly the MBPs max out at 2GB of RAM today. It’s a significant limiting factor when trying to work with multiple VMs
  2. A fast external storage device of some sort. In my case, that’s a samba server with a half terabyte of soft-RAID’d disk on switched gigabit ethernet
  3. Windows licenses. I use both Win2K and XP. I recommend older if you can get it, just because the older the Windows version, the less RAM the OS will soak up. Configure your VMs for the minimum operating memory you can get away with, you can always bump it up later.
  4. Virtualization software. These days I’m using Parallels, but previously I’ve used both VirtualPC and VMWare. They’ll all get you where you want to go so long as you can quickly make VM clones.

Before I get into the process, it helps to know that I’m not just making VM clones for the hell of it. Yes, there are things floating around that purport to let you run IE 5.5 alongside IE 6.0, etc. The fact of the matter is, though, that these aren’t what your users are running. IE isn’t built like Mozilla or any other browser. It really is down into the core of the OS because many of its behaviors are determined by the available versions of other components. Take, for example, the networking and javascript stacks. These are the cause of some very critical deployment-time bugs, but their behavior is determined by the versions of winsock and the Windows Scripting Host that are installed in the host OS, not the “IE version”. This means that if you’re not running the same version and patch-level of Windows, you’re not running the same browser that your users are, and if you’re not running the same browser, you can’t debug the problem or come up with a workaround. To accurately debug issues, you need to be able to step through OS revs, not just rendering engine+browser chrome updates. And as if that’s not enough, major Microsoft partners maintain their own IE builds. Getting reports of a problem that only shows up on Dells? There’s a reason for that. In cases like this, there’s really not much to be done short of buying a POS dell, but we can at least cover most of the rest of the strangeness we see in the wild with virtualization.

As for the choice of Mac, you can try to get away with something else, but if you support Safari or Mac users in general, it pays to have something that can run not just Safari, but all of the other mac versions of the various browsers your organization might care about. That, and OS X is the best desktop Unix available on the market today (sorry Ubuntu, you’re not quite there yet).

Here’s how I set up my environment:

  • Create a new VM. In it, install/register/jump-through-MS-hoops for the baseline version of the OS(es) you’re going to be using. Don’t even think of running windows update or installing a service pack yet.
  • Configure the VM to use the right local networking setup
  • In this new VM, install the Microsoft Script Editor, Ethereal, Drip, the MS web developer toolbar and whatever other debugging tools you use universally when debugging for IE
  • Shut down this VM and copy it off to your mass storage device. Give it a name like “XP_baseline”
  • For each OS Service Pack, do much the same thing. Install the service pack (avoiding browser upgrades if possible), shut the VM down, and pickle it off to cold storage
  • Once you’ve got a VM with a pristine version of the last OS service pack, start doing the same thing, but with major browser revs. If you can’t find an installer for a particular IE rev, try the Evolt Browser Archive.
  • At the end of the last step, you should have a “mostly” up-to-date version of both OS and browser. Once you’ve got a copy of that in cold storage, only then should you run Windows Update. Mmmm…watch that VM reboot!
  • This is now your “working VM”. Keep it on the local disk for on-the-go development and debugging. Also, keep this VM patched as MS releases updates.
  • For each new major browser rev, do NOT use your “working VM” as your baseline. Instead, pull your last major browser/OS rev snapshot out of cold storage, copy it, upgrade the copy, and put that back in the drawer

At this point, you’re going to have ton of space eaten up on your external drive with VMs that you might only use very occasionally, and that’s OK. Disk is cheap and if you’ve done stuff the way I recommend, your vms are probably going to be less than 3GB in size each. Should you make the mistake of installing, say, VisualStudio then at least disk is still cheap. At this point, you’re set up to respond to the thorniest bugs, and do it faster and more accurately than your co-workers/competition.

Need to test something on IE 5.5? No sweat, just thaw out that VM and give it a whirl. Clients reporting a problem on IE 6 that you can’t reproduce? Try the “naked” version of IE 6. Odds are you’ll be able to reproduce it there, and with some binary-search style patch application, you can pinpoint down to the individual hotfix when things got fixed.

At this point I should probably disclaim any and all liability you might incur with regards to your Windows EULAs. I’m not advocating that you violate your licensing terms with Microsoft, and depending on your agreement with them, you might be required to do something in addition to these instructions in order to stay in compliance, despite this really being a workaround for Microsoft’s design-time failures. Follow this recipe at your own risk.

5 Comments

  1. Posted October 20, 2006 at 1:11 am | Permalink

    I am literally in the process of doing this myself; bought a MacBook Pro last week, and I’ve been setting up my Parallel installs, including an Ubuntu Linux one to test on Linux. I wasn’t planning to have as many versions of the VM as you do though; just a Windows XP + SP2 + IE 6, and another one with Windows XP + IE 7. Do you really think it’s necessary to have more fine grained versions than that?

    It was great hanging out with you in Europe at EuroOSCON by the way!

    Best,
      Brad

  2. Posted October 20, 2006 at 8:00 am | Permalink

     

  3. Posted October 20, 2006 at 2:29 pm | Permalink

    Damn. I thought I was a browser geek :s

  4. Posted October 20, 2006 at 4:33 pm | Permalink

    Brad,

    Whether or not your need all those snapshots is kinda your call. I’m a bit lazy in places, but generally I have at least the pristine OS versions and the major browser revs available. Having more snapshots just saves you time when you’re in the thick of debugging things. There is some overhead for keeping VMs up to date with your virtualization software, so having too many snapshots can be a pain. I think at a minimum, you should at least have the pristine OS revs stored. It’ll at least save you the time to run a full install when the shit hits the fan.

    Regards

  5. Scott
    Posted October 21, 2006 at 4:15 pm | Permalink

    Hey Alex,
    I posted this on Ajaxian,  This may help.

    How to run IE V7 RC1 in standalone mode.
    http://tredosoft.com/IE7_standalone

    How to install multilple version of IE ( IE3, IE4.01, IE5, IE 5.5 and IE6 )
    http://tredosoft.com/Multiple_IE.

    Tom Trenka from dojotoolkit said the following:

    Scott, you missed the point: it’s not enough to run multiple versions of IE in the same OS, since a lot of the functionality in IE is based on standalone COM+ objects. How would you, for instance, test against different versions of the MSXML component with that setup (bearing in mind that that’s where XMLHTTP actually lives)?

    Here is my response:

    Tom,
    The suggestion isn’t perfect and does have it’s inherent problems but for the most part it should work as the installations are in separate directories containing the required DLL’s. The individual browser version work due to DLL redirection which was introduced with Win 2000.

    For reference: IE4 had the first version of the MSXML Parser (1.0). IE5 had the next version (2.0). From then until Version 3.0 you had to have IE5 to install those MSXML versions. From MSXML 3.0 forward the license doesn’t require IE5 for installation.

2 Trackbacks

  1. [...] As I have noted many times, the standalone Internet Explorer implementations are hacks that are best avoided. Alex Russell, leader of the Dojo project, explains the reasons quite eloquently. The recommended practice is to use Microsoft Virtual PC to run IE6 in a virtual environment. Which, for some, was a bit of an issue as it required another license for Windows—not everyone is blessed with an MSDN subscription. [...]

  2. [...] Alex Russel (Dojo Toolkit) legt behoorlijk overtuigend uit waarom virtueel testen beter is dan de standalone hacks te gebruiken. In het kort: standalones kunnen vrijwel nooit draaien als ‘native’ IE-installaties. IE is per definitie afhankelijk is van systeemcomponenten als Winsock en Windows Scripting Host, ook de standalones. Draai je dus niet dezelfde Windows-versie en patch-level als je test-doelgroep dan kun je verschillen in gedrag verwachten. [...]