delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/12/16/03:52:53

Date: Wed, 16 Dec 1998 10:52:40 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Peter Remmers <pitti AT tfh-berlin DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: VDS
In-Reply-To: <73smp7$ena$1@idy05.tfh-berlin.de>
Message-ID: <Pine.SUN.3.91.981216104802.22373W-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

On Mon, 30 Nov 1998, Peter Remmers wrote:

> Who is managing what memory?

I don't understand the question.

> Who is the VDS provider? The memory manager or the DPMI host?

The memory manager, usually.

> The VDS Get Version function tells me the provider is QEMM
> but memory is managed by the DPMI host?

Memory is also managed by QEMM.  QDPMI just services the DPMI 
memory-allocation functions by requesting memory from QEMM, and also adds 
the VM layer.

> is CWSDPMI (or go32?) allocating all the memory at startup
> for local management?

CWSDPMI doesn't do this usually.  The only cases where it allocates all 
the extended memory is when there is no memory manager loaded (no VCPI 
services available).

> >What people have had luck with is using the XMS functions to allocate
> >an XMS buffer and lock it into memory - which will be 1:1 mapped.
> Lock it with what? The DPMI lock-data function? or the
> VDS Lock Region function?

The DPMI call, I presume.

> The 1:1 mapping - is this the case with all XMS allocated memory?

You will have to check, but I think all of it.

> ...and use the _far* functions, right?

Yes.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019