From: Charles Sandmann <sandmann AT praline DOT no DOT NeoSoft DOT com>
Subject: Re: dpmi DS:VRAM hack
To: elio AT pvax DOT ICO DOT Olivetti DOT Com (Elio Tondo)
Date: Mon, 29 May 1995 19:55:46 -0500 (CDT)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

> Any comments about the "reliability" I noticed when only calling malloc() and
> not system()? On May 2 you wrote that a custom malloc was needed; can you
> give us all some more details about the conditions that can trigger the
> modification of the segment linear base address, and any way to avoid that?

Some DPMI providers do not change the linear address unless they absolutely
have to (like Win 3.1).  In this case, if there is not an external event 
which forces the DPMI provider to change the address, you are OK.  There 
are some external events which can force the linear address to change on a
resize - running with a debugger, nested DPMI programs (like GCC calling CC1)
and in some cases multitasking.  

Remember though, there are environments which do not support the -1 limit or
will change the base linear address each resize.  If you know for sure your
app will never see any of those environments (internal use only) you can use
this hack fairly freely, but for anything to be distributed its a bad idea.

> Yes, and this is the problem. I know that DPMI 1.0 has its own mmap()-like
> functionality; I was only trying to understand if some trick can be used, given
> that the page tables are global (is this right?) and maybe there is some way
> to circumvent the DPMI protections and access them directly.

On many hosts the tables are not ring 3 writable (I am not sure about Win),
but if they are you could try tinkering with them.  It is probably DPMI 
host dependent on what happens when you mess with the page tables.  For 
example, on CWSDPMI messing with them at all will probably be a disaster.