Seeking a Development Environment (Sun?)

[guy at sun.UUCP]

> (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/<pid>", 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 at sun.com (or guy at sun.arpa)