OS-wars: Unix file system(s)

OS-wars: Unix file system(s)

Post by Leichter-Je.. » Sun, 02 Dec 1990 17:37:00

[Normally, I stay out of this sort of stuff, but sometimes things get a bit
thick out there....]

           Now, Unix fans, can you answer one for me?

        I'll give it a shot -- I don't claim to be an expert.

           [munched example explaination concerning printing "funny" files]

           How are cases like this handled on Unix?  Is there a special print
           command, or something, that says "print this in raw mode"? ...

        Unix seems to have been built on an object-oriented paradigm before
        "object-orientation" was well-known.  Basically, one builds tools to
        do very specific functions and then builds on those tools to create
        other tools that do higher level functions.  This printer case is an
        example of that capability....  [The printer driver knows who to send
        a stream of uninterpreted bytes to the printer; front-end programs do
        translations; a configuration file determines which front-end program
        to use for a given printer.]

        The configuration file in this may actually have several configura-
        tions for a single printer at one time.  For instance, a laser printer
        might be called POSTSCRIPT when a user wants to send Postscript files
        to it or LA23 when a user wants to send a straight ASCII file to it.
        Usually, the user needs to know what type of file it is so he can send
        it to the right printer name.  However, this is not a hard thing to do
        and some people have built simple commands that guess the type and
        send it to the right printer....

Ahem.  The way object-oriented systems work is quite different.  Logically, in
an object-oriented system each object carries along with it the operation that
can be applied to it.  That is, an object like a file is printable if and only
if it has "within it" a "print" operation.  In an object-oriented system, the

        print foo

is interpreted as "find foo's `print' operation and invoke it".  Presumably a
Postscript file has a different "print" operation within it than a simple
ASCII file, but the result of invoking any "print" operation is to get some-
thing meaningful to appear on a piece of paper.  (An executable file would
either have no "print" operation at all, or would have one which printed out
something like "The executable file xxx".)  In a COMPLETE object-oriented
system, any user can add to the system.  For example, if I come up with some
nifty compression algorithm for images, I can create compressed files whose
"print" operation does the decompression.

The whole strength of an object-oriented system is that the user of an object
doesn't need to know anything about how it is organized, just that it imple-
ments the operations of interest.  In this case, it means that the user should
not have to figure out whether a file is Postscript or simple ASCII or Impress
or whatever - he only needs to know that it is printable.  In fact, in my
conjectural COMPLETE system, I could hand you my compressed file and you could
print it out, not even needing to know that I had compressed it, much less how
I had done so.

Unix provides some limited "object orientation", not in anything the author
describes, but in many printer control shell scripts which use the name of the
file to guess at what is in it - e.g., a file whose name ends in .ps might be
guessed to contain Postscript commands.  These are special-case hacks because
they are in particular pieces of code (the shell scripts), not in the objects
(the files) themselves.  To create a display program, I'd need to look through
"print" shell script and imitate its decision making.  A new file type added
to the shell script would not work in my display program until I learned all
about it and updated my program.  And yet in both cases all I need to do is
convert some kind of encoded input stream into displayable format.

VMS, on the other hand, "seems to have been built on an object-oriented
paradigm before `object-orientation' was well-known".  :-)  An RMS file is
exactly an "object":  It carries along with it the information needed to
perform the different operations it supports.  You can simply "print" any
standard sequential file and the "print" operation "within" the file will
worry about the carriage control and such.

VMS's implementation of "object-orientation" in this sense is very incomplete.
For example, there is no way to mark a file as being Postscript, much less as
having some user-defined "print" operation.  Since RMS now supports a generic
"file semantics" tag (added to allow DECWindows programs like WYSYWIG editors
to determine that a file is DDIF, for example) it could in principle encode
the "is Postscript" information, among other things.

Other OS's do better.  The Macintosh's resource and data forks could be used
in a fairly "object-oriented" way, though as I understand it they are general-
ly used for fairly coarse-grained things.  Still, contrast the Mac's ability
to let you pick only the file and have the appropriate editor come up automa-
tically with what you have to do in Unix (or VMS):  Pick the editor (an editor
for ASCII text, an editor for bitmaps, an executable file patcher) and tell it
to open the file for you.  EMACS users simulate this capability by using
either the file name or magic strings embedded within the file being editted
to select among different packages, but there are limits to how far you can
go with this kind of hacking - and, again, it is limited to EMACS and is
available to other programs only by copying the code or algorithms.

The most fully-developed object-oriented file system in a commercial OS that I
know of is in Apollo's Aegis.  Some very nice ideas there.  Too bad it's been
pretty much killed off by Unix.

Perhaps some of these ideas will re-emerge in Mach.  Nah, that would make it
incompatible with Unix's 1970's technology.... :-) :-)

                                                        -- Jerry