Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!pshuang From: pshuang@athena.mit.edu (Ping-Shun Huang) Newsgroups: comp.os.msdos.programmer Subject: Re: "Fixing" high memory after Windows Message-ID: Date: 19 Jun 91 00:41:50 GMT References: <3077@public.BTR.COM> Sender: news@athena.mit.edu (News system) Followup-To: comp.os.msdos.programmer Organization: Massachusetts Institute of Technology Lines: 25 In-Reply-To: timlee@public.btr.com's message of 16 Jun 91 01:10:24 GMT 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)