Infinite Mac: Resource Fork Roundtripping
Posted4 months agoActive4 months ago
blog.persistent.infoTechstory
calmpositive
Debate
20/100
MacintoshResource ForksRetro Computing
Key topics
Macintosh
Resource Forks
Retro Computing
The article discusses the implementation of resource fork roundtripping in Infinite Mac, a project that emulates classic Macintosh systems, sparking a discussion about the nostalgia and technical intricacies of resource forks.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
2d
Peak period
10
Day 2
Avg / period
4.3
Comment distribution13 data points
Loading chart...
Based on 13 loaded comments
Key moments
- 01Story posted
Sep 16, 2025 at 1:36 AM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 6:26 PM EDT
2d after posting
Step 02 - 03Peak activity
10 comments in Day 2
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 27, 2025 at 9:02 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45258403Type: storyLast synced: 11/20/2025, 3:38:03 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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.
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.
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
One crucial difference is that the Mac OS resource fork is dynamic - the system provided methods to create and modify resources at runtime, and many applications did so. Windows resources, by contrast, are static.