Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!teklds!zeus!bobr From: bobr@zeus.UUCP Newsgroups: comp.sys.apollo Subject: Re: Is an Apollo a UNIX box? Message-ID: <1760@zeus.TEK.COM> Date: Thu, 28-May-87 18:57:49 EDT Article-I.D.: zeus.1760 Posted: Thu May 28 18:57:49 1987 Date-Received: Sat, 30-May-87 06:21:53 EDT References: <8705271752.AA06674@apollo.UUCP> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 100 Jim Rees replied to my statement: Apollo currently is NOT a UNIX box. It runs an operating system called AEGIS, and provides libraries to simulate SV and BSD system calls, plus a lot of hacked up versions of standard programs which attempt to give the APPEARANCE of a unix system. with: I decided to try to verify this claim, and took a look at the source code to some of our unix commands. I just looked at the Berkeley commands, because that's what I use. I appreciate his review of changes for Domain/IX. It is the first time I have seen such a concise description of the modifications made to BSD UNIX utilities for Domain/IX. I have a few comments on the material presented. 'ar', 'cc', 'ld', 'nm', and 'size' are different because we don't use a.out. Neither does sys V, ... I don't know about the SV comment, but I do know that the standard way for generating nroff terminal descriptions (as found in /usr/lib/term) is to compile a C source file and strip it. I believe this works both under BSD and under SV, but it doesn't on an Apollo, because the object format bears no resemblence. I'm not claiming that it should--just that this is one of the loose ends in Apollo's emulation of UNIX. There may be other dependencies here, but nroff driver tables is one I know about. 'ps' uses well-defined interfaces rather than muck about in /dev/kmem. I appreciate the fact that Apollo is trying to clean up some of the dangerous coding practices employed in the implementation of UNIX. I would like to see the well-defined interface used for implementing 'ps'. I would like to port 'sps', which has in my opinion a superior user interface. However, since I can get neither the source for the Apollo version of ps nor documentation or code for this interface (as far as I know), I'm stuck. 'csh' and 'sh' have quite a few hacks in them. These are hard to characterize. Some of it has to do with better error reporting. Some of it has to do with a lot of other things, like process forking/job control. Because of the underlying differences in process support, Apollo workstations do very poorly in forking processes. They work much better when the process address space is reused (controlled via the INPROCESS environment variable). /com/sh provides some nice error reporting features, which do not work under the modified /bin/sh or /bin/csh, and the usual UNIX tools (e.g. adb) are not available to do the corresponding sorts of probes under the UNIX shells. 'login' and 'passwd' are pretty hacked up. This has to do with our distributed registry, which I think is better than /etc/passwd. I won't comment here. Please note a recent posting on the difficulties this system has introduced in reconfiguring nets operating under Domain/IX. Anyway, I don't think I would want to work for a 'pure' unix box company. It's obsolete technology. Is that why sr10 is going to have a kernel level implementation of UNIX system calls? Or why IEEE is formulating operating system standards that look very much like UNIX? Or why superficially AEGIS itself looks very much like UNIX, with names changed to protect the guilty? Give me a break. Not mentioned in Jim's summary are changed to the support libraries. I'm not sure how much difference exists, but I've seen mentioned on the net that UNIX system calls fail when using DMR3D, and I have personal experience with TERMCAP. The Termcap library implemented on Apollo systems is something of a kludge. Under conventional UNIX systems is the notion that control information can be sent to the "screen" via the same stream that transmits data. This is a reasonable conclusion for a system first implemented on "terminals." Implicit in this notion is the ability to divine a set of character strings which control the screen in certain ways, and a library which can contain the particular character strings to service a great number of terminals. Unfortunately, control or special data access to the Apollo screen is available only through a functional interface. So in order to support termcap, some magic had to be employed. A call to tgetent() to establish a particular terminal type automatically spawns a vt100 terminal emulator task, which subsequently acts as a filter with predefined and unchangable characteristics. These characteristics include the creation of a new pad which covers the existing input and output pad, remaining in place until the program which called tgetent() terminates. In 4.2BSD the easiest way to find the width of the screen was via termcap (this information has been moved to the terminal driver in 4.3). Thus the simple act of trying to determine the width of the window prior to formatting output places an obscuring pad which captures all output for the duration of the program, and on exit any program output issued afte the tgetent() call similarly disappears. MH mail is an example of programs which use this technique and so require nontrivial changes to work on Apollo systems. Another example is more(1). I would class myself as a novice Apollo user, yet I was able to find these and many more differences between the BSD system I use and the Apollo system I am trying to learn in my free time. I thank Jim for confirming my contention about Domain/IX. Nothing in my claim was contradicted by his posting. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK