Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: 386BSD - what a pain to install!
Message-ID: <1992Oct2.155958.29182@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
References: <id.X7NT.904@ferranti.com> <1992Sep30.035327.4082@fcom.cc.utah.edu> <id.S2QT.C03@ferranti.com>
Date: Fri, 2 Oct 92 15:59:58 GMT
Lines: 63
In article <id.S2QT.C03@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep30.035327.4082@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> >We've been running Xenix-286 for years with multiple data and multiple code
>> >segments. We're talking applications with megabytes of both.
>
>> Sorry. Peter is right for SCO Xenix, of course... but then again, that
>> won't compile for all 286 Xenix's... the resultant code runs only on SCO.
>
>Sorry yourself.
>
>I'm talking about Microsoft Xenix, which we've been doing this on since
>1984 or 1985. It was possible for Microsoft Xenix in 1983, according to
>the copyrights on the earliest set of floppies I can find. The final (so
>far as I know) release was in 1987, with patches continuing after that.
>
>This release left Microsoft for Intel long before SCO took over.
I wasn't thinking of Microsoft, Intel (modified Microsoft), or SCO (also
modified Microsoft) Xenix, all of which use a Microsoft derived compiler.
The Specifc instance I was thinking of was Altos, which has it's own compiler,
and in particular, an Altos 886 of long acquaintance. Rereading this, it
looked like I said "well, of *course* if you use SCO..."; that was only
partially the intent, in that the Altos developement kit can produce code
that will run on other Xenix flavors and Cubix boxes, and the SCO kit,
while it supports large model, makes binaries that are picky about where
they will run, especially if done in "large model".
I also have had the genuine Microsoft article running on a genuine IBM AT;
it does support large model as well (had to dig out the documentation for
this one!), but like SCO has the handicap of the Microsoft compiler (which
introduced the concept of a "far pointer").
"Large model" (which differes from "Medium model" by frequent segment register
reloads) has always seemed like a kludge to me, mostly because of the 286
being set up for 64K segments in the first place.
The Altos compiler does the same thing that MS-Windows does, which is limit
you to 64K of data, with the ability to use an "escape hatch" to get more
memory (Xenix 3.1b and above -- 3.1a had it, but "free()" failed) at the
expense of locking it down so no one else could use it.
This leads me back to the original argument that 286 memory management is bogus
compared to 386 memory management (and foreign memory management in general);
the idea that the architecture sticks through enough that you can have two
64K arrays, but not one 128K array has always irked me no end.
Of course, if one is a Microsoft employee, they can always run Xenix on a
Sun 3/60 and avoid the issue entirely. This isn't true for the majority of
us (although we may all be AT&T employess soon).
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------