Yes, I do. I recall they had ads where they showed the amazing things you could do with one-line commands at the shell - they had examples of pipelines including grep and awk etc. I remember being amused that these familiar idioms that had been used in the Unix/Linux world for ages were being presented as amazing new capabilities.
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!
Yes, they got it certified with 10.5, I think. Small market these days, although I'm always surprised when I hear that both AIX and HP-UX are still receiving updates...
It worked on me! I bought a PowerBook G4 in 2003, when I heard Fink/MacPorts and Jaguar were no longer complete nightmares to use. Been Mac only since then.
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.
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.
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.
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.
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.
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.
Maybe, but Mac APIs don't use them, so you can't mod your games with ResEdit anymore.
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.
It has extended attributes instead. You can look at them with `xattr -l /path/to/file`. Tags go into `com.apple.FinderInfo`, and resource forks are, predictably, `com.apple.ResourceFork`, though they're probably still stored in a format classic Mac OS understands.
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.
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.
It seems as if 100% of your criticisms have to do with exactly the issue in this article: Nobody supports resource forks but MacOS. So yeah, working with resource forks on systems that don't support them sucks.
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.
> some of the user interface features pioneered by Mac OS such the desktop
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 really, the basis for the desktop metaphor came from research done at IBM, and it was very extensively revised at Apple for Lisa. (See “Inventing the Lisa User Interface” from ACM Interactions in 1995.)
Apple seems to have a long history of integrations of Mac OS (and the Mac user interface) and UNIX, starting in the 1980s and continuing through today: A/UX, AWS (Apple Workgroup Server), MAE, Rhapsody, OS X, modern macOS...
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...
https://www.brainmapping.org/MarkCohen/UNIXad.pdf