Resource fork used to contain all the stuff you could edit with ResEdit (good old times!) right? Icons, various gui resources, could be text and translation assets too. For example Escape Velocity plugins used custom resource types and a ResEdit plugin made them easy to edit there.
A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy.
Once you pushed an app beyond the level of usage the developer had performed in their initial tests, it would crawl to a near-halt, thrashing the disk like crazy on any save. Apple's algorithm would shift huge chunks of the file multiple times per set of updates, when usually it would be better to just rewrite the entire file once. IIRC, part of the problem was an implicit commitment to never strictly requiring more than a few KBs of available disk space.
In a sense, the resource fork was just too easy and accessible. In the long run, Mac users ended up suffering from it more than they benefited. When Apple finally got rid of it, the rejoice was pretty much universal. There was none of the nostalgia that usually accompanies disappearing Apple techs, especially the ones that get removed outright instead of upgraded (though one could argue that's what plists, XML and bundles did.)
The rejoicing was definitely not universal. It really felt like the NeXT folks wanted to throw out pretty much the entire Mac (except keeps its customer base and apps) and any compatibility had to be fought for through customer complaints.
Personally, MacOS X bundles (directories that were opaque in the Finder) seemed like a decent enough replacement for resource forks. The problem was that lots of NeXT-derived utilities munged old Mac files by being ignorant of resource forks and that was not ok.
The 9->X trapeze act was a colossal success, but in retrospect it was brutally risky. I can't think of a successful precedent involving popular tech. The closest parallel is OS/2, which was a flop for the ages.
A large amount of transition code was written in those years. One well-placed design failure could have cratered the whole project. Considering that the Classic environment was a good-enough catch-all solution, I would have also erred on the side of retiring things that were redundant in NeXT-land.
Resource forks were one of the best victims, 1% functionality and 99% technical debt. The one I mourned for was the Code Fragment Manager. It was one of Apple's best OS9 designs and was massively superior to Mach-O (and even more so wrt other unices.) Alas, it didn't bring enough value to justify the porting work, let alone the opportunity cost and risk delta.
MacOS X bundles are actually NeXTStep bundles, and are behind the same idea in Java JAR files with META-INF directory, and .NET resources, due to Objective-C's legacy on all those systems.
> When Apple finally got rid of it, the rejoice was pretty much universal. There was none of the nostalgia that usually accompanies disappearing Apple techs
Once you pushed an app beyond the level of usage the developer
had performed in their initial tests, it would crawl to a near-halt
With HFS (unsure about HFS+) the first three extents are stored in the extent data record. After that extents get stored in a separate "overflow" file stored at the end of the filesystem. How much data goes in those three extents depends on a lot of things, but it does mean that it's actually pretty easy for things to get fragmented.
A bit more detail: the first three extents the resource and data forks are stored as part of the entry in the catalog (for a total of up to six extents). On HFS each extent can be 2^16 blocks long (I think HFS+ moved to 32-bit lengths). Anything beyond that (due to size or fragmentation) will have its info stored in an overflow catalog. The overflow catalogs are a.) normal files and b.) keyed by the id (CNID) of the parent directory. If memory serves this means that the catalog file itself can become fragmented but also the lookups themselves are a bit slow. There are little shortcuts (threads) that are keyed by the CNID of the file/directory itself, but as far as I can tell they're only commonly written for directories not files.
tl;dr For either of the forks (data or resource) once you got beyond the capacity of three extents or you start modifying things on a fragmented filesystem performance will go to shit.
Oh, they're not gone -- still very much part of APFS. You can read the contents of the resource fork for a file at path `$FILE` by reading `$FILE/..namedfork/rsrc`
The resource fork is still how custom icons for files and directories are implemented!
(Look for a hidden file called `Icon\r` inside any directory with a custom icon, and you can dump its resource fork to a `.icns` file that Preview can open)
Hehe yep, but if we're doing vestigial nitpicks, I'd like to see an OpenResFile app that was ported to OS X and kept using the resfork to save its data. FAIK such a recalcitrant beast might even exist.
I credit ResEdit hacking partially for steering my path towards becoming a programmer. I had my Classic Mac OS installs throughly customized, as well as the other various programs and games that stored their assets in resource forks.
It was a lot of fun and something I’ve missed in modern computing. Not even desktop Linux is really fills that void. ResEdit and the way it exposed everything complete with built-in editors was really something special.
Same here but only for joining the industry. Now it's the opposite, that webdev still hasn't reached that level of maturity of classic Mac OS makes me want to quit.
The other big thing in the resource fork was the executable code segments that made up the application. In fact applications typically had nothing but the data fork at all. It was all in the resource fork.
I always thought the resource fork as a good idea poorly implemented. IMO they should have just given you a library that manipulated a regular file. Then you could choose to use it or not but it would still be a single file. It could have a standard header to identify it and the system could look inside if that header was there.
One of the big problems with resource forks was that no other system supported them so to host a mac file on a non-mac drive or an ftp server, etc, the file had to be converted to something that contained both parts, then converted back when brought to the mac. It was a PITA.
