>To the best of my knowledge, no. They just have a resource format (".nib",
>I believe) that is easy to work with, much as if a Mac resource fork were
>stored in a separate file.
In Nextstep, applications could register extensions with the
desktop environment. Anything having a registered extension was
shown as a file. If the thing shown as a file was really a
directory, dirname.ext/dirname was accessed.
For example applications had the registered extension .app.
.app-directories were shown as files with an icon. Double
clicking on myapplication.app started myapplication.app/myapplication.
The myapplication.app directory contained among other things the
application binary and the localized .nib files for the
application. .nib files (Next Interface Builder files) were GUI
objects made persistent. Interface Builder and Applications were
able to read the objects stored in them and reinstantiated them,
re-creating the GUI object network part of the applications
For Macintosh users, .nib file are close ressource forks, but
more flexible. Within the Next .app directories there are
usually multiple subdirectories named after the supported
languages. Nextstep had a search path for nib files that first
searched language named subdirectories (in a user defined order)
within an application directory, then the application directory
itself for nib files.
Many Nextstep applications also kept sound and image ressources
as well as sample files or other data within the .app directory.
Since the command prompt was a regular Unix shell, normal Unix
command line utilities including tar, cp and others, knew
automatically how to deal with all this: If you operated at this
level, you had Unix guru status automatically and there was no
need to protect you from the fact that applications are really
The Nextstep desktop had an additional open option called "Open
as directory..." (Command-Shift-O) which allowed Non-Gurus to
look into application directories as well.
Many Nextstep applications (Create, Diagram!, Edit working with
rtfd files, ...) handled their application data in a very
similar way: They also used directories to store non-flat data
structures. From the GUI, nobody ever noticed this (unless this
person was specifically looking for this).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html