guy@rlgvax.UUCP (Guy Harris) (07/03/84)
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!guymark@cbhydra.uucp (07/05/84)
> 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. Hear hear! vi uses the ifdef for EXACTLY this purpose. I'd like to second this plea. > 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? Don't hold your breath for USDL to put this in - those people are incredible Berkeley-phobes. Too bad, too, because this is an important feature.
marcus@pyuxt.UUCP (M. G. Hand) (07/06/84)
Connected with this (the machine type defines), I encountered the following problem a couple of weeks ago: Between USG 5.2 and 5.3 (sic) - these are S5 releases for the 3B5 - the defined constant _u3b disappeared from the system with the consequence that one of my programs stopped compiling. Now I have to: #if defined(_3b) || defined(_3b5) (Not too painful admittedly, but all I wanted to know was whether it was a generic 3b system.) What this does is to underline the need for a series of standard names which covers Unix versions and the hardware on which it runs; and, when I say *standard* I mean well known, well documented, and universally adhered-to. (fat chance!). I add my voice in support of Mark Horton's proposal. Marcus Hand (pyuxt!marcus)
henry@utzoo.UUCP (Henry Spencer) (07/07/84)
I can think of one other thing that would be useful to have around,
so that #ifdefs could test it. As we all know, there is an ANSI C
standard in our future somewhere. The standard specifies some bits
of very useful syntax that most existing compilers barf on at the
moment. It would be real nice to have a predefined symbol along the
lines of "pre_ansi" so that one could write code like:
#ifndef pre_ansi
... do it right ...
#else
... kludge needed for old compiler ...
#endif
This would permit gradual transition to the new standard. (I suggest
"pre_ansi" rather than "ansi" on the theory that the standard should
be the default from the beginning.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrymark@cbosgd.UUCP (Mark Horton) (07/08/84)
In response to the query for a standard name for UNIX variants, e.g. BSD, USG, etc, for ifdefs. It seems to be traditional to use USG for SysIII/SysV versions of UNIX and BSD for nBSD. However, now that the marketplace has settled down a bit, I'd like to propose a new convention. Berkeley has settled on two names: 2BSD and 4BSD (there are various releases, e.g. 2.9BSD, 4.2BSD, within these names). 2BSD seems to follow in the footsteps of 4BSD and can be distinguished because of hardware differences. AT&T has also settled on a name: System V. It has releases, System V, System V Release 2 (SVR2), etc. Indeed, the name USG (standing for Unix Support Group) no longer makes sense, since the organization is now called the Unix System Development Lab (USDL) and reorganizes often enough to make this name useless. I propose we pick two names: BSD and SYSV. This covers most of the products out today, leaving out only V7 and System III based products. We could include V7 and SYSIII as two other names if desired, although it isn't clear to me how long lived these systems will remain without incorporating features from either 4BSD or SysV. I would like to see these names automatically built into the C preprocessor, along with the existing hardware names (vax, pdp11, sun, unix). Systems not having them in their cpp could add them as -D flags in the makefiles.