Mail Archives: djgpp/2001/07/26/12:00:12
> 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?
- Raw text -