>Things like .so file in /usr/lib, icons in /usr/something/ will be automatically
>skipped since this stuff is contained within the application or OS resource fork,
>so the search space for a particular file under HFS is much smaller in MacOS
>than with Win32/Unix since everything is treated as a file within those OSes.
So how does MacOS deal with things that could (should) be shared
between different applications, say libc? Does every program that
needs the libc has it in its resource fork? Or are there ways to say
"well, I need libc, but I don't have it handy, please go and look for
it in the OS" (e.g. use a dynamic linker).
If you must trade the benefit of not going through all the .so and
icon files for "having every binary contain its own icons and 'shared'
libs", then I would happliy stay with the current context.
BTW: One examples of "resource forks done wrong" are IMHO the
<application>.icon files from the Amiga OS.
I was pretty impressed with the description of the NT stuff. Basically
you get different views of your file structure depending on the
application which views the file space. This is pretty cool. What
looks like a bunch of dot-files for one application (e.g. ftp or file
manager) is a forked file for another application. But what if you
e.g. delete a dot file in one context?
Kind regards
Henning
-- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- hps@tanstaafl.de TANSTAAFL! Consulting - Unix, Internet, SecurityHutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054 Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"
- 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/