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.

▲

amiga386 3 days ago | parent [-]

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

	▲	duskwuff 2 days ago \| parent [-]
		> Windows also supports "resources" (menus, icons, etc.) that can be compiled and linked into the executable. 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.