[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    Re: [9fans] Why not APE?
From:       "Douglas A. Gwyn" <gwyn () arl ! army ! mil>
Date:       2001-04-27 14:42:05
Message-ID: 3AE97E52.3B6E58AF () arl ! army ! mil
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]