Hi, maybe it was discussed in the past many years ago but I just want to know, if on modern PC sytems with 4GB+ RAM and running modern memory manager for DOS like JEMM386 in V86 is there any reason to prefer VCPI over XMS? The available memory via VCPI
is usually just a fraction of available XMS. So I just tried to simply modify a condition at line 192 in valloc.c to pretend no enough VCPI memory available and force switch to use XMS. But I'm not sure if this can have some negative effect to CWSDPMI or
running programs. Modified SRC + BIN to try here:
http://www.rayer.g6.cz/programm/cwsdpmi7.zip
I don't want to disable VCPI by default in JEMM because I still run some older programs that wants VCPI and I just want to DJGPP programs avoid VCPI on same system. Other possibility to do it is to use HDPMI32 -r instead of CWSDPMI. I also found that
there was reported a buggy behavior of EMM386 in DOS 7.10 that confused CWSDPMI to silent exit and nobody seems to fixed it yet, so another reason to avoid VCPI in CWSDPMI.
https://groups.google.com/forum/#!topic/comp.os.msdos.djgpp/4UkalDo_tO8
BTW there's a hot new on field of DOS XMMs. Japheth extended the himemx.exe (now himemsx.exe) to support so called SXMS that is memory beyond 4GB. He introduced new XMS services to allocate such memory and it report itself as ver. 3.5. There's currently
not much programs that can utilize SXMS but one of 1st is rdisksx for RAMDISK and also modified shsucdx that allocate it' buffers in SXMS.
It would be nice to modify CWSDPMI to cooperate with himemsx via this new functions. I know that CWSDPMI can use entire 4GB too but only in raw mode without any XMM loaded that is not ideal. I belive that implementaion would not be so hard, new API
extension is quite simple:
https://github.com/Baron-von-Riedesel/HimemSX/blob/master/XMS35.txt
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)