Mail Archives: djgpp/1995/05/30/11:45:28
> 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
> in linear memory - why would it do this, surely a very time consuming
> operation, why not just use the 386's paging mechanism to remap memory?)
> then we lose addressability of the processes data variables, but we
> can still access all of physical memory. Not much better than
> 'mov _go32_conv_mem_selector, %ds' .
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.
You can make any calls except anything which indirectly might call sbrk() -
malloc for example, or any of the lib routines that might call malloc.
If you don't call sbrk, your base address won't change. Under some
providers (Win 3.1) the base usually won't change even on an
sbrk - an additional external event would be needed. Under CWSDPMI the
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!
> Mr Sandmann indicated a debugger or swapping
> might have this affect. Its probably safe to assume there will be
> no intefering debugger while we run our fat-DS program (or we can
> modify the debugger not to relocate DS). But swapping?? IMHO i dont
> think swapping relocates any data, only marks a page as dirty, and
> swaps it in when needed.
The debugger does not change anything, but it does allocate memory which
fragments the linear address space, which under Win 3.1 would force the
base to change on a resize (sbrk call).
> Anyway the hack is more or less useful, especially since it
> works well under MS Windows and cwsdpmi/go32/Warp, giving the process
> the equivalent of the much loved 0xD0000000 and 0xE0000000 address areas.
0xE00xxxxx yes, 0xD00xxxxx no. The later requires bank switching.
The hack is very useful for specific environments, but doesn't work well
in others. It's very similar to the fact 0xE00xxxxx type access does not
work under DPMI now. So you can write code that runs many places but
not others. Farptr will always work everywhere.
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.
- Raw text -