cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/21/13:09:06

Date: Thu, 21 Oct 1999 13:57:03 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: kriiid AT my-deja DOT com
cc: djgpp AT delorie DOT com
Subject: Re: allocating memory using DPMI
In-Reply-To: <7ukq18$cde$1@nnrp1.deja.com>
Message-ID: <Pine.SUN.3.91.991021135639.2684F-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Wed, 20 Oct 1999 kriiid AT my-deja DOT com wrote:

> It look pretty inefficient (if it is done for every malloc).

Who said it's done for every malloc?  The function that gets memory
from the DPMI host allocates it in chunks of 64KB, unless the program
asks for larger chunks.

Of course, if you'd write a program that does nothing except allocate
64K+1 byte in a loop, that would be somewhat inefficient, but that's a
toy program, not a real-world application.

> mov [precoo],ebx
> 
> And then I just use [precoo]...

This is your problem: you have allocated memory, but didn't make sure
your DS segment limit includes that memory.  In most cases, you will
need to enlarge the limit, otherwise you get a GPF.

> Changing base is not really a good idea, because what to do with data
> allocated within DS using db or something.

Sometimes, you don't have a choice, for example, if you resize a block
and the new block is at a different address.  DPMI spec doesn't have
any provision for you to control where exactly in the linear address
space does the DPMI host put the memory blocks you request.

- Raw text -


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