Google Earth setup experience

Google announced the release of Google Earth 4.3 today. Given the recent release of their WiX-based setup for the Google App Engine SDK, I had to give it a shot. (It helps that my day job also deals with 3-D terrain imagery.)

When you click the link to “Download Google Earth 4.3” (and accept the EULA), you download not Google Earth but “Google Updater.exe.” Run it and it starts downloading the Google Earth installer.

Personally, I much prefer to download the actual installers for the software I use. Some of it’s purely practical: I can stick it on a network and put it on multiple computers (EULA permitting, of course) without waiting for multiple downloads. Perhaps more importantly, for the paranoid among us, is the ability to virus-scan the installers. (Google Updater requests elevation, so it has admin rights to install multiple packages.)

Google Updater also runs as a startup app, optionally showing an icon in the increasingly-unusable system tray. (Yes, I know it’s technically the “notification area,” but come on, who calls it that?) I don’t think I need 24/7 instant access to software that doesn’t get updated that often. In fact, I’m sure I don’t.

Naturally, installing a packaging system with update capabilities is a boon to many users (and Google itself, of course, which has a nicely visible entry point to suggest additional apps for download). Apple does it with iTunes and Microsoft does it with Windows Live. Luckily, Google Updater has its own entry in Add/Remove Programs so you can remove it without impact to Google Earth.

Google Earth installer

The Google Earth installer is built with InstallShield, using its support for “dynamic file linking.” (If you haven’t used it, think of running Heat or Tallow with every build.) Interestingly, it uses the CAQuietExec custom action from WiX and has wixca.dll in the Binary table.

The .msi package fails ICE validation, with errors in ICE03, ICE15, ICE34, ICE38, ICE43, ICE44, ICE57, ICE64, and ICE99, and warnings in ICE45, ICE60, ICE82, ICE86, and ICE91.

There are 36 custom actions, some of which are mildly disturbing:

  • registerFlashSOL is a deferred, no-impersonate custom action that runs an included .exe with a “-install” command-line switch. Oh joy: self-reg.
  • InstallToolBarCA is an immediate custom action that runs an installed .exe. It’s not scheduled and is only available from the UI sequence – the one that’s suppressed because Google Updater runs the installation silently.
  • SetGEUserStats is another custom action run only from the suppressed – but still included – UI sequence.
  • SET_RES_READ_ONLY sets QtExecCmdLine to run the WiX CAQuietExec custom action. What is it hiding? It’s running attrib.exe to turn off the read-only attribute on a recursive set of files/directories. Doesn’t the File table let you control the read-only attribute? Yes, it does, but apparently not when you use InstallShield’s dynamic file linking to harvest a directory tree at build time. In a previous life, I used that functionality and turned off the read-only attributes in the build script before harvesting. Doing it as part of installation is bad karma on Google’s part.

Overall, it’s not a bad installer, but I hope Google cleans it up a bit before it loses the “beta” label.

5 Replies to “Google Earth setup experience”

  1. Google Updater installs a Windows Service, too. It’s called “Google Updater Service” (sic!), runs as LOCALSYSTEM(!), startup type ‘Automatic’. Fortunately you get rid of that thing, too, when you remove “Google Updater” via Add/Remove programs.

  2. I’m pretty much resigned to updaters wanting to run services, no matter how bad an idea it is from a security perspective. That’s why I run software like iTunes on my laptop and not my development box.

  3. It never ceases to amaze me how many vendors release MSI-based installation without running MSI validation and fixing any validation errors. I ran across another one last week (AcuCobol extend® 8 from, which also uses InstallShield). Using InstallShield, there’s really no excuse for not running validation since the InstallShield can be set up to automatically execute validation as part of the build process. I have no doubt these are just yet more examples of a vendor using a 3rd party installation software that ‘dumbs down’ MSI package generation for people who don’t bother to learn the underlying MSI technology. Personally, I think someone ought to take these people out back and shoot them. 😉

  4. Abstractions leak, that’s a given. That’s why there are tools like validation — but they have to be (1) run and (2) not ignored. And ideally, the instinct that running attrib as part of an installation is a “code smell” for setup (for example).

    Shooting violators that would result in a huge number of job openings…OTOH, that might make for a great business opportunity if you’re one of the survivors. 8)

  5. Don’t blame ISHNMET, validation is turned on by default… you have to turn it off. Also there is already plenty of work out there. I just changed jobs a month ago and I had three offers within 1 week of announcing that I was available. Funny thing though, I thought my job was supposed to be obsolete by now. Something about Distrupting the Centralized Setup Cycle. Yah…. we can talk all about Agile, Scrum and Done Done but the reality is Setup is still not abstracted enough for the vast majority of developers who neither understand or even care about setup.

Comments are closed.