From: Phil Galbiati <Philip DOT S DOT Galbiati AT Tek DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: [Q] how to get offset of DOS conv. memory
Date: Tue, 29 Oct 1996 15:44:24 -0800
Organization: Tektronix
Lines: 52
Message-ID: <327696D8.50F9@Tek.com>
NNTP-Posting-Host: philipga.cse.tek.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Greetings

If I allocate conventional memory using __dpmi_allocate_dos_memory()
and then I want to write to it using dosmemput(), how do I determine
what the offset of the target is?

I looked at the info pages for __dpmi_allocate_dos_memory() and
dosmemput(), and as far as I can tell, it doesn't say.  What it DOES
say is confusing (and probably should be corrected):

   [this was copied from the info page for dosmemput()]
   offset = segment * 16 + offset;

I assume that "offset" is referring to two different animals, the LH
"offset" being the third param passed to dosmemput(), and the RH
"offset" being the offset that I'm asking about, namely the offset
in segment::offset == physical address of the conventional memory
allocated by __dpmi_allocate_dos_memory().

Am I correct in guessing that __dpmi_allocate_dos_memory() always
allocates blocks aligned on 16-byte boundaries, so the offset is
always zero?  If so, would the proper way to use these functions be
something like this [error conditions neglected for brevity]:

   .
   .
   .
   /* suppose I need 1024 bytes of real memory */
   n_pars = (1024 + 15) >> 4;
   seg    = __dpmi_allocate_dos_memory (n_pars, &sel);
   r_addr = seg * 16;

   /* copy from v-space to r-space */
   dosmemput (vbuff, 1024, r_addr);
   .
   .
   /* do whatever real mode stuff you need */
   .
   .
   /* copy results from r-space to v-space and free conv. memory */
   dosmemget (r_addr, 1024, vbuff);
   __dpmi_free_dos_memory (sel);
   .
   .
   .

Thanx
--Phil Galbiati
=================================================
     Any opinions expressed here reflect the
     ignorance of the author, NOT Tektronix.
=================================================