From: Elio Tondo 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.