Attendees to the fest at the Temple of Castor and Pollux in December may recall that I amused myself by plugging in my mother's iMac hard drive into Titania to see what I could extract from it. I was sucessful in grabbing the files (once I installed the hfs-plus kernel patch; 2.6 kernels may have a new enough implementation), but some of the documents were in bizarre, Mac-only formats.

Interpreting the files would be pretty much irrelevant for this case. My machine would just serve as a place to backup files until a replacement drive could be obtained. Then the files could be copied back to the iMac, and it could do whatever it needed with them. I wouldn't even need to look at the contents at all. (Although I suspect most of the stuff that my dad cares about is in jpeg format anyway.)

In that case, I'd advise taking extra steps to make sure you get the resource fork as well as the data fork. Macs have a fascinating concept of metadata not found in other computing systems that involves something mysterious known as the "resource fork", which I don't really know all that much about besides that it exists and it can be used for evil as well as for good. But for jpegs it might not matter anyway.

Resource forks have been around since the invention of the Mac. The way files are split, there are 2 forks to the file, the binary or data fork, and the resource fork. For applications, the binary fork contains the actual binary, the code to be executed by the machine. The resource fork contains the data relating to that application.

<p>

For example, when I'm writing a program for the Mac, all I have to do is call NewMenu() or something like that, and it will go look in the resource fork for the title of the menu, and all the sub-menu items under it.

<p>

So what's the point of a resource fork? Why can't all that data just be compiled in as arrays or whatever?

<p>

The thing that makes a resource fork so powerful is that you don't have to recompile the software just to change the visual layout or anything not behavior related (and some things that are behavior related, I believe). In fact, anyone with a copy of ResEdit (free from Apple, this was back in the OS 9 and earlier days) could go in and change the layout of any program and do all sorts of nifty stuff, and it made the designer's job much easier. I think this might be one reason among many Apple developed such a reputation of software having such excellent interfaces. The programmer could write simple code to bring up graphical elements, and the interface experts could work on the user interface completely seperate.

I believe with OS X, they went ahead and split the resource fork into a seperate file, and you can have as many resource files all hidden inside a single package. This not only makes it more powerful, since you can for example have a seperate resource fork for each langauge version or whatever, it also makes it so people who care about using a resource fork still have access to it and in a more straightforward way (since it is a file now), but it's still quite hidden from those who couldn't care less.

Having dealt with a lot of different operating systems, I have to say that I think Apple's way of doing it is the most logical. All application specific stuff is hidden within one file, instead of being spread around the whole OS like Linux and Windows. Of course, that only applies to large scale applications. I think the Unix way is quite nice for dealing with a command line environment, but it sucks for graphical applications.

Actually, I think the way BeOS does things might be just as good or better than the way Apple does it, but I just seem like I had some complaint about the way they arranged stuff which I can't remember at the moment.

Anyway, I think I've written far to much, the point was explaining a bit about resource forks.