Mail Archives: djgpp/1995/05/26/13:54:42
Okay, here come some of the technical details on the VRAM hack problems.
I have known about this hack for about 2 years (and have a V2 test version
which allows this). But there are problems with it. The best setup I
have come up with is a volatile global variable __djgpp_convmem_offset
which must be re-added each time, ie *(0xa0000+__djgpp_convmem_offset)
In V1.x, look in go32/paging.c for what happens when sbrk() gets called.
You can see that the DS, CS, and SS selector bases and limits can be
changed depending on what the DPMI provider returns. Get a copy of the
DPMI specification and read on function 0x503 - in the notes you will see
that the linear address of the memory block may be changed. Some
providers *ALWAYS* change the address (OS/2 2.0 for example); others only
change it if a different memory block has been allocated; CWSDPMI never
changes it.
In the very simple example provided, sbrk() does not get called. In some
of the modified examples which do call sbrk() - they have not had the
base memory address changed forced on them by external events.
I guarantee I can write a subroutine which will simulate external events
(multitasking, debugger execution, etc) that will break this algorithm
unless the modified DS base is reloaded and the relative offset to VRAM
is recomputed with the current V1.x release.
If you are aware of this limitation, and don't need your code to run under
all DPMI providers, it may be the fix to your problems.
The problems can be changed by recoding malloc() to allocate
new blocks instead of resizing - but then you are forced to use the lim=-1
hack and the sbrk() routine must be removed from the library. My plans
were to provide a set of routines for this sometime in the future which
were smart enough to know if the DPMI provider allowed the lim=-1
configuration, and do the right thing.
- Raw text -