Seeking a Development Environment (Sun?)

[guy at sun.UUCP]

> In either case, it is an ad hoc standard (it has been propogated to many
> machines) and it's one more hurtle to hassle (via a filter or whatever)
> when migrating to the machine.

Life's a bitch, then you die.  There are plenty of problems when migrating
to a new machine, like learning that data formats, alignment requirements,
ability to get away with dereferencing null pointers, ability to sneak in
the back door of standard I/O in particular ways, etc. aren't the same on
all machines.

> This is principally an issue of content, not syntax (though you may argue
> that syntax can produce better error messages).

Yes, I would.  It might be nice for compiler error messages to point out the
precise place where the error occurred; Sun's compilers print out a token
near where the error occurred, but there may be more than one occurrence of
that token on the line in question.

> Absolute rejection of an environment is one thing--evaluation of the level
> of "compliance" (given that there is no objective indicator of that yet) is
> another.  My point was NOT that DOMAIN/IX is not UNIX, just that though they
> have made great strides towards transparency, that it is still an emulation,
> subject to the differences in dark corners that any emulation risks.

Or the differences in dark corners that many other changes in the
implementation risk.  You pays your money and you takes your choice.  Some
aspects of the implementation are considered to be just that -
characteristics of the implementation, not features of that implementation.
It might be nice if the information in *some* system data structures were
made available to applications, preferably in some fashion pretty much
independent of the details of those data structures (i.e., don't give people
access to the shared text table, because some versions of UNIX don't have a
shared text table that resembles V7's).  Some of these "dark corners" are
never going to be lit up; the vendor(s) reserve the right to make later
releases behave differently in those cases, and are perfectly justified in
doing so.

> And this is exactly the point.  I may not have a /dev/kmem whose data
> structures are *exactly* the same or even nearly the same, but I can deal
> with that, given sufficient documentation to make the changes necessary to
> port the tools to this new environment.  UNIX environments are essentially
> as closed as Apollo in this regard--/dev/kmem is no better documented than
> the means by which Apollo's ps command derives its information.  If
> Apollo/DOMAIN-IX came with a caveat that /dev/kmem does not exist, but the
> information contained within is available through some specified mechanism,
> I would be content.  But I have seen no such documentation.  We do have
> sources for UNIX, though, so I can get the information I need for that
> environment.  

You have sources for some versions of UNIX.  For other versions, you may
only have some include files.  You may be able to guess how the data
structures work, but you may end up guessing incorrectly.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)