[comp.unix.xenix] The WHOLE scoop on UNIX 5.3 for the 80386

rich@devvax.JPL.NASA.GOV (Richard Pettit) (09/18/87)

[grrrr]

Ok, I'm sick of all this massive confusion about who, what, where, and why
UNIX 5.3 for the 80386 is, isn't and should be. Since I have the scoop, I
think I'll pass it all on to the world.


In the beginning, there was AT&T.

(You knew it would start that way didn't you ?)

AT&T developed UNIX 5.3 in their labs getting it to run on their line of
3B computers. At this point, they figured that it would be a great idea
to put the system on a 80386 chip. Why not ? They were going to end up
selling 80386 machines some day soon anyway. So, where is the best place
to go to get your OS ported to a chip ? How about the people who made
the chip. Well, that's what they did. Intel was contracted to port the
5.3 code to the 80386. Intel, not wanting this massive responsibility
for themselves decided to subcontract the work. They chose the best
company that they could to do the port because they (Intel) were
responsible for delivering back to AT&T a running version of 5.3.
This company is Interactive Systems, Inc. in Santa Monica, CA.

Interactive (call them IS for short) went quickly to work porting the code,
and in no time at all they had a working version. Not ready to release yet,
but working.  The way it works is like this: IS would complete a release of
the code, be it beta or whatever, and they would release the code back to
Intel. Intel would in turn release the code back to AT&T. AT&T would then
release the code to those companies which had contracts with them to supply
the source to 5.3 as it became available.

So, IS is not just a code porting shop. They also sell UNIX 5.3, but they
only sell it to companies. They know very well what kind of crap Microport
goes through trying to support their systems. (Lets face it, a great deal of
people out there are buying UNIX for their AT and they don't know crap about
crap when it comes to crap. I wouldn't be a customer support person for
anything. People calling asking questions like "I put the floppy in the
drive without taking the cover off the disk and it won't read it. What should
I do ?".) Anyway, since IS sells this system too, they take the code, make some
changes to it and market it as two different products. The first is called
386/ix. This is just the stock 5.3 kernel and associated utilities, such
as compilers, uucp, sys adm, and so forth. The second is called VP/ix. This
is 386/ix with extensions to support the "virtual PC" mechanism. This is
the MS-DOG under UNIX option. It utilizes the virtual-86 mode of the
80386.

Now, obviously, since IS is the company doing the port, they are going
to be the people who offer the product first right ? Wrong. IS will only
sell the system if it is absolutely AT&T SVID certified. And they were,
in fact, the first company to have such a product. And to give you a
little clue, they only started shipping their 386/ix product about the
end of August. What does that mean to those of you who got a similar
product from Bell or Microport before then ? That's right. Beta release.
Surprised ?

"So, whose product is it that I got when I bought my Bell Tech. machine ?"
you're asking yourself. Microport. They are one of the companies that
buys the source from AT&T when it becomes available. They want to be the
first company in the marketplace to offer a 5.3 for the 80386. So they
release code that isn't SVID certified. And if you don't believe it,
call them and ask. Call AT&T and ask them what companies currently have
a SVID certified 5.3 available. Don't worry, it's a short list.

Bell gives you a UNIX port when you buy their hardware because it's a
great marketing ploy. What a lot of people don't know is that all you
get is the base system without documentation. Thanks guys.

None of this is to say that any of THESE companies are shifty. As far
as I'm concerned, every successful company on the face of the earth is
shifty. Caveat emptor. Microport doesn't sell any product called
"SVID Certified SystemV/386". It's up to the buyer to find that out.
I'm positive that eventually the Microport product will be SVID certified
and that just like their SystemV/AT product, it will eventually become
a mature, well running, well liked, popular product. The problem is
that buyers simply don't beware before they buy something. You've got
to watch your butt. How do you think the owners of 1984 Corvettes feel ?
That was a new product too.

As for the MS-DOG under UNIX option, Locus Computing of Santa Monica, CA
does the DOSMerge stuff for Microport, and Interactive works in conjunction
with Phoenix Technologies to do the VP/ix stuff. I have used both. I
like VP/ix infinitely better. That is just my opinion. Take it or leave it.

And as an added note, another company that buys the 5.3 source from AT&T
is a little garage shop called Microsoft. Didn't forget about them did
you ? This is comp.unix.xenix isn't it ? MS is taking the code, and working
with Interactive Systems (they are everywhere, aren't they ?) are producing
a 5.3 that will run COFF, Xenix, and DOS executables. Pretty slick, huh ?
This product will be called Microsoft UNIX 5.3. Pretty original. Give them
marketing people a raise.

Does that clear up anything ? I hope so. If you have any more questions,
drop me e-mail. I'm going to regret making that statement. Bye.

Rich (rich@devvax.jpl.nasa.gov)

ron@vsedev.VSE.COM (Ron Flax) (09/20/87)

In article <411@devvax.JPL.NASA.GOV> rich@devvax.JPL.NASA.GOV (Richard Pettit) writes:
>"So, whose product is it that I got when I bought my Bell Tech. machine ?"
>you're asking yourself. Microport. They are one of the companies that

I beg to differ with you here.  Actually Bell's version is 386/ix from
Interactive with Bell's device drivers for streaming tape, intelligent
serial card, non-intelligent serial card, etc.  The only thing
unbundled in the Bell release is the Documenter's WorkBench 2.0, and
of course vpix (the Interactive Systems DOS executive...).

As far as documentation goes, Bell gives you the AT&T hardware
specific documentation (differences specific to the 80386 port of UNIX
5.3), the System Administrator's Guide (from AT&T), and the System
Administrators Reference Guide (equivalent to section 1 of the normal
UNIX manual pages pertaining to administration.  They also give you
the generic AT&T UNIX 5.3 documentation as published by Prentice Hall
for AT&T.  You can of course buy as many copies of this as you need at
around $100 per complete set.

--
ron@vsedev.vse.com	(Ron Flax)
inet:	vsedev!ron@cvl.umd.edu
uucp:	..!uunet!cvl.umd.edu!vsedev!ron

kens@ism780c.UUCP (Ken Sarno) (09/24/87)

>I beg to differ with you here.  Actually Bell's version is 386/ix from
>Interactive with Bell's device drivers for streaming tape, intelligent
>serial card, non-intelligent serial card, etc.  The only thing
>unbundled in the Bell release is the Documenter's WorkBench 2.0, and
>of course vpix (the Interactive Systems DOS executive...).

    This is not quite true.  386/ix is INTERACTIVE's Unix V.3
    packaged product, which has quite a few enhancements and
    additional features.  The BTI release, which is the generic
    386 V.3 system as written by ISC and certified by AT&T, is
    an *ancestor* of the 386/ix kernel.  All 386 Unix V.3 systems
    that we know of are based on some release of the code developed by
    INTERACTIVE.

    While the Bell Technologies product is not 386/ix,
    as far as we know BTI ships only the certified release of
    Unix to its customers, not Beta releases.

    The enhancements over and above the generic 386 Unix which have
    been added to 386/ix by ISC include:

	- faster file system code
	- hot-key virtual consoles
	- the VP/ix DOS-under-Unix subsystem
	- integrated DOS file system support using the V.3 File
	    System Switch facility.  This facility, which is
	    independant of VP/ix, allows you to mount a DOS
	    diskette or hard disk partition so that both Unix
	    and DOS processes can access DOS files as though
	    they were normal Unix files (within reasonable limits,
	    e.g. you can't create a 14-character name in a DOS
	    partition).
	- standard support for the MICOM TCP/IP ethernet controller
	- standard support for ESDI and RLL disks in a new disk driver
	- a host of other standard device drivers
	- Documenter's Work Bench 2.0

sl@van-bc.UUCP (Stuart Lynne) (09/26/87)

In article <7375@ism780c.UUCP> kens@ism780c.UUCP (Ken Sarno) writes:
>>I beg to differ with you here.  Actually Bell's version is 386/ix from
>>Interactive with Bell's device drivers for streaming tape, intelligent
>>serial card, non-intelligent serial card, etc.  The only thing
>>unbundled in the Bell release is the Documenter's WorkBench 2.0, and
>>of course vpix (the Interactive Systems DOS executive...).
>
>    This is not quite true.  386/ix is INTERACTIVE's Unix V.3
>    packaged product, which has quite a few enhancements and
>    additional features.  The BTI release, which is the generic
>    386 V.3 system as written by ISC and certified by AT&T, is
>    an *ancestor* of the 386/ix kernel.  All 386 Unix V.3 systems
>    that we know of are based on some release of the code developed by
>    INTERACTIVE.
>
>    While the Bell Technologies product is not 386/ix,
>    as far as we know BTI ships only the certified release of
>    Unix to its customers, not Beta releases.

All *I* want to know is who is responsible for the async and parallel port
drivers in Bell Tech's release. I wouldn't want to flame the wrong party.

I've had the 386 box for a couple of weeks. Basically after much frustration
I have given up on the parallel port driver. I must admit it *does*
function. However printing one line every 5 to 10 seconds does not impress
me *to* much.

And as bad as the lp driver is, it's at least consistent. The serial drivers
on the other hand.... Can you say *schizophrenic*...  (let alone spell it).

The serial driver supports the two standard AT serial ports. In my case one
on the Intel motherboard, and one on an IBM Serial/Parallel Adaptor Card
(true Blue, not clone). An attempt has been made to get around the normal
Unix serial driver problems or how to handle modem control by having two
minor devices for each port. One with and one without modem control. The
problem is neither works!

I have yet to find a method to tie even a simple ASCII terminal (Qume
QVT102) to the 386 reliably. The closest I've come is to simply tie DTR from
the terminal high (through a null modem to simulate DCD). This works fairly
well. At least until I had to turn the terminal on and off to clear a glitch
(QVT's sometimes lock up when you send random garbage at them, simplest way
to fix is to just turn off and on); that hung the system!

At other times I've seen the following types of problems:

	- characters sent to the second serial port appear at the rate of about
	one every 1.5 seconds
	- /etc/getty tty00 allows login, but if you didn't login the login
	after about a half a minute, the login message would appear about six
	times in quick succession after which a message would appear on the
	system console the /etc/getty was respawning to quickly
	- running cu -ltty00 displays, Connected, Lost Carrier, DisConnected in 
	quick succession
	- running cu -ltty00, exiting with ~.<cr> hangs
	- running cu -ltty00, state change on DCD (low to high), Lost Carrier,
	disconnect

The really annoying part is that it is simply not consistent from day to day
(minute to minute sometimes). If the bloody thing would at least fail
consistently, I could probably figure out a work around. 

Of course I'm probably the only person in the world having these problems
right. I mean this is AT&T certified code, *right*. 

And I would *LOVE* to be proved wrong. If anyone can describe how to use a
simple parallel printer with the lp driver, or hook a modem up to the
asynchronous port for reliable dial in operation I'd just love to be made a 
fool of. 

Anyhow even though its a bit slower than we had hoped, the 386 box is quite
nice. There's two of us on it right now doing light development work. This
should extend to three in the next week or so, and we'll be getting down to
brass tacks. I'll let everyone know how usable the box is for this type of
use. (PS. I'm using the Bell Tech ICC card for extra users, not the
standard serial ports.)

-- 
{ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532

bill@ism780c.UUCP (10/02/87)

> All *I* want to know is who is responsible for the async and parallel port
> drivers in Bell Tech's release. I wouldn't want to flame the wrong party.
> 
> I've had the 386 box for a couple of weeks. Basically after much frustration
> I have given up on the parallel port driver. I must admit it *does*
> function. However printing one line every 5 to 10 seconds does not impress
> me *to* much.
> 
> And as bad as the lp driver is, it's at least consistent. The serial drivers
> on the other hand.... Can you say *schizophrenic*...  (let alone spell it).
> 

Your parallel printer port problem is a configuration problem. Check your
config file. The reason your printer runs so slowly is that you've configured
it to run off the clock interrupt, rather than the printer port interrupt.
So you are sending a character to the printer every clock tick.

The ICC driver was developed by BTI. You may also have a configuration
problem there as well. You might check with them to find out if you have
the latest version of the driver.

The base drivers (display, keyboard, parallel, async (COM1 & COM2), CMOS,
hd, and fd) were certified by AT&T and were also extensively tested by
Intel's beta sites (more than 60 beta customers). They work if configured
properly. Note that the standard V.3/386 release does not support more
than a single device per interrupt vector. If you have 2 devices on a single
interrupt vector, one of them will be serviced when interrupts occur and
the other will likely be serviced by clock ticks.