Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: net.micro.mac,net.unix Subject: Re: Porting UNIX Applications to the Mac Message-ID: <1091@hoptoad.uucp> Date: Mon, 15-Sep-86 05:09:35 EDT Article-I.D.: hoptoad.1091 Posted: Mon Sep 15 05:09:35 1986 Date-Received: Mon, 15-Sep-86 18:36:01 EDT References: <1572@cbdkc1.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Centram Systems, Berkeley Lines: 70 Xref: mnetor net.micro.mac:6986 net.unix:5487 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. 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. 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. But this leaves open the issue of integrating the existing and extremely high-quality UNIX system into the Mac's graphics-intensive environment. 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. 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. If this is the only interface, it becomes impossible to use grep in multi-process programs. 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. 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. Second, we may make some sort of separate input/output filter for 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. 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). It seems cleaner to me to set up separate i/o filters, although this would probably increase system overhead. 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. 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. Any other ideas on this subject? -- Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa) "Little people, with tiny brains; little bullets flowing in their veins! What do they want? They want you!" - Oingo Boingo, "Tiny Guns"