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!decvax!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix,net.micro,net.micro.pc
Subject: Re: Unix on the PC ("IBM" version)
Message-ID: <1561@rlgvax.UUCP>
Date: Mon, 16-Jan-84 17:10:54 EST
Article-I.D.: rlgvax.1561
Posted: Mon Jan 16 17:10:54 1984
Date-Received: Wed, 18-Jan-84 01:08:38 EST
References: <227@vortex.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 79

<fixed this yet?>

	Clearly, for persons who prefer V7-type systems over System III
	(especially on small machines with fairly limited environments)
	the Interactive system will probably not be terribly desirable,
	even if all else were equal.  There are, of course, numerous other
	choices of Unix and Unix-like systems for the PC, some of which
	are presumably faster and smaller than a System III-type port
	would probably be.  (As you can probably tell from this message,
	I've never been a big fan of System III, but that's a personal
	opinion and a whole different topic...) Of course, it is pretty clear
	that porting of V7-oriented applications will generally be easier
	to V7-like systems than to System III variants.

Well, what do you mean by "V7-type" vs. "System III"?  The main real
differences are:

1) S3 has a *lot* more programs than V7, which will be a problem on
machines with limited environments.  Of course, you don't have to provide
all of S3, but the announcement I saw mentioned SCCS, so I'll bet they may
be loading it up.  However, I remember the announcement saying that one of
the video boards would only be supported in text mode, so maybe they
won't bother porting PWB/Graph, which is *g*i*g*a*n*t*i*c*.

2) There are a couple of syscalls in V7 not in S3 (which are frequently not
put in V7 ports; calls like the multiplexed file stuff, "phys", and "lock"),
and there are a couple of syscalls in S3 not in V7.  All in all, fairly
trivial differences.

3) V7 hashes the sleep events but not the buffer cache, while S3 hashes the
buffer cache but not the sleep events.  Of course, you can cache both of
them if you want.  Other than that, the kernels are *extremely* similar
inside; maybe a cycle is wasted here or there by S3 having the end of
various tables in the "var" structure rather than being compiled in, but
I wouldn't expect much performance differences between a vanilla V7 and
a vanilla S3 compiled with the same table sizes.

4) "index" was renamed "strchr" and "rindex" was renamed "strrchr".  This
causes about 15 minutes work at the worst for moving an application from
a Research-based system to a USG-based system; less, if you just set CFLAGS
in the makefile to include "-Dindex=strchr -Drindex=strrchr".

5) The TTY driver is different.  Most programs which do funny things with
the TTY modes are screen-oriented programs which go into CBREAK mode with
echo turned off; they usually have one place where they do this and one place
where they restore the modes.  Just stick in an #ifdef, and go out of ICANON
mode with echo turned off on USG systems.

6) The way you get local timezone information changed.

7) Some command syntaxes have changed.

8) "dbm" doesn't come with S3, but would port with zero work.

So I don't think that a properly-written program would have much trouble
at all moving from V7 to S3.  We've moved several large programs of that
sort with no trouble at all, including a *lot* of screen-editor like programs
(and if you use a screen package like "curses", just change "curses" and
most of the programs will require no change).  I generally think of V7
and S3, for a lot of purposes, as variants of one system; the differences
between them - or, at least, between a "core subset" of V7 and of S3, excluding
all the stuff added to S3 and the stuff like "dbm" and "learn" that never
went from Research to USG - are a lot less than those between V6 and V7.

I also don't think that any performance differences between V7 and S3
implementations are likely to be due to intrinsic characteristics of V7 and S3;
they're more likely to be due to differences in what the implementor did with
V7 and/or S3.  If PC/IX is a fairly vanilla port of a VAX OS to a PC, I could
easily see it being slow; Venix, I think, actually uses a V6 file system rather
than the file system used by V7 and S3 for performance reasons.

Overall, I don't see the fact that PC-IX was based on S3 as being a deficiency;
S3 does several things more nicely than V7 (for instance, vanilla V7 doesn't
have "CRT rubout", while vanilla S3 does), and the only problem with porting
S3 to a small micro is that it's even huger than V7, so you may want to be
*very* selective about what you port.

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