From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Pharlap 286 Date: Wed, 25 Jul 2001 14:54: 7 Organization: Aspen Technology, Inc. Lines: 22 Message-ID: <3b5edd8f.sandmann@clio.rice.edu> References: <68C4CF842BD2D411AC1600902740B6DA02CDC45D AT mcoexc02 DOT mlm DOT maxtor DOT com> <3b5df3e1 DOT sandmann AT clio DOT rice DOT edu> <996052472 DOT 673367 AT queeg DOT ludd DOT luth DOT se> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 996091707 4160 10.32.115.107 (25 Jul 2001 20:08:27 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 25 Jul 2001 20:08:27 GMT X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > Charles Sandmann wrote: > : XMS memory and manage it for DPMI applications. If a non-32-bit-DPMI > : protected mode application tries to run, it won't be able to get any XMS > : memory (bad things can happen in the raw memory management world). If > > Can you be more specific about what these bad things are? In raw memory management, the size of the memory is obtained from Int 15, and the A20 state is set by changing port registers. So there is not a good clean way to coordinate between PM programs. In addition, the "standard" way of doing this is to hook Int 15 and decrease the amount of memory reported and do top down allocation. CWSDPMI doesn't do this for a long list of reasons (DMA buffers must be in first 16Mb for ISA cards, multiple Int 15 calls to get memory size, exit stability, etc). So, in a raw environment an application may see all the extended memory free and trash the DPMI memory. If there is extra memory available, and they use top down, it works if you are lucky. In an ideal world CWSDPMI might hook the Int 15 interrupt and return all the known memory size API calls as zero and then the application would always fail as it does under XMS. But it seems no one has complained about it yet, but there are other things people want...