The Challenges of Integrating the Unix and Mac OS Environments (2000) (opens in new tab)

What I found amusing at the time was, after years of touting the Mac point-and-click interface as a great improvement over the old-fashioned hard-to-learn obscure command line, they switched to touting the unprecedented power and versatility of ... the command line!

The first Mac filesystem didn't even have folders! So either every little thing would be visible to the user, or they'd have to hide files somehow. But really you wanted to just have one thing that you could copy around, double click, etc.

Resources also provided the programmer with a way of working with the data in a structured way. Unix is of course remarkably primitive here, you'll get bytes and like it.

It's always a little funny to see the scorn Unix minimalists have for the old Mac OS. It seems very hard for some people to understand that rather than technical purity or whatever, the Mac developers were working from the interface on in, and the interface was meant to make the computer approachable for people who'd never touched one before and weren't interested in computers for their own sake.

You are correct. Resource objects had a `purgeable` bit that would allow the block to be evicted from RAM if memory became scarce. Also, the memory blocks for resources were allocated as `Handles` (essentially, `void **` instead of `void *`, as C malloc() would return). That made the blocks holding the data moveable in memory, for reducing heap fragmentation. If your Handle pointed to a NULL pointer, that meant the block was purged and needed to be reloaded from disk. Manual allocation could also be done as a Handle, further reducing the risk of heap fragmentation.

System 7 makes it even more interesting since they had to implement resource compression to keep the Finder + System suitcase small enough to fit on a single floppy with space leftover for the user to actually use. The decompression routines ship alongside the compressed resources, as 68k machine code in a ‘dcmp’ resource and later as PPC code in a ‘ncmp’ resource, so devs were free to cook up and include any compression algorithm they wanted and weren’t limited to Apple’s ~three or so common ones.

It made applications portable in the "move it anywhere on the system" sense. I dimly recall dragging commonly-used applications to my desktop, particularly before support for aliases (similar to Windows shortcuts) was added.

Resource forks attract unresolved clutter.

It's like having an attic or a garage where you can put stuff while you (do not) decide what to do with it.

Then you carry around this clutter everywhere.

Developers might add something to a resource fork that should go in the file.

Utilities have to deal with files AND resource forks.

You have to backup a file, but then you also have to back up the resource fork.

If it goes to another filesystem you have to figure out how to deal with it if the filesystem deals with only, you know, files.

so what if the file and the resource fork are separated? Then you have a file that might not work.

this burden is carried by the developers, the administrators, the users.

There are plenty of analogous situations to this, like ftp

ftp used to have two connections - a control connection and a separate data connection.

Then when you had a firewall, you had to deal with an outgoing connection, plus an outgoing or incoming data connection.

Then they added passive mode, and you only had to deal with two connections in the same direction, but there had to be special firewall logic to track them both.