Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!decwrl!sun!guy From: guy@sun.UUCP Newsgroups: net.unix-wizards Subject: Re: Seeking a Development Environment (Sun?) Message-ID: <8422@sun.uucp> Date: Thu, 23-Oct-86 03:49:11 EDT Article-I.D.: sun.8422 Posted: Thu Oct 23 03:49:11 1986 Date-Received: Fri, 24-Oct-86 00:20:35 EDT References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP> <30ceeabf.809c@apollo.uucp> <747@zeus.UUCP> Organization: Sun Microsystems, Inc. Lines: 73 > (UNIX) does not have ... a C compiler which generates error messages > incompatible with standard error postprocessing techniques. These may all > be bugs... What does "standard error postprocessing techniques" mean? You mean Apollo's C compiler doesn't produce PCC-style error messages? Horrors! Burn their compiler people at the stake! They mustn't be allowed to get away with such a greivous sin against the nature of UNIX! Frankly, I wish more compilers would produce better error messages than PCC's. If you really want something that "error" (or whatever) can handle, look into writing a filter that can convert their error messages into the form you need. > but they are certainly incompatibilities between the expected UNIX > environment (BSD in my case) and the reality of the system. This gives *carte blanche* to users to reject any system as "not UNIX" if any data structure, whether intended to be exported to user code or not, isn't identical with the system that implements your "expected UNIX environment"; in effect, you get dangerously close to the notion that UNIX is an implementation, rather than a command-language and C-language interface to various services. SunOS doesn't permit you to dereference NULL pointers, while VAX UNIX (in 4.2BSD and System V, at least) does. Is this another such "incompatibility"? Some of the other items you mention could be considered bugs, assuming some UNIX specification requires that, for instance, changing the mode of a file will not affect its modification time. Others, like the format of compiler error messages, are not specified anywhere. It may be inconvenient to you that they aren't the same as some other implementation, but if the benefits to Apollo's user community as a whole outweigh the inconvenience to some die-hard UNIX hackers, so be it. > To some extent the issue is whether /dev/kmem exists, when it restricts the > portability of standard UNIX tools. I presume you mean the lack of "/dev/kmem" restricts the portability of standard UNIX tools. Well, maybe yes, maybe no. A lot of "standard" UNIX tools depend on the contents of "/dev/kmem", not just its existence; there is *not* guarantee that file table entries point to inodes, and inodes have thus and such fields, and so forth and so on. Will you claim that since various machines don't have the same instruction set as the VAX, it restricts the portability of "standard" UNIX compilers? > Obviously, the folks at Apollo have some way to get around it, since > they have an implementation of ps which appear standard. Come on, it's not that hard to give something the same *user interface* as "ps" just because you don't have "/dev/kmem". "ps" returns information about the processes running on the system. It's none of the user's business how it accomplishes this. > However, I have not yet seen any documentation about how to get at such > information as required by ps. This means I have no mechanism for building > tools that look like "top", or "sps", or other publicly distributed tools > that I might want to have on an Apollo. It might be nice if there were some standard way of getting at information about the processes running on the system. Something like the "/proc" file system implemented on Version 8 might be a reasonable way to handle this. Perhaps if you open "/proc/", and do some special "ioctl", it could return some standard structure containing the information about that process that "ps" would want to know. (Just dumping the "proc" structure won't cut it - there's no guarantee that a particular implementation of the UNIX interface *has* a "proc structure" that contains all the information needed.) -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)