Date: Sat, 27 May 1995 15:20:35 +1000 (EST)
From: "Junaid A. Walker" <junaid AT barney DOT eng DOT monash DOT edu DOT AU>
Subject: Re: Compiling gdb, dpmi DS:VRAM hack.
To: Elio Tondo <elio AT pvax DOT ICO DOT Olivetti DOT Com>
Cc: rbabcock AT cfa DOT harvard DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu,
        sandmann AT praline DOT no DOT NeoSoft DOT com



On Thu, 25 May 1995, Elio Tondo wrote:

> > > 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.

	Agreed, the segment overide stuff is messy..

> 
> 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.

	4GB i think. Even works on Pentiums (64bit hah!). Please tell me
which dpmi providers fail. I'm beginning to think that the -1 'huge segment
limit' is a feature, required by some system utilities...like ps, and 
inter-process debugging/messages etc.

> |   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).

	OK...system() is probably the one case where DS is going to
move, as we execute another program in the current processes address
space. But, the base of DS is restored after system() to allow the
calling process to run with its own set of variables. We can rely on DS
being correct (except when system() and a parent's interrupt handler gets
called) whenever the process is in control proper. As mentioned, the limit
on DS changes as malloc, free and other memory management fns get called.


> 
> 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.

	Dont think there is any access to the page tables in dpmi.
We can however roll our own segment descriptors (even DOS/4G supports
this). So thats another, more 'portable' way of getting a fat DS. 
Sugestions on doing this?

	Junaid

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