From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Pharlap 286
Date: Thu, 26 Jul 2001  9:56: 2
Organization: Aspen Technology, Inc.
Lines: 49
Message-ID: <3b5fe932.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> <3b5edd8f DOT sandmann AT clio DOT rice DOT edu> <996153636 DOT 755884 AT queeg DOT ludd DOT luth DOT se>
NNTP-Posting-Host: dcloan.hou.aspentech.com
X-Trace: selma.aspentech.com 996161904 13436 10.32.115.107 (26 Jul 2001 15:38:24 GMT)
X-Complaints-To: postmaster AT aspentech DOT com
NNTP-Posting-Date: 26 Jul 2001 15:38:24 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

> Which functions of INT15 are you talking about? Is AH=0x88 enough or
> must we watch AX=0xe801 and AX=0xe820 as well. And any other one?

You must at a minimum watch 0x88 and 0xe801 but there are others.
Scour RB's interrupt list and you'll find 1/2 dozen for the PC
architecture, and then you also need to support PC98 (Asian) 
which has different requirements.

But this is a moot point, since there are lots of workarounds
(like load himem.sys which allows dos=high, or emm386 which
allows umbs and guaranteed to work).  In the 7 years versions of
CWSDPMI have been out there, I can't recall a single complaint
on this.  I'd much rather spend time supporting 2Gb memory
machines (which are now very common with the cost of RAM).  If
anyone is booting a machine "raw" it's typically for a single
purpose - not general use (spawning obsolete subprograms).

> How hard would it be to make CWSDPMI support 16-bit DPMI as well?

Not terribly hard for true DPMI.  I had a prototype working under
r4, but nothing would run under it.  Why?  Everything I found which
used 16-bit DPMI also assumed there was an extender as part of
the DPMI (calling RM interrupts from PM and expecting it to move
data to RM for you, convert segment/selector, etc).

In particular, the interrupt table format must change to be 16-bit
interrupts instead of 32-bit interrupts (see Intel manual) for 
hooking and chanining, exceptions must be 16-bit, etc.  This is
why you can't have 16-bit and 32-bit DPMIs alive at the same
time.  The DPMI 1.0 fix for this would be to have separate IDTs
for each client (a whole new can of worms).

Building a 16-bit only CWSDPMI was my prototype.  To have
CWSDPMI do both it would need to add lots of if blocks, replace
constants with variables, etc.  Slower, more bloated, more bugs,
with no clear benefit.  I decided it would stay on the shelf
until someone had a convincing argument.

> How hard would it be to make CWSDPMI active from start and map in some
> pages at 0xc0000 - 0xdffff (an EMM386 UMB replacement)?

Currently CWSDPMI turns off paging when swapping back to real mode,
but maybe that could be changed (can't remember details).  Then you 
might be able to touch UMB memory - but you would have to add the 
interrupt hooks to get DOS to recognize it as being available to add
it to the chain.  Kind of an interesting concept - CWSDPMI could 
even potentially use it to store it's own data structures in raw
mode.  But adapter identification might be tricky to determine where
you want to map memory?