The Sad, Sordid State of File Associations

So there's been a snafu recently with the way REALbasic handles file associations on Windows (in 2007r2). Yes, I realize it sucks, and I'm sorry for that. It's also been fixed. But someone asked a few interesting questions like "why the change" and "how did this get missed" which deserve some interesting answers.

So it's time for a history lesson.

When I was first hired on at REAL Software, my job was to help port the IDE from the Mac to Windows. I came on board just after 4.0 was released, and while we were working on 4.5. So this was a long while ago (over five years). One of the things we had to do was to make sure you could double-click on a file and it would launch in REALbasic. Obviously, this happens via file associations in the registry.

There was a decision that the IDE should be responsible for assigning these associations because the REALbasic IDE was the only thing in the world which could know how to open up the REALbasic project files. So if the user accidentally changed the file association, it was trivial to change it back to the proper application by just launching the IDE. Many thought it was very sensible at the time since there was no such thing as a valid .rb file association to something other than REALbasic.

If you're very astute at connecting the dots, you'll immediately see two problems with this.

1) Ruby came along with its .rb file association.
2) You now have a clobbering problem.

The issue with #1 sucks, but we've been avoiding recently since REALbasic uses .rbp as its default project extension, mostly as a kindness to the growing Ruby community. But the issue with #2 is where the real problem lies.

You see, the *correct* way to register file types on Windows is to have the installer register all private file types implicitly, register any public file types explicitly (by asking the user), and allow the user to re-register any file types via an option in the application itself. This is called "correct" both because it's the de facto standard, and because it's the way Microsoft lays out in the logo certification program and best practices guides. And this is what I've been striving towards for many years. But there's that nasty #2 issue. Let's take a peek at the use-case.

Sally is a long-time REALbasic user, She upgrades from version X to version Y. She grabs the installer, and installs version Y. The installer registers all of REALbasic's private file types with version Y. Sally is happy and does some work. She has one main product that she still develops in version W because it's in maintenance mode, and she has another new project that she's working on in version Y. A bug report comes in for her main project, so she opens up version W, opens her main project and fixes the bug. Oops, now all REALbasic file types are associated with version W, not version Y. She opens up version Y, but that doesn't re-associate the file types. Oops. Clobbered!

You might think that's a contrived use-case, but it's not. What's more, think about the beta testers. They flip from one version to the next more often than I change socks.

There are two ways this can be fixed. The nice way, and the not-as-nice way. The nice way involves file association versioning information being stored with the file association. It's a fairly complex little concept that Microsoft advocates as a way to solve this issue. Basically, you store application version information with the file association so that Version X doesn't clobber an association from Version X + n. Eventually, when enough versions have come out, you can get rid of the file association in the application and rely entirely on the installer because the chances of clobbering are so slim. This is the path we tried taking for 2007r2. However, as I said, it's very, very hard to get right. We thought we had it right when it was implemented, and there were no complaints about it. Until fc3. And when that complaint came in, it happened to be entirely unreproducible for me because of the way my machine was setup, and the original reporter said they weren't sure it was an RB issue to begin with. Bad coincidences suck, let me tell you. Oh, also, another reason why this was more of a priority to change now -- the old association was entirely wrong on non-admin machines (such as Vista defaults to). In that scenario, the file association was only in a half-installed state. Files were associated, but there was no application information to associate them to.

So due to the pain of this entire process, we've decided to just bite the bullet and jump in with both feet. In the next version of REALbasic, the IDE will not do any file association stuff on launch. None. Zero. Zilch. The installer will do the file associations as you'd expect, and if you happen to clobber them by going back a release, you can re-associate via the preferences dialog. It may be slightly more painful than the other approach for a while, but it's certainly much safer than the versioning approach and has no chance to automatically cause bad things to happen.

So now you know why the file associations changed, and a bit about why it wasn't caught before the release happened. In terms of what you can do about it right now (in r2) -- there really isn't too much. The problem is that every time the IDE launches, it automatically adds the registry information. About the only thing you can do is manually correct the associations that REALbasic makes (being careful not to delete or change names), and then set their permissions to being read-only. Quite convoluted.

I'm simply living with the broken extension until r3 arrives (remember, I use r2 to work on r3 -- so I feel this daily too).