DOS/16M

Tenberry Home

Consulting Services

DOS/16M FAQ

Release Notes

DPMI Spec

* * *

DOS/4GW

DOS/4G

DOS/16M FAQ:
Interrupt Handling


[Previous Section] * [Index of FAQ] * [Next Section]
  1. I have a protected mode handler installed as a TSR and signaled via protected mode int 7C. To determine elapsed time, the handler calls the Microsoft library function clock(), signals int 7C, calls clock() again, and checks the difference. I'm finding that erratic values are returned. Do you have any suggestions as to what might be causing this?
  2. If one protected mode program installs a bi-modal communications handler and a second protected mode program is active when a communications interrupt is signaled, will there be any kind of conflict?
  3. Why won't the Microsoft _bios_disk() function work with DOS/16M?
  4. Why is it that when called from an interrupt handler, pointers (32-bit offsets) passed as parameters to an assembly language routine reference incorrect segment register (this works if pointers are global rather than automatic), but when called from non-interrupt code, the same routine behaves correctly?
  5. I'm writing a bi-modal communications handler and I want the real mode handler to access data in high memory. Is there any way I can switch from real to protected mode in a DPMI environment to access data in high memory?

1. I have a protected mode handler installed as a TSR and signaled via protected mode int 7C. To determine elapsed time, the handler calls the Microsoft library function clock(), signals int 7C, calls clock() again, and checks the difference. I'm finding that erratic values are returned. Do you have any suggestions as to what might be causing this?

Interrupt masking during real mode <-> protected mode transitions could easily account for variation in results. You may get more consistant results if you assign a protected mode pointer to the BIOS data tick count and use that directly for interval calculation.


2. If one protected mode program installs a bi-modal communications handler and a second protected mode program is active when a communications interrupt is signaled, will there be any kind of conflict?

No.


3. Why won't the Microsoft _bios_disk() function work with DOS/16M?

We don't provide register translation for INT 13h, so protected-mode addresses aren't translated to real-mode, and extended-memory data structures just aren't accessible. You will need to provide your own wrapper and translation.

We suggest using d16SignalRMInterrupt() to actually signal the interrupt.


4. Why is it that when called from an interrupt handler, pointers (32-bit offsets) passed as parameters to an assembly language routine reference incorrect segment register (this works if pointers are global rather than automatic), but when called from non-interrupt code, the same routine behaves correctly?

The routine uses implicit segment registers; it assumes DS=SS. This assumption fails in ISR case. There are a couple of things you can do: be certain that pointers passed to this routine are always global or automatic, coding the called routine appropriately, with segment overrides if needed; pass 48-bit pointers, including the correct selector value; or simplest of all, pass no pointers, just return the desired 16-bit value.


5. I'm writing a bi-modal communications handler and I want the real mode handler to access data in high memory. Is there any way I can switch from real to protected mode in a DPMI environment to access data in high memory?

Use a real-mode callback function(INT 31h func 303h). It's worth doing it this way, instead of through a pass-up communications handler, because the data-copying function won't be used every time an interrupt occurs.


[Previous Section] * [Index of FAQ] * [Next Section]
Last modified 2003.02.07. Your questions, comments, and feedback are welcome.