logoalt Hacker News

chizhik-pyzhikyesterday at 10:26 PM3 repliesview on HN

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?


Replies

duskwuffyesterday at 10:42 PM

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.

show 2 replies
clhodapptoday at 3:08 AM

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.