Unix/C program modularity

[Guy Harris]

> The problem here is not a question of programmers forever reinventing the
> wheel, but rather a lack of uniformity of the various flavors of Unix.
> Most defensive programmers take into account that the programs they write
> might be ported to v6 or XENIX or even a micro that only has an incomplete
> implementation of the stdio package (if that much).

If you're talking about a micro with only an incomplete standard I/O
implementation, you're talking about the lack of uniformity of various C
implementations, not of various flavors of UNIX.  Every UNIX since V7 has
had a standard I/O library, although there are some differences between
them.  The original V6 didn't, but V6 without the "50 changes" and
"Phototypesetter, Version 7" is sufficiently different from all subsequent
UNIXes that trying to write code that builds under it and other systems is
extremely difficult.

> Writing a program with a myriad of fancy pipes and filters may be faster
> and easier, but if you don't want to go the extra mile to write emulations
> of certain system calls...

Again, if you're talking about "standard" UNIX system calls, you're dealing
with the problem of porting between different operating systems.  I know of
few languages at the approximate level of C which permit you to
transparently port applications which run as screen editors, or which run
other programs, or....  The whole reason the people at Bell Labs ported UNIX
was to get around the problem of dealing with multiple machine architectures
*and* operating systems:

	The realization that the operating systems of the target
	machines were as great an obstacle to portability as their
	hardware architecture led us to a seemlingly radical suggestion:
	to evade that part of the problem altogether by moving the
	operating system itself.  (S. C. Johnson and D. M. Ritchie,
	"Portability of C Programs and the UNIX System", BSTJ Vol. 57,
	No. 6, Part 2, July-August 1978, pp. 2021-2048)

At that time, both machines (PDP-11 and Interdata 8/32) were (I presume)
running V7.  Since then, several cooks (the UNIX Support Group/UNIX System
Development Laboratory, U. C. Berkeley's Computer Science Research Group,
10000 other universities, Microsoft, 10000 other UNIX vendors, etc., etc.)
have made their contributions to the broth.  I hear that lots of
applications broke when moving from VMS 3.x to VMS 4.x also...

> C and Unix aren't always synonymous, especially on micros:  witness the
> Amiga and the Atari ST.  If they (the ANSI C standards committee) don't
> stay on track, they may jeapordize their whole standard.

Amen.  The trouble is that C has, for example, no built-in I/O constructs,
so the original UNIX C implementation had an I/O library.  A portable
version was written (two, actually - the Portable I/O library and its
replacement, the Standard I/O library), but it still had a UNIX flavor to
it.  The ANSI C committee is doing some really dumb things like building the
signal mechanism into their standard.  Anybody who wants to write an
application in *any* language which they want to run under, say, VMS and
UNIX, and which makes use of the operating system's facilities in ways that
can't be subsumed by the languages built-in I/O capabilities is going to
have to build an OS interface library and hide the OS dependencies there
anyway.

	Guy Harris