I love(d) resource forks. Before there were signed applications, it made it easy to modify applications without the source code. I even had a plug-in that disassembled the binary executable blobs, and had fun modifying one of the original text editor desk accessories to allow windows larger than 512 x 342. (Those were the days...)
The resource fork concept was always something that confused me about old mac. Anyone have a recommended blog/guide to learn more about how that works?
But the short version is that the Resource Manager provided a standardized way for applications to store a bunch of record-based data in a file - either as part of the application itself, or in files it created - and load those records on demand. The system used resources heavily to represent assets like code fragments, icons, dialog box layouts, or sounds, which could all be loaded on demand or automatically purged from memory when not in use.
Emphasis on the memory management: because early Macs had only 128k/512k of RAM and a single floppy drive, dialogs and code fragments had to be constantly swapped in from application disks; and because early Macs had no paging, resources were accessed via handles.
You'd often have enough of a word processor resident in memory, to be able to work with a document disk in your Mac. But if you wanted to (say) print or run a spell-check, you simply didn't have enough memory to do so: so the System needed to purge resources, and load the requisite resources (code, dialogs) from the application disk.
You'd be constantly swapping between user disks and application disks. Resources and handles were the way the System constantly shifted parts of an application in and out of the limited memory, tracking where they came from.
To understand the capabilities in modern terms, imagine if each file was a SQLite database in addition to containing its normal data. The normal data and the database would be entirely independent "chunks" of data. The system APIs would offer the ability to either open the file as a normal data stream, or to query it as a SQLite database.
In such a world, you might find yourself leveraging the database "side" of executables to store assets for your programs. You might use it to store the fonts used in your documents. And you might use it to store metadata for your photos.
In some cases, you might find yourself creating files just as an easy way to get a SQLite database, and not putting any normal data in them.
The format wasn't actually SQLite, but in a hand-wavey way, that's resource forks.
You could do this today on Windows with NTFS Alternate Data Streams.
Windows also supports "resources" (menus, icons, etc.) that can be compiled and linked into the executable.
Resource forks died out because users want to easily see where data is hiding, and having multiple files attached to the same name didn't make the filesystem fast or manageable.
Resource bundles (borrowed from RISC OS) allowed hiding the resources in the Finder by presenting them as an app, but also making it easy to open the Contents folder and see the internals
I love(d) resource forks. Before there were signed applications, it made it easy to modify applications without the source code. I even had a plug-in that disassembled the binary executable blobs, and had fun modifying one of the original text editor desk accessories to allow windows larger than 512 x 342. (Those were the days...)
I run System 7 on an iPad and used ResEdit to change the resource forks to make toolbar buttons in an app larger and more tapable. https://blog.gingerbeardman.com/2021/03/28/changing-the-size...
Agreed. Definitely used to enjoy having fun with ResEdit back in the day - simpler times :-)
The resource fork concept was always something that confused me about old mac. Anyone have a recommended blog/guide to learn more about how that works?
Apple's own documentation is a fine place to start - the first chapter of this book explains what resources were and how they were used:
https://developer.apple.com/library/archive/documentation/ma...
But the short version is that the Resource Manager provided a standardized way for applications to store a bunch of record-based data in a file - either as part of the application itself, or in files it created - and load those records on demand. The system used resources heavily to represent assets like code fragments, icons, dialog box layouts, or sounds, which could all be loaded on demand or automatically purged from memory when not in use.
Emphasis on the memory management: because early Macs had only 128k/512k of RAM and a single floppy drive, dialogs and code fragments had to be constantly swapped in from application disks; and because early Macs had no paging, resources were accessed via handles.
You'd often have enough of a word processor resident in memory, to be able to work with a document disk in your Mac. But if you wanted to (say) print or run a spell-check, you simply didn't have enough memory to do so: so the System needed to purge resources, and load the requisite resources (code, dialogs) from the application disk. You'd be constantly swapping between user disks and application disks. Resources and handles were the way the System constantly shifted parts of an application in and out of the limited memory, tracking where they came from.
Palm OS borrowed the concept. This meant that you could edit apps on the device! https://blog.gingerbeardman.com/2022/10/07/fixing-bugs-using...
Palm OS borrowed a lot of concepts from Mac OS - and it's no coincidence that many of their early employees came from Apple as well.
To understand the capabilities in modern terms, imagine if each file was a SQLite database in addition to containing its normal data. The normal data and the database would be entirely independent "chunks" of data. The system APIs would offer the ability to either open the file as a normal data stream, or to query it as a SQLite database.
In such a world, you might find yourself leveraging the database "side" of executables to store assets for your programs. You might use it to store the fonts used in your documents. And you might use it to store metadata for your photos.
In some cases, you might find yourself creating files just as an easy way to get a SQLite database, and not putting any normal data in them.
The format wasn't actually SQLite, but in a hand-wavey way, that's resource forks.
You could do this today on Windows with NTFS Alternate Data Streams.
Windows also supports "resources" (menus, icons, etc.) that can be compiled and linked into the executable.
Resource forks died out because users want to easily see where data is hiding, and having multiple files attached to the same name didn't make the filesystem fast or manageable.
Resource bundles (borrowed from RISC OS) allowed hiding the resources in the Finder by presenting them as an app, but also making it easy to open the Contents folder and see the internals
https://folklore.org/The_Grand_Unified_Model.html