In article <1993Mar30.140821.8097@microware.com> adam@microware.com (Adam Goldberg) writes:
quoted text
>bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>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.
>
>This is almost certainly NOT the reason why VCPI is being replaced by
>DPMI.  Using VCPI the 'client' and the 'server' become peers after the
>client goes into protected mode.  Using DPMI, the 'client' is always a
>client--to allocate a new GDT entry, for instance, there is a DPMI
>call--with VCPI, the 'client' just grabs one.

I keep forgetting that I have to write in this noisegroup as if everyone were
idiots, because otherwise I get accused of being one...

We already know, those of us who've been in this thread from its inception,
that VCPI provides no real memory protection.  It's been said several times
already, which you'd know if you'd been reading the thread.  I am temporarily
ignoring that in part because there are folks saying "so what?" because a
properly working VCPI program obviously doesn't crash the system under DOS.
Quite aside from the fact that ignoring memory protection is a Bad Thing (and
contrary to the point of using Linux; if you want a *ix-oid without memory
protection, there's always DESQview/X and the MKS Toolkit) there are other
problems with implementing VCPI in the presence of demand paging; I'm trying
to explain *that*, if you don't mind.

++Brandon
-- 
Brandon S. Allbery                                       bsa@kf8nh.wariat.org

It's not too late to turn back from the "Gates" of Hell...
Linux.  The FREE 32-bit operating system, available NOW.