using protected mode handler as real mode callback

[Stephen Howe [TeamSybase]]

> Ryan Jewell" <rje...@attbi.com> wrote in message
news:hK74jgD...@forums.sybase.com...
> I tried to post this message through google 2 days ago but the message
still
> hasn't showed up... Sorry if this is a duplicate.

No that is fine. Don't ever use Google to post here, do it direct.

> I have a Watcom C, DOS4GW application and I'm trying to integrate a
> real-mode driver. Everything works fine except I need to install an
> interrupt callback routine and the driver only accepts real mode
> addresses. After a little research, I've found the site
> http://www.tenberry.com/web/dpmi/1104.html that describes how to
> accomplish my goal. I'm having trouble with the assembler code and I'm
> hoping someone has (or can help me write) the C equivalent. If someone
> already has protected mode code that installs a real mode interrupt
> handler (like mouse callback), that would be ideal.

> well... dang. Do you happen to know if there is another way around my
> problem. At first I was hoping I could just create a real mode function (I
> don't know much about this). I imagined I could create a function under
1mb
> (or whatever that magic number is) so I could create a realmode address
that
> would point to it. Anyway, are there other ways I can give the real-mode
> driver a good segment:offset.

What exactly are doing? In your DOS4GW program, are you going to be calling
this drivers interrupt or does it work out that this driver calls some real
mode far function or real mode far interrupt and you want to intercept this.

(Digression: A bit of information.

Tenberry make 3 DOS Extenders: DOS4G, DOS4GW Professional and DOS4GW.
DOS4GW, the last I just mentioned comes free with Watcom C/C++. The other 2
extenders you buy from Tenberry. DOS4G is the top of the range extender,
DOS4GW Professional is just below

If you wonder how they differ from each other it works out that DOS4G
supports most of the DPMI 0.9 API, DOS4GW Professional supports slightly
less and DOS4GW the least. I personally have never liked this as a means of
product differentation
as it means programmers are stuck if their DPMI function is not supported.

A chart showing the differences is here:
http://www.tenberry.com/dos4g/watcom/4gwtable.htm
End Diresssion)

Back to your problem:

If you going to be calling this drivers interrupt ...

Then DOS4GW is fine. You can use Watcom's int386() and the real mode
interrupt will be called (use this if in your call you are not dealing with
real mode buffers or segments). If you are dealing with real mode buffers or
segments then you need to use DPMI 300h which calls a real mode interrupt.
DOS4GW supports 300h

If this driver calls some real mode far function or real mode far interrupt
and you want to intercept this...

Then DOS4GW is no good. It does not support DPMI 303h and 304h which is what
you want. I would recommend Causeway which is free, DOS4GW compatible and
supports all the DPMI 0.9 API (hooray). You can get this here
http://www.devoresoftware.com/freesource/cwsrc.htm

Stephen Howe [TeamSybase]
London, UK

).

[Ryan Jewell]

I tried to post this message through google 2 days ago but the message still
hasn't showed up... Sorry if this is a duplicate.

I have a Watcom C, DOS4GW application and I'm trying to integrate a

real-mode driver. Everything works fine except I need to install an
interrupt callback routine and the driver only accepts real mode
addresses. After a little research, I've found the site
http://www.tenberry.com/web/dpmi/1104.html that describes how to
accomplish my goal. I'm having trouble with the assembler code and I'm
hoping someone has (or can help me write) the C equivalent. If someone
already has protected mode code that installs a real mode interrupt
handler (like mouse callback), that would be ideal.

Thanks.
Ryan

[Ryan Jewell]

Hi Stephen.

I appreciate the help.

> What exactly are doing? In your DOS4GW program, are you going to be
calling
> this drivers interrupt or does it work out that this driver calls some
real
> mode far function or real mode far interrupt and you want to intercept
this.

[...]

> If you going to be calling this drivers interrupt ...
>
> Then DOS4GW is fine. You can use Watcom's int386() and the real mode
> interrupt will be called (use this if in your call you are not dealing
with
> real mode buffers or segments). If you are dealing with real mode buffers
or
> segments then you need to use DPMI 300h which calls a real mode interrupt.
> DOS4GW supports 300h
>
> If this driver calls some real mode far function or real mode far
interrupt
> and you want to intercept this...
>
> Then DOS4GW is no good. It does not support DPMI 303h and 304h which is
what
> you want. I would recommend Causeway which is free, DOS4GW compatible and
> supports all the DPMI 0.9 API (hooray). You can get this here
> http://www.devoresoftware.com/freesource/cwsrc.htm

