Date: Fri, 4 Jun 93 13:29:26 EDT
From: engdahl AT brutus DOT aa DOT ab DOT com (Jon Engdahl)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: DPMI support

> From: DJ Delorie <dj AT ctron DOT com>

> Due to the linear nature of go32's environment, it was necessary to
> make the 0-1M memory region appear somewhere in the program's address
> space so that you could do things like write to the screen or access
> BIOS data.  This memory is linearly mapped beginning at virtual
> address 0xe0000000.  For example, if you read 0xe00b8000, you would be
> reading the text screen memory (B800:0000).  Under DPMI 0.9, go32 is
> not able to perform this virtual mapping, so programs that relied on
> the memory appearing at that address will no longer work.  Instead,
> there are some new functions in pc.h that perform the function of
> reading and writing to physical memory for you.
> 

This sounds dangerous (thinking of wild programs stabbing low mem).
Wouldn't it be better to unmap this region, and provide functions to
map it only if the program asked for it via an system call?  Maybe the
safety intrinisic in hiding a 1 meg space in 4 gig is adequate. An
incrementing pointer won't run into e0000000, because it will fault
first. Let's see, a randomly generated pointer has a 1 in 4096 chance
of hitting the mapped low memory.

Jonathan Engdahl, Sr. Project Engineer | engdahl AT aa DOT ab DOT com N8XVY 313-998-2450
Allen-Bradley Co.                      | A Rockwell International Company
555 Briarwood Circle,                  | Industrial Communication Networks
Ann Arbor, Michigan, 48108, USA        | system design, software, ASICs