From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Pharlap 286 Date: Fri, 27 Jul 2001 14:06:25 Organization: Aspen Technology, Inc. Lines: 37 Message-ID: <3b617561.sandmann@clio.rice.edu> References: <996234387 DOT 551529 AT queeg DOT ludd DOT luth DOT se> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 996261608 25810 10.32.115.107 (27 Jul 2001 19:20:08 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 27 Jul 2001 19:20:08 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 > What are [PC98] differences? I found a document pc98.pdf by searching > on www.google.com but it's not talking about XMS, extended memory or > INT15. Is this documented in RBIL? I don't have a PC98 machine to test - all of the stuff has been explained in email, donated code, or tested by others. Best suggestion is to look at the CWSDPMI source. > I'm hacking FDXMS.SYS adding memory detection using INT15 > AX=0xe820 etc, so I'm interested in what I have to do to do (Hey, it > echoes here!) it properly. CWSDPMI uses 0xe801 and 0x88 - they seemed to be universally supported ones on the couple of dozen machines I tested. There are strange configurations with memory holes, etc that HIMEM.SYS supports that the raw mode of CWSDPMI doesn't. RBIL's does give lots of details on the other interrupts. I found some of the other interrupts to behave irratically or have bugs on some BIOSes. > :> How hard would it be to make CWSDPMI support 16-bit DPMI as well? > > Can't this be solved by having 32-bit version and somehow detect that > it's a 16-bit application making the interrupt and then massage the > arguments? You can do some of this when the DPMI provider handles interrupts (just clearing the upper word of each EAX register). But the format of the exception handler structures is different for 16-bit DPMI, and if the client hooks exceptions or interrupts (or chains them) they all have to be of a consistent type. So different IDTs. > If CWSDPMI switched to V86 mode instead of real mode this would not be > a problem. Setting up and maintaining a V86 mode is an equivalent problem to the total code in CWSDPMI and not worth the effort (unless you're trying to re-write EMM386 - which is not what I wanted to do...)