I believe I am doing a little of both. This card has a real-mode TSR/driver
as I understand it. I am currently using its software interrupt interface to
control the card without problems. So this is like callingint386(). My
problem is that I need to run some code on a certain interrupt they're
handling. One of the driver calls gives the option of providing a callback
routine (a user defined handler). My problem is that I need to provide the
driver with the segment and offset of the handler in DX:BX. I thought I
might be able to convert the protected mode address to the real mode
equivalent but the routine is too high in memory. I looked at creating my
own hardware ISR but decided figuring out this address translation might be
easier. I saw the information on setting up a real mode handler to pass
control to the protected mode routine and thought this was my answer...

Is Causeway easy to integrate? Is there C sample source for accomplishing my
above goal using DPMI 303h and 304h?

Thanks for the help.

[Stephen Howe [TeamSybase]]

> I believe I am doing a little of both. This card has a real-mode
TSR/driver
> as I understand it. I am currently using its software interrupt interface
to
> control the card without problems. So this is like callingint386(). My
> problem is that I need to run some code on a certain interrupt they're
> handling. One of the driver calls gives the option of providing a callback
> routine (a user defined handler). My problem is that I need to provide the
> driver with the segment and offset of the handler in DX:BX

Then that is no problem. I will see if I can find an example or knock
something up better than a text description.

1. Write your protected mode interrupt handler. This can be done in C. When
this is called

Interrupts disabled
DS:ESI = Selector:Offset of real mode SS:SP
ES:EDI = Selector:Offset of real mode call structure
SS:ESP = Locked protected mode API stack
All other registers undefined

You can get at these using Watcom C by doing

void __interrupt myhandler(intpack *regs)
{
// regs can be used to get ES:EDI and by looking at that, you will know
what your software interrupt called you with
}

2. DPMI Call int386x() with

AX = 0303h
DS:ESI = Selector:Offset of procedure to call
ES:EDI = Selector:Offset of real mode call structure

So DS:ESI will point to myhandler
ES:EDI will point to a real mode call structure. This looks like

typedef struct
{ long edi;
long esi;
long ebp;
long reserved;
long ebx;
long edx;
long ecx;
long eax;
short flags;
short es,ds,fs,gs;
short ip,cs,sp,ss;
} RMI;

This structure will be the one filled in when your interrupt is called. The
bottom 16-bits of EBX will be the BX of what your user-defined interrupt is
called by in real mode by the driver.

3. When terminating (normally or not), you need Call int386() with the real
mode address you got from DPMI 304h

> I thought I
> might be able to convert the protected mode address to the real mode
> equivalent but the routine is too high in memory.

It would not help. The code would be 32-bit protected mode code and even if
it was located below 1Mb (and therefore theoretically callable by 16-bit
real mode code) you have to remember that segments in protected mode have
selector values not part of a physical address like real mode. Protected
mode code has be called by other protected mode code.

You can allocate DOS memory (i.e. below 1Mb) using DPMI 100h. This is done
frequently so that a real-mode buffer can be passed to real mode interrupts.
But it does not help here.

> I looked at creating my
> own hardware ISR but decided figuring out this address translation might
be
> easier. I saw the information on setting up a real mode handler to pass
> control to the protected mode routine and thought this was my answer...
>
> Is Causeway easy to integrate?

Yes it is. There are few things you need to do to set it up for Watcom but
it is a drop-in-replacement for DOS4GW.EXE

> Is there C sample source for accomplishing my
> above goal using DPMI 303h and 304h?

Looking...

[Ryan Jewell]

Hi Stephen.

I will start working on moving to Causeway. The explanation of the steps I
need to follow is good. If you come across any sample code (or other helpful
info) please send it.

Did you see the other response in comp.os.msdos.programmer? I think Peter
provided code that would work as long as I was looking for a mouse
callback... While the situation is similar I think the sample code doesn't
address my problem. It seems like his sample is working with a protected
mode interface...

Thanks.
Ryan

"Stephen Howe [TeamSybase]" <SPAMs...@dialGU.ARDpipex.com> wrote in
message news:EWZL22T...@forums.sybase.com...