www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/02/02:08:18

Date: Thu, 2 Jan 1997 08:49:59 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Aaron m Clemmer <aclemmer AT juno DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Allocating and using memory with the dpmi functions
In-Reply-To: <19970101.035138.4855.1.aclemmer@juno.com>
Message-ID: <Pine.SUN.3.91.970102083550.17516B-100000@is>
MIME-Version: 1.0

On Wed, 1 Jan 1997, Aaron m Clemmer wrote:

> 	I'm trying to use virtual screens in my graphics lib.  As they
> vary in size from 64k to several megabytes, I decided that using the dpmi
> functions was the best way to go.

IMHO, this is a bad decision.  What's wrong with using `malloc' and 
Co.?  I think that going for the DPMI functions will make things 
considerably more complex for you (see below), without any real reason.  
I submit that you will be much better off resolving any problems you 
might have in using `malloc' (possibly with advice from this news group) 
than trying to use the raw DPMI functions.

> Anyways, the buffer appears to
> allocate properly, but when I try to write to it, I get a GPF.

Of course, it will GPF!  You have a whole slew of bookkeeping to do 
before you can reference memory thus allocated in your program.  For 
starters, it's outside your program's address space (e.g., beyond the DS 
selector limit).  Take a look at the code of `brk' and `sbrk' functions 
(on crt0.s in the library sources, djlsr201.zip) and see how many things 
they need to do around the bare-bones call to the DPMI function.  Believe 
me, you DON'T want to do that on your own without a *very* good reason!

- Raw text -


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