timlee@public.btr.com (06/16/91)
If himem.sys is in config.sys, Windows (3.0) can run in protected mode. Here is the problem: With himem.sys, running Windows, Intel Code Builder C (iCC 1.0), or other DPMI extended program (i.e. anything linked with iCC) causes subsequent executions of Pharlap 386|* (2.2d), MetaWare High C (2.3), or any VCPI extended program (i.e. things linked with Pharlap 386|link) to be unable to find enough memory. Removing himem.sys removes this problem, but removes the possibility of running Windows in protected mode. What would be nice to know is if there is a simple way to "fix" the memory after running a DPMI program so that VCPI programs can find the memory again. Please email replies.
pshuang@athena.mit.edu (Ping-Shun Huang) (06/19/91)
In article <3077@public.BTR.COM> timlee@public.btr.com writes: > Removing himem.sys removes this problem, but removes the possibility > of running Windows in protected mode. > > What would be nice to know is if there is a simple way to "fix" > the memory after running a DPMI program so that VCPI programs can > find the memory again. HIMEM.SYS itself is not a DMPI server, but rather an XMS memory allocator. If VCPI applications will not run after DMPI applications are run beforehand, it may be that the DMPI programs do not re-release their memory back to HIMEM.SYS properly. Additional question: if you load HIMEM.SYS but do not run any DMPI programs, will VCPI programs work for you? If so, then I suspect the above, otherwise HIMEM.SYS is probably grabbing too much memory on startup (it won't yield the memory to VCPI programs since it is not VCPI-compliant) and you can try using switches (in CONFIG.SYS) to make HIMEM.SYS leave some extended memory completely unallocated so that VCPI programs will be able to find some. -- Singing off, UNIX:/etc/ping instantiated (Ping Huang)