From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	Re: DOS 1Mb area
To:	javier AT auto DOT isa DOT cie DOT uva DOT es (Javier Achirica)
Date:	Fri, 10 Dec 1993 22:17:15 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

> 	Also, I noticed that when the extender is running under DPMI it is not
> possible to map the 1Mb DOS area at 0xE0000000 in the current selector, and it
> is mapped a 0 in a new selector. Wouldn't be better to also map that area in
> the 0 position in a new selector when using a non-DPMI mode? This way accessing
> that memory would only be a matter of changing selectors, so routines wouldn't
> need to have a temporary area and call dosmemget and dosmemput to do the
> transfer, saving all the overhead involved.
> 
> 	This approach, if possible, could also be used for the 0xD0000000 video
> window, so there still can be a planar video window in all cases.

The problem is you can't specify a selector in a pointer from C (unless someone
wants to teach GCC about "FAR" :-) so you are "stuck" with either GAS or
the subroutines.  GRX 1.04's (2.0's?) rewrite was to use these selectors to
make DPMI graphics possible.

The 0xE0000000 still exists as a compatibility holdover and a convenience.
There is a selector with zero offset also for non-DPMI mode and it is
used usually.  But code may be run with a pre-1.10 extender (or an old
EMU387) that trashes needed registers.  It was easier to try and fix up
as many cases as possible and provide compatibility than explain why all
the combinations of GO32 and binaries might or might not run.

DJ's plan for 2.0 will allow us to remove these bits of history from the
code, but until then multiple 1-MB area support mechanisms will stay in
place.  Unfortunately, programming for DPMI 0.9 isn't as easy as the 
original DJGPP environment, and there's no way around it.

- Raw text -