There used to be things like this on Apple's website, too: https://www.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Us...
I can't find any mention of UNIX in Big Sur's pages, even though it is listed as certified on the Open Group's website.
Newer filesystems and application designs have eliminated many of the differences, although I still miss resource forks.
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.
My understanding is that's where file tags, file comments and custom file icons are stored.
NTFS also has multiple forks, and also has many of the same fancy attributes capabilities that made the BeOS filesystem (in)famous, but they're not used in the same way, so it's kind of moot.
What really what made BeOS and Mac OS good was not so much the technical underpinnings, but the way they exposed these in the APIs and standard applications.
The power of Unix isn't just from the presence of the standard I/O routines, but the fact that most programmes are written to adhere to a specific paradigm that allow them to work together.
That said, I think metadata about a file outside of the file has always been problematic. I don't know if there's ever been a clean solution to timestamps, r/w/x, ACLs and more.
That is not true. The desktop metaphor, for example, was first introduced at Xerox PARC in 1970, and used commercially in the Xerox Star workstation in 1981.
Not to mention the OS X-like variants for their other platforms: iOS, tvOS, iPadOS, watchOS...
Also consider the various Mach implementations on Apple hardware: MacMach, MachTen, MkLinux, OS X/Darwin...
Sadly it seems that the classic Mac API died when Carbon and 32-bit apps died, so you can't easily port old Mac apps to modern macOS. macOS (and iOS) seem to have a rather poor record for backward compatibility, and it's only going to get worse with the current architectural switch to Apple Silicon...
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.
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.
I remember putting FKEY resources into the System resource file so the user could type Shift-Command-<digit> anywhere to automate some common task.
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.
This is why I miss them, but understand that they're not used any more.
Resource forks let you put stuff outside of files that can and should go inside them. Now people have to look two places, or even be aware there are two places.