This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: precompiled header support


> Heh.  Doesn't the application pretty much _own_ everything <640kB
> under DOS?  You might be able to make *very*small* pch work; just
> get the compiler to relocate itself into extended memory and it can
> use the space it vacated in low mem as an absolute
> allocation.......!  [*]

No, this won't work.  You don't understand the division between DPMI
and the application.  It's kinda like DPMI is the kernel (think mach,
not linux) and the application must rely on DPMI to allocate memory.
In DPMI 0.9, the application has NO way of telling DPMI where it wants
memory.  It either allocates a new chunk (which shows up anywhere) or
grows an existing chunk.  Since we're running in a true 32-bit virtual
environment, even knowing we can grab parts of the 640k low memory
doesn't help - since we can't predict our own base linear address, we
can't predict where the 640k memory will be mapped to.

And BTW we really went through all these discussions when they were
porting Quake to DJGPP and needed the SVGA memory window to stay put.
If Sandmann and Carmack couldn't do it, neither can we.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]