Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c Subject: Re: Unix/C program modularity Message-ID: <2933@sun.uucp> Date: Sat, 26-Oct-85 18:10:07 EST Article-I.D.: sun.2933 Posted: Sat Oct 26 18:10:07 1985 Date-Received: Mon, 28-Oct-85 04:17:04 EST References: <637@dicomed.UUCP> <1219@wucs.UUCP> <133@sdcc7.UUCP> Organization: Sun Microsystems, Inc. Lines: 59 > 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