Porting UNIX Applications to the Mac

Wed Sep 17 13:21:05 AEST 1986

In article <1091 at hoptoad.uucp> tim at hoptoad.UUCP (Tim Maroney) writes:
>This issue is going to become more and more important as the UNIX Mac is
>released.  Apple has committed themselves to preserving the Mac interface
>while also supporting UNIX(tm).  But my gremlins (actually, experience with
>the Mac Programmer's Workshop) report that they don't really have a complete
>or general paradigm for doing this yet.  I'd like to see some discussions on
>how this ought to be done.
>
>Briefly, the problem is this.  On the Mac, all user applications are graphic
>applications.  On UNIX, very few applications use graphics beyond those
>attainable on a hardcopy character-graphics terminal.

The problem is a difference in concept.  Unix creates a "stream of bytes"
which can be treated as a "stream of bytes" OR a "stream of objects".
In Unix, common objects include letters, words, lines, paragraphs, and
pages.  Applications of various "classes" such as find, sort, grep, and
awk, are actually subsets of the same type of record.  The important factor
here is that information that may be part of a larger set of classes, can
be extracted for use by smaller class operators.  C source can be "grepped"
for comments that can be manipulated by "awk" into information that can
be used by sort, join, lorder, find, and other "delimited field objects".

The Mac currently supports the concept of a "Stream of Objects", but objects
are often defined and remain unique to the application which creates them.
A "box" in MacProject may be quite different than a "box" in MacDraw or
MacPaint.  The clipboard and scrapbook are capable of supporting a subset
of these objects, but the ability to transform objects is not considered
mandatory to the application.

Such transforms are not impossible.  Other systems, which at least emulate
the Mac user interface, also define a standard set of objects, with the
capability for extensions.  Postscript has this capability as well.
VDI type interfaces are a key element.  A full VDI interface can take
"standard input" from a mouse/keyboard, or file, and display it to a
"bit-map screen", an "ACRTC device", a Laser Printer, or a disk file,
without knowing or caring which device is the output, or where the
output will go.

It may be possible to for example "grep" for "boxes containing text pattern",
but only if "boxes containing text pattern" are defined in a standard way,
such as group(box(x1,y1,x2,y2),text(x,y,string)).

Parsing of these groups and object streams requires an actual parser, but
should be possible, even simple to do.  A good test of such a parser would
be to output in "human-readable text form" any input file in "standard
stream of objects file", and have the "human readable form" become input
to a parser which will convert it back into "stream of objects" form.
Now you can put standard text filters, as well as "stream of object" filters
between the to resources.

Another concept that is important is that of "strings" as well as "packets".
Packets require that you know about certain information inside the packet
(such as number of objects, length in bytes,...) before the packet can
be sent.  Strings simply require an "end of string" delimiter.  A simple
object of this type could be added to the existing archetecture and
would enable creation of objects larger than the storage space available,
very important when only parts of a collection are needed.

>While the flexibility
>of the UNIX system for an expert programmer has never been approached by any
>other operating system, it is notoriously unfriendly and mystifying to naive
>users.  This is too bad, because many of its applications, such as grep,
>would be very useful to any user at any level of experience.

This is a valid point.  A few new products, such as Office-Power, GNU Emacs,
VSH, and a large assortment of other "visual shells" have made good progress
in this direction, but are most often limited by the weaknesses of the
"terminal interface" rather than the archetecture.  Building "classes"
of operators is more difficult, but not impossible.  The object oriented
design, rather than object oriented language, is all that is often needed.

>Most bitmapped UNIX systems just ignore the problem and pretend that it is
>sufficient to use bitmapped output devices to provide multi-window terminal
>emulators.  The Mac shows that this is not true, that for user interfacing
>every application should be a graphics application, that the presentation of
>options to the user as controls and menu items achieves much more user
>friendliness.

It is true, to a point, that each application should have a "graphics
interface" on the front end.  But it is also appropriate to have one
of the options be "text arguments", or function keys.  In addition,
the hierarchy of menus could be three dimensional, or even deeper.  For
example, the top line options might change as the various options are
scanned, allowing search of say 64 options using a simple 8x8 matrix,
of which only the options for the given menu selection are given.

>But this leaves open the issue of integrating the existing and
>extremely high-quality UNIX system into the Mac's graphics-intensive
>environment.

Try to think of it this way, the best part of UNIX is it's "back end"
or "application to application data compatibility".  The best part of
Mac (most of the time) is it's "front-end" intuitive graphics user interface.

>To make matters worse, it is impossible to just change the applications to
>use a bitmapped user-friendly interface.  One of the great strengths of UNIX
>is the ability to create multi-process programs, even on the fly, by using
>pipes and i/o redirection to chain together multiple programs.  This is made
>possible only because of the use of a character-stream, non-graphics
>interface for most applications.  If this is lost, then no way is it UNIX.
>But if it is retained as a user interface, no way is it either Mac-like or
>novice-friendly.

How about the ability to "draw circuits" of pipelines and filters for
"batch type jobs".  In fact, "tees" could get very interesting.  A "data
flow diagram" with prompts for each member of the circuit could also
be useful.  If input format and output format could be specified, it
might even be possible to normally restrict "next in chain" options
to those commands which create/use the appropriate format.  Of course,
it should be possible to enter text stream commands at some level as well.

As mentioned before, byte-streams and graphics DATA interfaces are not
necessarily mutually exclusive.  Conversely, character interfaces and
character streams are not necessarily mutually inclusive.  Try putting
a "pipe" between your standard input and VI if you need convincing.  A
"pipe" between VI and standard output might actually be useful (VI
would only need one definition of "termcap" and a "curses interface"
similar to those used by plot, could do the conversion to specific
terminal codes).  For editors, it might not be necessary to have
"streaming" capability, proprietary formats, during the actual editing,
might also have legitimate use (VI and various other interactive
editors put the proprietary format file in /tmp or /usr/tmp, often
under a process id type configuration.  The only special need is that
the final product be either saved or convertable to, a "standard data
interface format".

>To take a concrete example, the grep program provides an extremely useful
>search facility.  On the Mac, it should be a dialog box allowing
>specification of a range of files to search (using an extended standard file
>interface) and a regular expression to search for, with help windows to
>explain the use of regular expressions.

So far, not really a problem.  I can generate
'>grep 'object >' using either a text specification, or a visual interface
which creates the text specification.  If you wanted to be really perverse,
you could set up binary "argv, argc, and env", but that may be and extra
step.

>If this is the only interface, it
>becomes impossible to use grep in multi-process programs.

Only if you begin execution immediately.  Your "shell" parses for a complete
command in unix, your "Mac Shell" could wait until you pressed an "O.K."
dialogue box for the "Shell Command".  The command(s) which make up the
stream could be done as picture drawings, even with a "save" feature.
If you wanted to make it real interesting, you could "display" text mode
input versions.

>So it would
>appear that both interfaces need to be retained, but in different contexts;
>and this is true not only of grep, but of most other applications as well.

For matters of taste, this is true, but again, the two can compliment rather
than conflict with each other.

>There seem to me to be two basic options for solutions to this problem (or
>to put it in the usual jargon, this is the top level of the decision tree).

>First, we may modify the existing UNIX applications.

If you mean, modify the actual method "grep" uses for parsing it's arguments,
this may not be necessary.  In reality, you need a hybrid between the
"shell" and the "man" to create a visual shell that can create "standard
exec and popen" type calls for the shells.

>Second, we may make
>some sort of separate input/output filter for each application.

Again, transforming from one common form to another is not out of the question.
This however does not need to be done in each application.

>In either
>case, we need some way of detecting the type of the input, output, and error
>channels, which may be tty (or pseudo-tty) windows, pipes, files in the file
>system, or bitmapped i/o systems.

This is the "magical" feature of VDI.  What you will need is drivers which
use the standard "Virtual device" format, and transform tasks to convert
from one type to the other, hopefully in a "per object" mode.  Editors
should issue VDI calls directly (the same way they issue quickdraw calls,
but implementation of quickdraw calls rather than use of them become device
dependent.  In other words if you.

	fd1=fopen("window","w");
	fd2=fopen("diskfile",w);
	box(fd1,x,y,x2,y2);
	box(fd2,x,y,x2,y2);

the second box command might simply be a write of whatever the token for
"box" was and the binary co-ordinates.  So long as all applications agree
on one definition of "token for box", your all set.  Applications that
didn't use the standard set would have to provide the transforms to AND
from their proprietary format to at least one of the "general purpose"
formats.  Apple would be responsible for transforming from one "general
purpose" format to another.  For example "scrapbook to postscript" and
"postscript to scrapbook".

>A simple ioctl will suffice for this
>purpose.  In the first solution, the type checking is done by the
>application itself; in the second, it is done by the "shell" (which would
>presumably be something like Servant).

An important factor here is that the input type and output type of not
only the files, but also the applications must be available to the shell.

>It seems cleaner to me to set up separate i/o filters, although this would
>probably increase system overhead.

Yes this is extra overhead, but it might not be necessary to do it often.
This might be used to extract a small portion of the file.  The important
thing here is that A) only a portion of the application needs to be running,
B) The user isn't required to remember where in the sequence he is when
he takes a break (with data stuck in the scrap).  He can also do something
else while waiting.

>It is possible that some specification
>language for such i/o filters could be created that would obviate the need
>to write a C program for filtering and also not require that a separate
>process run to mediate between the program and the user.

BINGO!!!  Apple already has three possible specifications, subsets and
supersets could be added, possibly even by the "install" of running and
application (sounds more like OS-9 all the time).

>Hacking the UNIX
>applications themselves seems like a much bigger job, and one that would be
>likely to introduce new bugs into the applications, which at this point are
>fairly well-tested and bug-free.

You may want super-graphics versions of certain types of filters, but
it is probably a good idea to keep the UNIX versions as-is.

One of the advantages of doing text-mode formats, is that humans are excellent
pattern recognisers.  They can often identify a pattern which would not
be obvious to the computer, the parser, or the user, when only binary
modes are available.

>Any other ideas on this subject?
>-- 
>Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles

There are a few, hopefully constructive ideas, for getting the best of BOTH
UNIX and MAC features, without giving up too much of either.

Rex Ballard.