Path: utzoo!attcan!uunet!husc6!mailrus!ames!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.lang.c
Subject: Re: CURSES package for Atari ST
Summary: Portabilty and BS
Message-ID: <524@wsccs.UUCP>
Date: 14 May 88 02:13:16 GMT
References: <2853@pasteur.Berkeley.Edu> <51436@sun.uucp>
Lines: 68

In article <51436@sun.uucp>, limes@sun.uucp (Greg Limes) writes:
> In article <2853@pasteur.Berkeley.Edu> sarge@fraud.Berkeley.EDU (Steven Sargent)
> decries the sad state of UNIX, with references to the sentiment that
> "all the world's a VAX" ...
> >
> >Now can we get on to something else?
> 
> I agree. Just think how portable a program will be, when its source will
> compile and run on Berkley UNIX, AT&T Unix, Xenix, Ultrix, SunOS 3.x
> for Sun3, SunOS 4.x for Sun3, SunOS 3.x for SPARC, SunOS 4.x for SPARC,
> and whatever we are selling on the Sun386i ... the mind boggles. But
> then, such a program would probably be free of all the various quirks of
> all those various operating systems.

Ah.  Faith.  A wonderful quality.  Totally unrealistic in the naked light
of Occam, but a wonderful quality, nonetheless.

As long as library routines are not standardized, total machine independence
is impossible, even if we were to grant that the bastardization of UNIX by
the folks who brought you the ioctl() controlled modem of the 7300 bashing
heads with the folks who bought you the un-cola of UNIX machines, SPARC, is
a good idea.  It isn't a good idea (opinion) and total independance is not
really possible, even at the source level, given that people seem to still
be going in 8 directions with "God's own machine".

The crux is, of course (coerce?) the C compiler and it's cast of thousands,
the library routines.  We have portable code that runs on all of the above
with compiler flags, but there is a great dichotomy between Berklix and
ATTix (Berkely and AT&T UNIX, respectively)... ioctl(), curses.h, and
termcap vs. (blechhh!) terminfo.  At the very least, we have to change the
methods we use to do I/O.  At the most, we have to change design strategy
and method of approach.  For instance, SPARC.  The C compiler does not
support variable argument lists or alignment of structures or other such
stuff (very well/well/at all).  Code runs faster if you can make some
assumptions that using such constructs aparrently thwart, and that sells
more computers, in the short run, I suppose.

An ideal environment certainly would allow total portability, with the
possible exception of:

#ifdef SUN
#define NAME "A Sun System"
#endif

[Obviously, ANSI is not the answer here -- ed]

But it is not likely, considering that major vendors are willing, nay, eager
to sacrafice portability of applications written by developers for the sake
of squeezing a few more drops of "marketability" (yes, the quotes ARE necessary)
out of a machine.

How marketable is something if no third party vendors produce anything for it
because it is nearly impossible to use the C compiler?  I would much rather
spend my time programming C than porting somthing to a machine that runs
something that looks like C, but isn't.

[Perhaps SUN should be sued for "look and feel" on their compiler -- ed]

Besides, you shouldn't lump SPARC in with UNIX machines sporting things
resembling compilers.  It gets me all worked up.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'Admit it!  You're just harrasing me because of the quote in my signature!' |