For those unfamiliar, Mac files of the era had two sections: a resource fork, and a data fork. Resources were structured chunks of information, like icons. You could open ResEdit and mod any app you liked.
I missed resource forks when they moved to the UNIX way in what's now macOS.
I used to use ResEdit to make new fonts. The fonts were fully defined as bitmaps in the resource fork; pop open the System file in ResEdit and you could make whatever you wanted. Turned in all my school papers during middle school in a font of my own design.
Confession: Back in the day, before Macs had a real virtual memory system, I abused the Resource Manager and a file's resource fork to serve as a crude VM for an object management library I created so that I could write apps that used more C++ objects than would fit in memory. It was a hack, but it worked surprisingly well.
“Thankfully, I knew of a similar system in Smalltalk, an object-oriented virtual memory called OOZE that was designed by Ted Kaehler, that swapped objects in and out of main memory as required. This was my inspiration for the Resource Manager. Find out more about OOZE here”
I think the Resource Manager was designed with the "objects" in mind being understood to be an application's assets, such as code, graphics, menus, text, and so on. My abuse was to extend this to arbitrary, dynamically allocated blobs so that an app could, for example, scan thousands of files and store each file's metadata in virtual memory, way beyond what would fit in RAM.
This would have been in the early 1990s, I'd guess.
EDIT: I just checked the sources: it was mid 1993. Back then, a Macintosh Classic II would have been a common machine and shipped with 2 MB of RAM. Older machines often had only 1 MB of RAM.
Ha, I worked in a computer lab a student assistant and used to modify the Netware for Mac client on some of the tech staff we worked for. I remember swapping the logout and login commands on our boss's computer.
Resourcerer had better templates for lots of common GUI elements, but system resources were complete in ResEdit. Don't forget rez and derez tools for the list.
I missed resource forks when they moved to the UNIX way in what's now macOS.
You could mod Windows apps the same way (and at least one resource editor was also named ResEdit), yet the filesystem didn't provide multiple forks --- it was just a separate section in the binary.
In fact macOS apps are just a directory containing both the main binary and resources.
I remember Borland’s resource editor. I themed my VGA.DRV file quite extensively.
Later on, Windows NT gained resource forks. An early security flaw of IIS was that you could ask it to serve the DATA fork of any source file and see things like hard-coded credentials (because IIS would not execute the file, just serve its contents).
> In fact macOS apps are just a directory containing both the main binary and resources.
This is a much saner design decision, but it wouldn’t be possible before the file system got folders.
Forks caused all sorts of issues when you needed to transmit a file from one computer to another without using a floppy disk.
For those unfamiliar, Mac files of the era had two sections: a resource fork, and a data fork. Resources were structured chunks of information, like icons. You could open ResEdit and mod any app you liked.
I missed resource forks when they moved to the UNIX way in what's now macOS.