Windows 3.1: INT 30 - Function ?

[SFan00]

Hi.

In doing some research I came across something in an article I did not understand.

According to RBIL ( A published list of intterupt calls for IA32)

- INT 0x20 - Vxdcall ( Windows 3.x/Windows 9x)

- INT 0x2E - NT syscall ( Windows NT)

- INT 0x2F - Multiplexor ( Windows 3.x/ Windows 9x)

There are others, however one article claims that INT 0x30 is also connected with VXD's (.386 in Windows 3.x),

RIBL claims that INT 0x30 is a PM Callback in Windows 3.1, but doesn't go into any further depth..

Anyone here know what this 'mystery' call is, and perhaps more importantly if it's ever actually used from user

code of that era?

[dencorso]

Anyone here know what this 'mystery' call is, and perhaps more importantly if it's ever actually used from user code of that era?

Yes, several. Not usually from user code (yet, define "user code"...), not necessarily just from that era.

Find and read: "Calling VxD functions from Win 16 (protected mode) code", in Matt Pietrek, "Windows 95 System Programming Secrets", chap. 6, p. 427-430 (1995); ISBN 1-56884-318-6.

BTW, read also J. de Boyne Pollard's "On questions having yes/no answers".

[SFan00]

Anyone here know what this 'mystery' call is, and perhaps more importantly if it's ever actually used from user code of that era?

Yes, several. Not usually from user code (yet, define "user code"...), not necessarily just from that era.

Find and read: "Calling VxD functions from Win 16 (protected mode) code", in Matt Pietrek, "Windows 95 System Programming Secrets", chap. 6, p. 427-430 (1995); ISBN 1-56884-318-6.

BTW, read also J. de Boyne Pollard's "On questions having yes/no answers".

OK, thanks for the very prompt response , and reference.

I'll try and get a copy because it seems a book like that might solve some other research issues I had .

[rloew]

INT 30 is one of two ways I have found that Windows uses to allow V86 code (16-Bit Programs and Real Mode Drivers) to call Protected Mode functions.

Of the four methods I use to enter RING 0 from 16-Bit Code in my RAMDISKs, this is the only one that does not require prior setup or kernel-mode files.

[SFan00]

INT 30 is one of two ways I have found that Windows uses to allow V86 code (16-Bit Programs and Real Mode Drivers) to call Protected Mode functions.

Of the four methods I use to enter RING 0 from 16-Bit Code in my RAMDISKs, this is the only one that does not require prior setup or kernel-mode files.

Hmm...

So is Int30 set as a real mode interrupt or as one in 'protected' mode (i.e via a trap/intterupt gate)?

At the very least it presumably locks the context for the duration of the call, and does some parameter translation

before doing a linear jump?

I would also assume that the return isn't a straightforward IRET as you need to switch back to a 16 bit style environment

vs a 32 bit one..

[rloew]

INT 30 is one of two ways I have found that Windows uses to allow V86 code (16-Bit Programs and Real Mode Drivers) to call Protected Mode functions.

Of the four methods I use to enter RING 0 from 16-Bit Code in my RAMDISKs, this is the only one that does not require prior setup or kernel-mode files.

Hmm...

So is Int30 set as a real mode interrupt or as one in 'protected' mode (i.e via a trap/intterupt gate)?

In V86 mode, all Interrupts switch to protected mode. The Interrupt handler can return to V86 mode as if a Real Mode Interrupt occurred, if necessary.

At the very least it presumably locks the context for the duration of the call, and does some parameter translation

before doing a linear jump?

It does whatever is needed for the intended function. Contexts can change if the function has to wait.

I would also assume that the return isn't a straightforward IRET as you need to switch back to a 16 bit style environment

vs a 32 bit one..

The final IRET automatically switches back to 16-Bit V86 mode.

Since my RING 0 switch is not an intended INT 30 function, I have to unwind the System Stack before the IRET.