The function dosmemget() crashes when told to copy data from the HMA into the program address space. Consider the example below:
#include <stdio.h>
#include <stdlib.h>
#include <go32.h>
#include <dpmi.h>
int main(void)
{
void * buffer;
buffer = malloc(65520);
if (buffer != NULL)
{
/* I canīt remember the exact order of parameters, but it should copy 65520 bytes from HMA into buffer allocated with malloc */
dosmemget(0x100000, 65520, buffer); /* please check start address, I am calculating it as I write this */
puts("Copying was successful!");
free(buffer);
}
else puts("malloc failed.");
return 0;
}
This short program is supposed to allocate 65520 bytes via malloc and copy the contents of the HMA into it. This program runs successfully under a Windows DOS box, but crashes when run under plain DOS with EMM386 and CWSDPMI. The stack dump points at _dj_movedata as the last function executed, and the DS and ES registers show selectors into the low 1MB area and the program data area.
It seems that this problem is caused by EMM386 not honoring a set selector limit message that is issued by CWSDPMI (probably when building _dos_ds). This problem, however, remains when I disable VCPI services with the NOVCPI parameter. I discovered this as I wrote a program that copied video ROM fonts into my data areas, as part of my graphics library. DISPLAY.SYS seems to locate replacement fonts into the HMA, so the code ends up trying to copy data from the HMA, with the described results. Apart from uninstalling either EMM386.EXE or DISPLAY.SYS, could anybody suggest a workaround to access the HMA? I worked this around by copying the fonts in real mode into a file, but other services may be mapped into the HMA, and DJGPP programs will crash on them.