bcs212@vader.UUCP (Vince Skahan) (04/05/88)
Does microport make a version that will run on a non-286/386
IBM compatible. My SX is 1.4 times as fast as an XT - will I grow
old waiting for it if I try to run some flavor of unix???
--
Vince Skahan Boeing Computer Services - Phila.
(215) 591-4116 INTERNET: bcs212%psev@boeing.com
UUCP: {...rutgers!bpa | uw-beaver!uw-june!bcsaic}!vader!bcs212 vandys@hpindda.HP.COM (Andy Valencia) (04/08/88)
/ hpindda:comp.unix.microport / bcs212@vader.UUCP (Vince Skahan) >Does microport make a version that will run on a non-286/386 >IBM compatible. My SX is 1.4 times as fast as an XT - will I grow >old waiting for it if I try to run some flavor of unix??? SCO sells XENIX for the 8086/8088. Yes, it works. Yes, you will grow old waiting for it. You'll do much better to sell it for a couple of hundred dollars, then go get a '286 or '386 clone. I recommend '286 unless you NEED the 32 bit address space--those '386s can be *flakey*. Andy Valencia
hedrick@athos.rutgers.edu (Charles Hedrick) (04/08/88)
I think the original IBM Unix, probably a Xenix version, ran on XT's. (I certainly recall seeing it run on a machine here long before there were 286's, so it had to have.) Mark Williams software has a V7 derivative that they call Coherent. I don't know much about it, but I do know that it runs on the older processors (indeed I think it won't run on a 286). The reason Uport won't run on an XT is that it uses protected mode. This exists only on the 286 and 386. It's impossible to make a real multiprocess OS without using that feature, so Unix is impossible on an XT. So, you say, how about the two things I just listed? They use sort of smoke and mirrors. As far as I know, they work, but any process can walk all over any other's memory if they do the wrong thing with the pointer registers.. In my opinion, this means that the processes are not in any normal sense separate processes. Since Unix by definition has multiple processes, this means that they aren't Unix. But they may look, act, and smell enough like Unix to be useful.
dyer@spdcc.COM (Steve Dyer) (04/08/88)
In article <Apr.7.16.12.35.1988.7065@athos.rutgers.edu>, hedrick@athos.rutgers.edu (Charles Hedrick) writes:
] I think the original IBM Unix, probably a Xenix version, ran on XT's.
] (I certainly recall seeing it run on a machine here long before there
] were 286's, so it had to have.) Mark Williams software has a V7
] derivative that they call Coherent. I don't know much about it, but I
] do know that it runs on the older processors (indeed I think it won't
] run on a 286). The reason Uport won't run on an XT is that it uses
] protected mode. This exists only on the 286 and 386. It's impossible
] to make a real multiprocess OS without using that feature, so Unix is
] impossible on an XT. So, you say, how about the two things I just
] listed? They use sort of smoke and mirrors. As far as I know, they
] work, but any process can walk all over any other's memory if they do
] the wrong thing with the pointer registers.. In my opinion, this
] means that the processes are not in any normal sense separate
] processes. Since Unix by definition has multiple processes, this
] means that they aren't Unix. But they may look, act, and smell enough
] like Unix to be useful.
Rather Jesuitical logic there. Sheesh, pretty soon we'll be hearing
"Since UNIX by definition has virtual memory, this means that X isn't
UNIX..." These comments were written with rather short hindsight from
someone who should know better.
The earliest versions of UNIX ran on unprotected PDP-11s, and mini-UNIX,
a version of V6 which ran on PDP-11/04s and similar unprotected 64K byte
machines could be licensed from AT&T in the 70's. There was an internal
V7 port to the 8086 within Bell Labs in the late 70's. IBM's PC/ix (an
Interactive Systems port to the 8088) was a creditable port of UNIX System
III based on UNIX System III licensed code. SCO used to sell a version of
XENIX, also UNIX licensed code, which ran on the 8088. In the case of PC/ix,
one was reasonably "protected" from processes manipulating arbitrary segment
registers because the compiler offered one and only one memory model:
split-I&D, 64K instructions and 64K data, just like the PDP-11 44,45 and 70.
No medium model far calls, or "large" or "huge" models. To the programmer,
the segment registers didn't exist and weren't visible. The UNIX kernel used
the segment registers to isolate the processes' address spaces from each other.
This is about as good as you can do on such a machine, and it worked fine.
It is better to have true memory protection and separate user/supervisor
spaces, but their presence or absence is really quite orthogonal to what
makes something "UNIX" or not.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyerdyer@spdcc.COM (Steve Dyer) (04/08/88)
This is totally gratuitous, for which I apologize in advance...
Since Unix by definition shouldn't crash when performing a 9600 baud
UUCP transfer, this means that [they] aren't Unix. But they may look,
act, and smell enough like Unix to be useful.
Since Unix by definition shouldn't give hard disk errors when accessing
two perfectly OK disks attached to the same controller, this means that
[they] aren't Unix. But they may look, act, and smell enough like Unix
to be useful.
Of course, I'm just pointing out that the logic is faulty. I don't agree
with the sentiments.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,husc6,linus,ima,bbn,m2c}!spdcc!dyer