Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!rb From: rb@cci632.UUCP (Rex Ballard) Newsgroups: net.micro.mac,net.unix Subject: Re: Porting UNIX Applications to the Mac Message-ID: <365@cci632.UUCP> Date: Tue, 16-Sep-86 23:21:05 EDT Article-I.D.: cci632.365 Posted: Tue Sep 16 23:21:05 1986 Date-Received: Wed, 17-Sep-86 06:12:47 EDT References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> Reply-To: rb@ccird1.UUCP (Rex Ballard) Organization: CCI, Rochester Development, Rochester, NY Lines: 250 Xref: mnetor net.micro.mac:7033 net.unix:5517 In article <1091@hoptoad.uucp> tim@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. This is one option when two applications have incompatible formats. In this case it might be necessary to have two transform filters. For example MacDraw.Print GCCfile |MacDraw.to_scrap |MacWrite.from_scrap|MacWrite.grep|\ MacWrite.to_vdi|Laserwriter 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.