Date:	Thu, 23 Sep 1999 11:17:48 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	johnny_chan AT phoenix DOT com
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP virtual memory
In-Reply-To:	<vines.Vm1E+snKurB@ptlsjlab1.phoenix.com>
Message-ID:	<Pine.SUN.3.91.990923111725.10652V-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 22 Sep 1999 johnny_chan AT phoenix DOT com wrote:

> Building my program with DJGPP 2.02, I can access all the extended
> memory on the target machine running ms-dos 6.22. This is fine, except
> that some of that memory was already used by a ram disk. I am using
> himem.sys and ramdrive.sys, which are part of dos 6.22. So my program is
> overwriting the memory used for the ram drive.
> 
> Is there any way for my program built with DJGPP to be compatible with
> HIMEM.SYS?

DJGPP *is* compatible with HIMEM.SYS.  How else do you think a DJGPP
program could access memory when HIMEM is installed?  It does so by
talking to HIMEM, of course.

There's something wrong with your setup or with your program.  First,
are you sure that memory occupied by the RAM disk is overwritten by
the DJGPP program?  Please post the details which indicate that the
DJGPP program is the culprit, and please also tell more about how
exactly do you see that the RAM drive memory is overwritten.

Second, how does your program ``access all the extended memory''?  Do
you, by any chance, use the XMS interface from your application's
code?  If so, your program is the one that should take care not to
overwrite occupied areas.  But if your program only accesses the
``normal'' C memory, either via malloc or static (i.e. compile-time)
allocation, then you should be safe.

As long as you use DJGPP library functions like malloc or sbrk to
allocate memory, you are accessing that memory via the DPMI interface.
That interface is implemented in a DPMI server, which is a separate
piece of software.  It is the DPMI server that needs to be compatible
with HIMEM (and other established standards of accessing extended
memory, like VCPI).  DJGPP comes with CWSDPMI as its DPMI server, and
CWSDPMI *is* compatible with HIMEM.  Do you use CWSDPMI, or do you
have some other DPMI server installed?

Finally, if none of the above helps to find the cause for the problem,
please type "go32-v2" from the DOS prompt on the target machine and
post here what does it print.

- Raw text -