From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9906011841.AA15376@clio.rice.edu>
Subject: cwsdpmi r5
To: djgpp-workers AT delorie DOT com
Date: Tue, 1 Jun 1999 13:41:19 -0600 (CDT)
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Reply-To: djgpp-workers AT delorie DOT com

I've decided it's time to do a cwsdpmi r5, so I'm listening to requests.  What's in today:

1) Bug fixes for physical memory usage between 128Mb and 256Mb
2) Bug fixes for total virtual size of up to 512Mb
3) PC98 raw mode support
4) Merge PFM686 changes as a compile option

Things I'm thinking about:

1) Physical memory support using XMS (himem.sys) up to 2Gb
2) Physical memory support max at 256Mb instead of wrapping > 256Mb
3) Virtual memory support up to 2Gb
4) Built in stub
5) PFM686 support as run-time option

Issues:
1) Page directories live in DOS memory, so total virtual is limited to
   about 512Mb without paging directory entries.  So, does supporting
   more than 512Mb physical even make sense?
2) Using XMS memory breaks the hack to handle >1Mb DMA buffers.  Should
   there be a workaround?
3) There are code size and run-time performance penalties for supporting
   more than 256Mb of either virtual or physical memory.  Is there a good
   reason to do so?
4) Due to a design flaw, supporting >256Mb virtual at run time will break
   the exisiting CWSPARAM stuff (backward compatibility issues).  But this
   code is written, tested and easy to turn on.
   
As always, no guarantees, but if someone has a strong opinion I'll listen.