From:	Elio Tondo <elio AT pvax DOT ICO DOT Olivetti DOT Com>
Subject:	Re: Compiling gdb, dpmi DS:VRAM hack.
To:	rbabcock AT cfa DOT harvard DOT edu
Date:	Thu, 25 May 1995 11:53:18 +0200 (MET DST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu, sandmann AT praline DOT no DOT NeoSoft DOT com

> > Well here it is; how to access video ram at 0xa0000 without using
> > a segment overide (ie using the current process's DS). Works well
> > under MS Windows 3.1 in a full screen DOS box.
> >    This program works by removing the segment limit on DS and
> > using 32-bit wrap around in the linear address space to access
> > memory at linear address 0xa0000.
> 
> Nice trick!  Your test program seems to also work under OS/2.

Maybe this issue needs some further analysis; it is not the first time that
it is discussed on this list, but there are still open items. Obviously
the interest is high; people coming from Unix know that they can use mmap()
to do this kind of things when needed, and the non-DPMI djgpp 1.x solution
was very comfortable. The farptr stuff works well, but the ability to write
and read video memory with plain C pointers is sometimes essential when
porting existing code, and much more comfortable in any case.

But in a message on May 2, Charles Sandmann wrote:

| There is a way on *SOME* DPMI providers to set up DS so that you could use
| a direct pointer to the video memory.  To do this you would need:
|   1) To sacrifice the ability to run under some DPMI environments; you
|      must depend on 2GB segment limits and memory wrap.  Not all allow this.
|   2) To replace the supplied malloc() with a custom version (I can provide
|      the details)
|   3) Never use sbrk in any code
|   4) Compute the pointer offset (it will *NOT* be a constant).
| 
| It is possible to detect at runtime if the DPMI provider will support this;
| but you would need the farptr functions as a fallback method if not supported.
| 
| The above code is on my LONG list of things to do, but it is not near the top.

I tried the program posted yesterday and it seems to work with no problems
both under CWSDPMI and in a Windows 3.11 DOS box. To stress further the thing,
I added a loop doing big malloc() calls (1MB each) and reading again the DS
linear base address at each iteration. It apparently did not move even when
swapping started.

A second stress test has been done by adding a system() call at each
iteration; this time the DS linear base address changed after a couple of
iterations, after disk swapping started (by the way, I was somewhat surprised
to see that when running in a Windows DOS box a djgpp swap file is still
created (but only when doing malloc() and system() calls one after the other);
I was thinking that the DPMI provider virtual memory was used).

Maybe Charles Sandmann can enlighten us about all the hidden constraints
related to using this tricky method of getting a near pointer to conventional
memory?

As a related issue, does anyone know if there are ways to implement a "true"
mmap() functionality when using a DPMI 0.9 host? Some way to manipulate the
page tables to get the desired mapping, or similar methods.

   Elio
 _____________________________________________________________________________
|  __           ___                | Olivetti - Viale Gramsci 12 - Pisa, Italy
| |_  | .  _     |  _   _   _|  _  | Tel:  +39-50-516554   Fax:  +39-50-502664
| |__ | | (_)    | (_) | | (_| (_) | elio AT olivetti DOT com | Standard disclaimers.

- Raw text -