Messages in this thread |  | | | From | Peter Desnoyers <> | | Subject | Re: nice troll (was: All this resource-fork AKA multiple stream nonsense) | | Date | Sat, 10 Jul 1999 07:27:16 -0400 (EDT) |
| |
Since everyone's arguing from first principles, I thought it might be helpful to describe instead in a bit more detail how these various GUI OS's actually handle icons, associations, and all that.
BEOS - I'm completely ignorant.
MacOS (knowledge current as of '90 or so :-() - each file has two 4-byte fields, creator(?) and type, as well as a resource fork and a data fork. A mysterious file (the desktop db?) maps from creator to application and from type to icon. Data file resource forks are used infrequently by the app to store app-specific data.
The reason for two fields is so that you can keep the type constant while customizing the app binding for a specific file. In addition, 4-byte fields allow readable ascii values to be used, reducing the need for a global registry of types and yet another database.
Win95/NT - files are bags of bytes. Executables have icons and other resources stored in the object file header. The registry maps from file extensions to associated app and icon.
Linux needs nothing to support the windows model, as if you can store resources in COFF I'm sure you can store them in ELF. For the Mac model, you might be able to store creator and type somewhere in ext2; if they get nuked by utilities, they can be restored from /etc/magic. Just a thought...
-- ............................................................................ Peter Desnoyers 162 Pleasant St. (617) 661-1979 pjd@fred.cambridge.ma.us Cambridge, Mass. 02139 (978) 461-0402 (work) pjd@giga-net.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |