Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
SFan00

Windows 3.1: INT 30 - Function ?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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". :)

Share this post


Link to post
Share on other sites
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 :).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...