Apple Safari setup built with WiX

Apple’s Safari browser is now available in public beta on Windows. A little spelunking shows that it uses Windows Installer packages and that they’re built with WiX. Sadly, they didn’t use WixUI.<g>

On a more serious-but-sad note, the packages have ICE validation errors (other than the typical ones), contain VBScript custom actions, and the main Safari package uses a custom action to install the Apple Software Updater package (instead of using a chainer). Already there’s a forum report of a 2738 error with the VBScript CA. And I guess the only way to report bugs is via forum posts…? It’s not clear. The “Report Bugs to Apple” command on the Help menu seems focused on rendering problems. Too bad. After all, Setup Development Is Just Development.

5 thoughts on “Apple Safari setup built with WiX

  1. I did my own spelunking and the package seems to contain a second executable (called by a custom action) that installs Apple Software Update. Does that not qualify as a chainer?

    Also, keep in mind that this is a beta release. VBScript is great for quick development and perhaps they will move away from it if/when a final version is delivered.

  2. The ability to install another package from a custom action is deprecated. (See http://msdn2.microsoft.com/en-us/library/aa368010.aspx.) Apple worked around that in its CA by sequencing it in the UI sequence only so basic/silent UI modes will never install it. A chainer is a separate executable that avoids those problems.

    VBScript is great for prototyping CAs but should never go outside the walls. VBScript is too fragile, something Apple knows about. (See http://docs.info.apple.com/article.html?artnum=304405.) Given that other Apple products on Windows RTM’d with VBScript, I’m not confident it’ll go away, except by pointing out the problem.

    Apple is all about the user experience and setup is the user’s first experience (especially on Windows) (and even on OSX). Taking shortcuts for the sake of quicker delivery can kill the experience.

  3. The behavior is definitely deprecated (link didn’t work), but is there documentation (i.e. from MS) on how to ‘correctly’ implement a multiple MSI install and/or chainer?

  4. MSI doesn’t really have a proper fully featured bootstrapper. This has been historically left up to tools vendors but based on the changing attitudes towards merge modules and concurrent installs, I expect MSI will be addressing this story alot more in the next version of MSI ( 4.x maybe? ) very soon but that it’ll still be up to the tools vendors to implement the patterns.