X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	CWSDPMI questions [was Re: Charless Sandmann]
Date:	Sun, 24 Feb 2002 14:09:39 CST
Organization:	Rice University, Houston TX
Lines:	105
Message-ID:	<3c794883.sandmann@clio.rice.edu>
References:	<a5bf05$nrv$1 AT news DOT tpi DOT pl>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1014583647 11832 128.42.105.3 (24 Feb 2002 20:47:27 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	24 Feb 2002 20:47:27 GMT
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> What about changing PD and PT. Is it harmfull to CWSDPMI or my
> program when I change some PD or PT entries?

As long as you know what you are doing you can change the Page Directory
and Page Tables as much as you would like.  Once they are changed you
need a mode swap (calling an interrupt, for example) to get the changes 
loaded.  This feature has been used to rearrange fragmented physical
memory pages (under emm386) to create a contiguous memory area suitable
for DMA usage.

> I'd like to map whole (or fragment) DOS (0-1MB) memory
> to my virtual address space.
> (I allocate 1MB of memory, commit all pages, lock this region,
> go thorugh PD and PT changing physical addresses to point to
> DOS memory)

There is actually a DPMI 1.0 extension interrupt which CWSDPMI supports
which will do this for you.  (See dpmi function 0x508).  I think you could
do the entire 1Mb area in a single call - but it may leave the cache bits
turned off.  But it's easier to flip those after mapping than set up
the entire thing.

> I'd like to map APIC register space to my program
> virtual address space.
> 
> I've tried this before and it worked, but I'm not sure about
> consequences.
> 
> Doing this I make some silent assumptions:
> +cwsdpmi won't change my program base linear address

Correct, unless you specify unixy sbrk() and allocate a DPMI memory block
after a the block containing your program and then ask to increase it's
size.  The resize request would be forced to move it.  Very rare, and
only if you do several things to shoot yourself.

> +cwsdpmi won't remap this modified linear fragment to other physical
> address

Not unless it's in the way of something else you ask it to do.

> +cwsdpmi will be able to allocate memory if asked by DJGPP libc

This shouldn't be a problem, unless you need lots of memory (ie >256Mb)
and the address of the devices you are mapping gets in the way.  Once
again, very rare.

> If answer for some of these questions is NO maybe there is way changing
> this answer to YES?

With the source, there is always a way to fix it :-)

> I'd like to install RM interrupt in the same way as I did in PM (
> directly via IDT)
> I assume that I've service routine in DOS memory.
> 
> Now I can put its address directly into Interrupt Vector Table (IVT).
> But where is it? Where begins IVT for real mode interrupts?
> Does it still begin at 0000 or it's moved somewhere?

Yes, the real mode interrupt table is at address 0 in physical/linear
memory, and that's where the real mode interrupt routines would need to
be set.

> Now I think it's sufficient to put address of my ISR to this table,
> and everything should work fine AFAIR (I've never tried so far)
> As in PM case CWSDPMI won't even see this interrupt when it arrives
> and will get served by my RM ISR.

CWSDPMI has it's own hooks into the RM table - so if you overwrite them
it will never attempt to call it's routines.

CWSDPMI does reprogram the PICs to interrupt on different values.  It
should be transparent, but you can save a few extra cycles by hooking
the right one instead of being bounced to it.

> What abount NMI? I intend to use Local APIC and some "Local interrupts"
> Some interrupts generated by APIC must be carried as NMI.
> Is it possible to crash CWSDPMI by NMI interrupt?

NMIs are passed like regular interrupts to the appropriate interrupt 
routines.  There are some places which CWSDPMI does not like to be
interrupted since it's not reentrant there.  Simple things shouldn't kill
it, but if you do something complex in an NMI in exactly the wrong spot, 
I'm sure it's possible to cause something bad to happen.  This hasn't
been looked at in detail.  NMI handling was improved in r4? r5? so that
it didn't cause problems on some applications - but I didn't look at it
after doing what users requested to fix it.

> When mode is switched from PM->RM there is moment when
> LDT (by LIDT instruction) must be loaded, so there is very short
> (but IS) time, when IDT is invalid.
> Since NMI interrupt cannot be masked, there is possibility
> (very small, but IS) that everything will crash - I think.

This is possible - but in that time the IDT is pointing to the one for
the other mode (real/PM).  I don't think this is only only bad 
possibility.  In reality, some people have used it in ROM applications
using NMI without problems (maybe just lucky...)

> If I'm right is this really dangerous?
> Maybe probability of this is very small e.g 10^-50 ??

It all depends on the number of NMIs and the frequency of mode swaps,
so your guess is as good as mine.

- Raw text -