Install Mac Office 2008 updates to a data volume

The Office 2008 installer package was shipped with an intentional deficiency–the ability to install to other volumes than a system volume, and furthermore a system that supported the minimum OS requirements of Office 2008–to work around problems with the OS installer. Those problems only existed on certain versions of Tiger and they were fixed before Office was shipped, but not until after minimum OS version support was announced.

The unfortunate problem is that, even though the problem existed on a particular version of the OS, the installer logic denies you the ability to install when you’re on a version of the OS that doesn’t have the problem, which includes 10.4.11 and 10.5.x. This could be handled by logic in the .dist file hiding in the updater package, but to date (including the 12.1.1 update), is not.

Here are some instructions that I have successfully used¹ to get Office updates to install to my data volume, which is where I moved it immediately after installing it:

1. After auto-update runs the installer, OK the dialog asking if it can run a script.


2. Command-Click on the title bar of the installer and choose the folder containing the Installer package, usually named “Temporary Items”. This should reveal it in the Finder.


3. Copy the installer package to the Desktop using Option-drag. This is so we can edit the copy and have it in a known, long-term location.


4. Quit the Installer, since the stock package won’t install.


5. Right click the package on the Desktop, and choose “Show Package Contents”.


6. Double click the Contents folder.


7. Open distribution.dist in your favorite text editor.


8. Replace the body of volumeOs1049OrHigherTest with return true;


9. Save the file; it’s read-only by default, so you’ll have to force it.


10. Double click the installer package on the Desktop and install it as normal.

One might imagine that if there were a particular problem with the installer in 10.4.9, that one could rewrite the check s.t. the volume check succeeds if (!systemIs1049() || volumeOs1049OrHigher()) && volumeHasUpdatableVersion() and still get the limited behavior where it causes problems with the system, and the unlimited behavior where it does not.
--
¹YMMV. Void where prohibited. These are not official Microsoft instructions; I’m acting as merely another customer of Microsoft using publicly available knowledge about .dist files.

On tools and how to sell managers on tools upgrades

You would think that because Apple provides their developer tools gratis that that means they’re “free.” There’s a rather marginal cost involved to actually physically making the switch in the build system for your product, larger if you aren’t using Apple’s whole toolchain¹, but in and of itself, that’s still pretty cheap.

The real cost is the ineffable “baking time” cost for QA to be sufficiently happy with knowing that the toolchain change did not introduce any regressions². You can immediately run all of your existing unit tests and scenario tests and have a good idea of the quality of your product, true. But, all the manual tests need to be run by hand, and depending on the size of that corpus, it can take a while. Furthermore, not everything gets tested in these official tests³, and some amount of ad hoc testing is generally desired. How much depends on the complexity of your product, the (apparent) understanding of QA of that complexity, and the general paranoia level of QA.

The best time to sell managers on tools upgrades is at the beginning of a project release, though, for long-term projects, the tools may change multiple times over the course of development. In that case, strategic tools changes even after beta releases may be desirable, but you have to sell them on the strategy: what is the benefit? In some cases, the benefit is inobvious–e.g., we know they improved the optimizer, but does that actually help us in our scenarios? These need private releases using the new tools just to measure performance changes before there's a benefit demonstrated. In other cases, new compiler or SDK features imply the ability to have a better feature, e.g., conditional linking of 10.5 APIs without having to clunkily redeclare them in your source that's otherwise tied to the 10.4 SDK, or for 10.5/Xcode 3.0 specifically, the ability to add DTrace custom probes. For us⁴, unless we posted the bug, it’s unclear what set of bugs were addressed in a new tools release to know whether any of them would affect us, save through testing. Ultimately, management can weigh the benefit with the known/estimated costs and choose to make the jump, or wait until we start the next release.
--
¹For example, the delta for switching between the 10.4 headers and the 10.5 headers consisted only of having to add a few explicit #includes that we had gotten away with not having because another system-level #include had done that work for us. Deltas between compiler revisions is another story, since the compiler gets monotonically more strict over time.
²Whereas it is significantly more rare that a toolchain change will introduce a regression due to a compiler/linker bug, it is much more likely that such regressions are a product of substandard design that (1) took reliances on unspecified compiler behavior or (2) was luckily not revealed by a previous compiler.
³It should be no surprise that testing matrices are far larger than we have time to test. (Think along the line about testing until the heat death of the universe.) Official testing may only sparsely fill the matrices along tuples of interesting-to-combine technologies.
⁴Whereas some of these toolchains produced by Apple are Open Source, since Microsoft is also in the business of making compilers, it behooves us not to inspect code changes made in a specific revision of the tools.

WWDC bound

Miller, Mabry and I are headed to SF tomorrow, and I’ll be staying through the week for WWDC. I suspect that there will be scads of iPhone developer wannabes¹. Me, I’ll be focusing on hardware exception handling, tools support for servicing, and Windows integration. Maybe I’ll find a few highly technical Mac/Unix heads in the Seattle area who want to come work for Silverlight, either with me in the CLR or on the WPF/E team. I really hope, though, that I’ll shake this cold before Monday.
--
¹I’d be a iPhone dev wannabe, but the CLR team doesn’t have an ARM JIT compiler, and the .NET Compact Framework, which does, would probably be the most likely product to support a CoreCLR-like piece of software for the device.