[9fans] Why not APE?

[9fans] Why not APE?

[baldwin]

Russ has it dead on: Plan 9 isn't attempting to be compatible with
"Standard C" and has no previous usage to be worried about.  It's
trying to come up with a clean system -- keeping old baggage around
is *not* the way to do that.  And what would be the point of the
old baggage?  Does anybody really believe that native Plan 9 would
be able to compile and run off-the-shelf Unixoid programs?  To do
that would require major damage to Plan 9.

The APE solution seems to work just fine: if you want "int main()"
and stdio and signals and tcgetattr and sockets and all that other,
err, junk, well go right ahead and use APE.  It seems to work as
well as can be expected (don't blame APE for autoconfig hell).
For heaven's sake, even X11 was compiled under it.

Now this may be a little weird, but I for one use the Inferno C libraries
to compile Plan 9 programs on Unixoid boxes.  They are sort of an inverse-APE.
They don't intend to be a complete implementation of the Plan 9 C libraries,
but they do well enough that my sundry Plan 9 programs compile and run on,
say, Solaris (like the mk and C compiler tools of Inferno do).  And I don't
have to de-Plan 9 them.

I am quite happy that the baggage of the past can be left to the side
and not intertwine itself with Plan 9 and constrain it.  If I wanted a
system that could compile and run all the "lovely" Unix programs out
there, well I'd go get FreeBSD or something.

Re: [9fans] Why not APE?

[Douglas A. Gwyn]

baldwin@vitanuova.com wrote:
> Russ has it dead on: Plan 9 isn't attempting to be compatible with
> "Standard C" and has no previous usage to be worried about.  It's
> trying to come up with a clean system -- keeping old baggage around
> is *not* the way to do that.  And what would be the point of the
> old baggage?  Does anybody really believe that native Plan 9 would
> be able to compile and run off-the-shelf Unixoid programs?  To do
> that would require major damage to Plan 9.

C != UNIX.

There is a *lot* of existing *portable* C code that could not be
effectively used on Plan 9 if there is not a standard-conforming
implementation of C.  The idea that one must throw away existing
carefully designed and written code and start all over is plain
stupid.

> The APE solution seems to work just fine: if you want "int main()"
> and stdio and signals and tcgetattr and sockets and all that other,
> err, junk, well go right ahead and use APE.  It seems to work as
> well as can be expected (don't blame APE for autoconfig hell).
> For heaven's sake, even X11 was compiled under it.

You have missed my point.  Why did Plan 9 choose to call its
native start-up user function "main" instead of "mains"?
There need be only *one* compilation environment, not *two*.

> Now this may be a little weird, but I for one use the Inferno C libraries
> to compile Plan 9 programs on Unixoid boxes.  They are sort of an inverse-APE.

Similar to libXg etc., sure.  We've been doing similar things for
decades.

However, pretending that you have your own separate API standard
means that you have to reimplement the API every time you export
to another platform.  I used to do this for the UNIX System V
environment on BSD variants, and I can tell you that it is a
significant drag on resources.  If there is an established
standard that provides adequate facilities for the purpose, then
using the standard facilities means you can spend more time on
developing applications and less time on implementing support.
Applications are more rewarding, in more ways than one.

Some people seem to think that I'm arguing against Plan 9 having
its own design for the native C environment, but I'm doing no
such thing.  All I'm saying is that it is in the long run
counterproductive to make it *intentionally* conflict with the
standard environment.  An integrated environment is more useful
than two separate ones.