iPhone-to-iTunes Fail

The May-December relationship between my new iPhone 3G and my G4 cube has quickly and suddenly given up the ghost. Two days after getting the 2.2 software on my phone (which I would have done with my G4 cube, but its 802.1b connection was way too slow to download the software, and I used my 802.1n on my MacBook Pro), my phone showed the graphic that I needed to plug it into iTunes. Le sigh. So I try to connect to the G4 (which has finally downloaded the software by now), and I get:
Well, carp. I go back to my MacBook Pro and restore the phone. At this point, I suspect I should be able to hook it back up to the G4, but no. iPhoto realizes it needs to launch, but iTunes spends most of two minutes showing the beachball and finally pops up the same error. Unfortunately, my MacBook Pro, which is a working machine (many enlistments in lots of source), has a pittance of the music / podcasts / playlists / etc. compared to that of the cube. I’ve finally given up and copied my various applications over to its iTunes installation, and am about to sync using the laptop instead.

Also, is it too much to ask to have the backup remember the text correction data that it's learned? I’ve taught it not to correct certain words and now it appears I get to do it again. :(

Updated (12/3):
After spending a week of trying to get this to work (rebooting the cube, rebooting the iPhone, force quitting the iTunes Helper app, etc.), and finally getting worked up enough to post about it, last night after posting, it finally worked. For some reason, connecting the phone while iTunes was up was causing the error, but connecting the phone first, and then booting iTunes got me to the “You need to put in your phone password” error, and thence to actual connection (again, having to quit iTunes and ensure the phone was connected and unlocked, and then launching iTunes again). Now, after several hours of USB v1 synching, my phone is mostly back. For some strange reason, the AppStore thinks all of the applications are out of date and is now downloading replacements, but whatever.

Redefining free

From the ASP.net website,

ASP.NET is a free technology that allows anyone to create a modern web site.

and from the getting started page,

All you need to get started with ASP.NET is the free .NET Framework and the free Visual Web Developer.

I am now wondering whether Microsoft is now issuing also free licenses to Windows, so that as a Macintosh owner, I can actually use the technology. No, not so much. Perhaps they need a superscript asterisk^*.
--
^*Requires the purchase of a qualified Microsoft Windows operating system.

Setup woes

Could someone explain to me why installers are often the least thought-through part of the application development process? And more importantly, why, especially at Microsoft, the people who write the software and thus know the limitations it has on file layout (including files comprising the application and its support libraries, but also plugins, caches, temporary user data, persistent user data, configuration files or *puke* registry keys) are usually not the people producing the software installation packages? And even when they are, they think first Test Matrix and second Customer Utility.

Installation is the very first user experience (after opening the box, in the case of full package product, which rarely happens anymore with web downloads), and is a regular experience as upgrades come out, or more likely, security patches. Getting your installer right enables people to install your application where they want it to. Whether that means an alternate volume (other than the boot volume) or in a user-specific directory (in the case where they’re not an admin and don't have access to the root of the volume), or on some network share for multiple people to use, they should be able to get it there, and installer writers are notorious for arbitrarily limiting this.

Furthermore, custom installer scripts do the most insane things, requiring you to quit apps that have nothing to do with the thing you're installing, or to reboot because they couldn’t figure out how to gracefully install in a way that lets running apps continue to work correctly. Gaah!

I downloaded the RDC update (well, from v2.0 Beta to v2.0 RTW) and tried to install it. It wouldn’t allow me to install to my data volume. Why? No reason that I can fathom. (It doesn't have the same installation requirements promise that Mac Office 2008 made; it's an RTW product and free–they could change it to be whatever they wanted, even 10.4.10. Heck, that would even reduce the all-important testing matrix.) Even if I use the same hack to fix that, the package was not marked as relocatable, so it would have installed the thing to /Volumes/OtherVolume/Applications, rather than let me nicely select where to put it (i.e., to replace the Beta version that was on the data volume and running fine from there). So, I decided to install it “normally” and just move it after the fact. While running, it asks me to quit Entourage. Why does it need to quit Entourage? There’s no shared libraries between Entourage and RDC. Ah, but it needs to install Microsoft AutoUpdate, and Entourage uses that. There are two obvious problems here: (1) There was nothing in the package that said it was installing two different items, RDC and AutoUpdate. If AutoUpdate is not in the package of RDC, then it should be its own separate line item to be installed. Even if the developers wanted to enforce an (unnecessary) dependency between RDC and AutoUpdate, having it called out would be actually useful. (2) Why does Entourage have to quit in order to update Microsoft AutoUpdate? Even presuming that there was an actual update that was occurring (which seems strange considering I just updated to Office 12.1.1, and would have expected that any updates to AutoUpdate would have been in that package as well). The best part is that your only choice when Entourage is running is to quit Entourage, because the only button available to you in the installer is “Continue”, and if you click that while Entourage is still up, it just causes the dialog to reappear. I suppose there’s always Force Quit.

So, in summary, the installer fails on several fronts:

• relocatable installation
  • different path
  • different volume (unless the volume happens to be a system volume of 10.4.9 or later
• non-admin installation to ~/Applications

and is a little annoying about hiding multiple packages with weird installation requirements.

Guess I’m back to fighting the uphill battle.

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.