Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.sources,net.unix,net.lang.c,net.unix-wizards
Subject: Re: QUERY: Coding convention
Message-ID: <2065@rlgvax.UUCP>
Date: Tue, 3-Jul-84 00:25:20 EDT
Article-I.D.: rlgvax.2065
Posted: Tue Jul  3 00:25:20 1984
Date-Received: Wed, 4-Jul-84 00:14:01 EDT
References: <793@ihuxx.UUCP> <80@cbosgd.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 33

I agree that V7 and System III won't pose too much of a problem; if the
target system is System III, then either the System V version will work
(modulo bugs fixed between S3 and S5) or the System V version requires
S5 features, in which case it might be hard to get the software to work
on another version anyway (if it uses shared memory it'd probably require
a major rewrite not to use it, and be too slow once it was rewritten).
V7 may not go away - it has its partisans out there.  However, if SYSV is
taken to include System III in most cases, we might be able to define V7
as "everything that isn't BSD or System V".

I'd put in an additional plea - have "VMUNIX" mean "this system has lots
of address space which isn't too horribly expensive to use", and be used
to conditionalize things like "nroff" keeping its temporary file in memory -
and *not* be used to mean "Berkeley UNIX".  The USDL (or whatever it's being
called this week) will surely someday release a paging version of "USG" UNIX
(or make all the demand paging hardware on the 3B series look pretty silly),
and VMUNIX should apply there also.

Oh yes, while we're on the subject, could everybody out there please pick up
the "directory library" that was done for 4.1BSD in preparation for the
change to directory formats in 4.2BSD?  It works under all the non-4.2BSD
UNIX implementations (they all use the V7 file system except for V6, and
even V6 had the same directory format), and also opens the door to porting
software to "UNIX overlays" on top of OSes that don't treat directories like
regular files for reading, or that have yet *another* directory format.
(In other words, it makes directories into abstract objects, and permits you
to write code that handles directories which is independent (by and large)
of how directories are actually implemented.)  I'd also vote for putting
a "rename" routine in, for the same reason, but that's getting off the
topic.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy