Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!apple!brutus.cs.uiuc.edu!wuarchive!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.i386
Subject: Re: Microsoft Word & (SCO) Unix 3.2
Message-ID: <5890@ficc.uu.net>
Date: 25 Aug 89 21:02:54 GMT
References: <LARRY.89Aug17095648@focsys.UUCP> <7227@megatest.UUCP> <32271@ism780c.isc.com>
Organization: Xenix Support, FICC
Lines: 56

In article <32271@ism780c.isc.com>, darryl@ism780c.isc.com (Darryl Richman)
seems surprised by the fact that we're running programs large enough to cause
problems on a 386 even when they're using a hundred times the memory they were
using on the '286.

> Obviously there is a limit to the process size, and there is a
> jump in process overhead every 4MB for the extra page table directory,
> but these seem like they should be a long way off for a 286 environment
> program.

Not at all. We're talking about 286 programs that have to spill to disk
on Xenix-286 even with a MEMPOOL (rough equivalent to ulimit) set to 3
megabytes. These are not small programs.

[stuff about tuning the system deleted... we're dealing with big 286
 programs suddenly using maybe 100 times as much memory as before when
 loaded on the 386 ]

Regarding intel's UDI library:
> This is a surprising way to handle memory on a 286 considering that it
> is so expensive to load a segment register, the limited (4k-1) number
> of segments allowed to a user process, and the added overhead in
> process switching incurred by large LDTs.  We have not encountered a
> problem like this one in the large number of commercial XENIX products
> we, Microsoft, and SCO tested.  Have you discussed this problem with
> INTEL?

These programs were originally intended to run in RMX-286, which shares
the same LDT among all processes so does not have this problem. The Intel
UDI is very much dependent on this behaviour, and tends to use a segment
where a more conventional system uses an offset. It's not possible to
change this behaviour of the programs. Not only is it designed into the
PL/M runtime library but many of them are no longer supported. The only
realistic solution for us would be to change the behaviour of x286emul.

If this can't be done, we'll have to stick to our old systems.

> In designing and implementing the environment emulator, our goals were
> to provide backward compatibility and the same or improved performance
> in existing products compared to running native on a 286.

I'm not surprised that you haven't run into this problem, since there are
very few folks still running the system-3 based Xenix and intel development
tools. I can't argue about the size of the market people like us represent,
but to move out of the 286 we need an upgrade path. We'll be happy to move
into the 80386 world, but we need a way to support our existing 80286
software on whatever hardware/operating system combination we use. You
haven't given us one.

It's frustrating to be told we have to stick to the 286 for the very reason
that the 286 is obsolete... :-<.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'" -- Tom Neff     'U`
"I didn't know that ksh had a built-in APL interpreter!" -- Steve J. Friedl