Mail Archives: djgpp/1995/05/30/23:19:08
On Tue, 30 May 1995, Charles Sandmann wrote:
> > and fiddle conventional memory to our heart's content with the full
> > knowledge that the OS will not be able to change the fat-segment's
> > base address. However if (big if, seems if we wait after a system() and
> > re-hack a huge DS then everything is OK) the OS changes the base of DS
> > behind our back without us anticipating (ie it relocates the data segment
>
> DPMI never changes the segment base or limits. DPMI may change the
> location in virtual memory of your code and data on a resize request.
> This movement is accomplished by changing the page tables on all providers
> I have see so it is very fast. Some providers change the address each
> time on a resize; others only when needed. It would be required to
> change the base if the linear memory space becomes fragmented.
> GO32 notices if the base of the memory block changes and it modifies the
> CS,DS and SS to match.
>
> > Maybe someone
> > can tell me when an OS will relocate the data segment base in linear
> > address space while the process is running and the process is not
> > making system calls?
>
> Never.
Thank heavens! But just perusing the dpmi v1.0 spec last night
revealed that each dpmi client has their own private LDT and IDT. But seems
that there is no need for 'the-hack' as v1.0 supports memory mapping.
Will cwsdpmi provide v1.0 services in the future? Its intreguing to see
dpmi v1.0 as a bigger and better VCPI...
> > base will *NEVER* change (current beta, algorithm may change in future)
> so the VRAM hack would always work there. BTW, one of the reasons CWSDPMI
> handles memory in this way is so this hack would work all the time!
But there is no reason to need the hack, because in raw mode,
cwsdpmi can do its own memory mapping aka the 0xE0000000 window as
go32 does. BTW no one wants the 0xD0000000 what with its high banking
overhead (any good blit algorithm knows when its going to bank, and
vesa gives us the banking code in PM), unaligned bugs, and need for
drivers built into the extender.
>
> 0xE00xxxxx yes, 0xD00xxxxx no. The later requires bank switching.
> I have plans that (eventually) using this accesss will be as simple as
> setting a compile time flag and checking to see if it is supported. In
> V2 the modifications are limited to a single file (crt0.S). This might
> be used in a widely distributed app to gain some speed when the hack is
> available, or fall back to the farptr functions if it is not available.
>
Good idea. But dont fall into the trap of providing a vectored
movedata() fn like in go32 now. The whole point of the hack is that we
can rapidly access sparse (or small) areas of conventional memory
without function call overhead, and indeed, without segment overides
(irelevant if writing to slow memory). Instead provide a global variable
that indicates what enviornment we are running under, wheather the hack
works or not, and possibly a fn to activate the hack when needed.
crt0.s is definately the place to do it (we can easily recompile to
handle new dpmi enviornments to implement the hack). Again once a
0xE0000000 segment in cwsdpmi is created, the hack is unnecessary, so we
dont need to do evil things in the extender itself.
Junaid.
- Raw text -