From:	Elio Tondo <elio AT pvax DOT ICO DOT Olivetti DOT Com>
Subject:	Re: Compiling gdb, dpmi DS:VRAM hack.
To:	junaid AT barney DOT eng DOT monash DOT edu DOT au (Junaid A. Walker)
Date:	Mon, 29 May 1995 14:22:52 +0200 (MET DST)
Cc:	elio AT pvax DOT ICO DOT Olivetti DOT Com (Elio Tondo), djgpp AT sun DOT soe DOT clarkson DOT edu

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

The limit is not the problem, since we need to set it to 4GB to use the
near pointer trick; the problem is the linear base address, which surely
changes (sometimes) *AFTER* returning from system(); it is not clear if
(and when, and when not) it changes also after the sbrk() call done by malloc()
when asking for more memory to the system.

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

Can you add some details?

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

- Raw text -