From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: DPMI under dosemu (was Re: DOSEMU Success list!!) Date: Tue, 30 Mar 1993 00:35:59 GMT
In article <733195401.F00062@remote.halcyon.com> Yousuf.Khan@p6.f215.n163.z1.fidonet.org (Yousuf Khan) writes:
>From the VCPI host, each subsequent VCPI client must ask permission to
>allocate memory from the host through VCPI calls. Once the permission is
>granted and the client goes into protected mode, then the client and the
>host are peers. If the client wants to allocate more memory, it cannot
>simply take it, it must make calls to the VCPI host again. If any
>subsequent VCPI clients want in, then they too must ask permission from
>the client.
Among other things, the host can't manipulate the client's memory once it has
been allocated. Which means that memory allocated by VCPI *cannot be paged*
except by the VCPI client that "owns" it; in particular, once it's allocated,
Linux can't page it unless it's very, very careful not to let the client get
another timeslice until *all* of it has been mapped back *at the same hardware
addresses it had originally*.
This is enough of a problem that not even Quarterdeck, co-creator (with Phar
Lap) of VCPI, will attempt to track VCPI pages in that manner in their
flagship product DESQview/386... and DESQview/X won't allow any swapping at
all, which "solves" the problem of DV386 crashing if you don't disable
swapping of a VCPI client but means your physical memory is *it* as far as RAM
goes unless the VCPI clients are willing to demand-page their own allocated
memory.
Suffice it to say that VCPI is a pain in the *ss to administer in a
demand-paging system. Which is why Windows and OS/2 don't support VCPI and
why (Quarterdeck and Phar Lap aside) it's being replaced by DPMI.
++Brandon
-- Brandon S. Allbery bsa@kf8nh.wariat.orgIt's not too late to turn back from the "Gates" of Hell... Linux. The FREE 32-bit operating system, available NOW.