[klodolph]

I feel the modern approach takes the main strengths of resource forks and builds on them—instead of needing to use ResEdit, all of your application resources are just ordinary files stored in a directory. Images are stored in standard formats like PNG, data is often stored in plist or text formats.

[asveikau]

Maybe somebody who knows classic Mac well can correct me here if I'm wrong, but I feel like resource forks were also solving a "constrained memory and an OS that didn't do paging" problem.

So the library deciding how to load and possibly when to evict sounds like it was kind of the point. Simulating what might be the job of mmap() on a modern system.

[rvense]

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.

[dietrichepp]

It’s true that MFS didn’t have folders—but it was also superseded by HFS all the way back in 1985! From my research, there’s only one generation of Macintosh computers (the original 128K and 512K) that did not ship with HFS. MFS was standard for a very short period of time.

The article hints at how files work. On MFS you would refer to a file as a (volume ID, filename) pair. On HFS, you would refer to a file as a (volume ID, directory ID, filename) triplet. A bunch of toolbox calls (syscalls) got duplicate versions for HFS—but if you were working with legacy code, you could create a fake volume ID called a “working directory” that could be used as if it were a volume ID in a (volume ID, filename) pair. These “working directories” are just awful. The working directory table is global to the entire system and they are not reference-counted—if you open the same working directory twice, you get the same ID both times, and you only have to close it once.

As a funny note—the original filesystem, MFS, had a maximum file name length of 255 characters. HFS, its successor, had a 31-character limit when it first appeared. As a compromise, the new FSSpec file APIs that appeared in System 7 used a 63-character limit filename, because 63 characters was the maximum filename length that the Finder supported.

You could create files with names longer than 63 characters on MFS volumes, it’s just that if you browsed these volumes in the Finder, the Finder would crash!

I’ve got a blog post in the work that is going through some of the wackiness I’ve seen in the old Mac OS filesystem API, and I’ve recently been on the RetroDev Discord helping some people write file handling code for classic Mac OS programs.

[tempodox]

Those were the times. ResEdit, with disassembly of CODE resources and editors for structured types, together with MacsBug for inspecting or manipulating runtime state, was a combination that gave you ultimate power over your system.

I remember putting FKEY resources into the System resource file so the user could type Shift-Command-<digit> anywhere to automate some common task.

[tempodox]

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.

[Lammy]

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.

[geraldcombs]

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.

[pwinnski]

True, I do like 'Show Package Contents'