Mail Archives: djgpp/2006/02/03/11:45:43
Ok, doing realmode reflection doesn't look like it's too bad then...
And you suggest using _go32 function instead of __dpmi functions,
so to chain the interrupt vector, how would that work, it seems as
though there is no _chain_ routine, would I simply call the old
dos realmode int's pm_offset assuming the _go32_dpmi wrappers
made such a routine for me? This is how I think it _should_
look:
#define IDLEDOS_INTERRUPT 0x28
_go32_dpmi_registers dosidle_regs;
_go32_dpmi_seginfo old_dosidle_int, new_dosidle_int;
int in_dosidle=0;
my_dosidle_handler(_go32_dpmi_registers *r)
{
in_dosidle++;
(*old_dosidle_int.pm_offset)(r);
in_dosidle--;
}
capture_dosidle() {
_go32_dpmi_get_real_mode_interrupt_vector(IDLEDOS_INTERRUPT,
&old_dosidle_int);
new_dosidle_int.pm_offset = my_dosidle_handler;
_go32_dpmi_allocate_real_mode_callback_iret(&new_dosidle_int,
&dosidle_regs);
_go32_dpmi_set_real_mode_interrupt_vector(IDLEDOS_INTERRUPT,
&new_dosidle_int);
return(1);
}
int release_dosidle() {
_go32_dpmi_set_real_mode_interrupt_vector(IDLEDOS_INTERRUPT,
&old_dosidle_int);
_go32_dpmi_free_real_mode_callback(&old_dosidle_int);
return(1);
}
Thanks!
-Brad
Rod Pemberton wrote:
> "Brad House" <brad AT mainstreetsoftworks DOT com> wrote in message
> news:43E2C6DA DOT 4080700 AT mainstreetsoftworks DOT com...
>> Wow, thanks for the insight. Actually, I think what I posted
>> actually hooks 0x1c instead of 0x08
>
> I thought you had it named properly. :-) int 0x08 calls int 0x1c...
>
>> maybe PMODETSR reflects 0x08 but not 0x1c...
>
> The assumption on my end is it is not reflecting whichever one your program
> uses. :-)
>
>> 0x28 from realmode to protected mode, all I see that doing is
>> improving latency since my app wouldn't execute while the
>
> Speed is good.
>
>> Also, on reflection, how would I go about doing that? Can that
>> be done within one app, or does the DPMI need to be hacked ?
>
> No you'll be using code like these snippets (not in a useable order):
> __dpmi_raddr old_handler, new_handler;
> __dpmi_regs *r;
> r->x.cs = old_handler.segment;
> r->x.ip = old_handler.offset16;
> __dpmi_get_real_mode_interrupt_vector(0x21, &old_handler);
> __dpmi_set_real_mode_interrupt_vector(0x21, &new_handler);
> __dpmi_allocate_real_mode_callback(int_handler, r, &new_handler);
>
> If you have future plans to use OpenWATCOM, make sure you only use the _dpmi
> functions don't use any of the _go32 functions since there is no way to
> convert some of the _go32 functions to regular _dpmi functions.
>
>> Btw, dosmemget() doesn't call an interrupt, does it?
>
> No interrupt. dosmemget calls movedata, they are in dmg.c and md.S
> respectively. dosmemget moves between _dos_ds and _my_ds() selectors.
>
> I haven't confirmed this, but I think the following are interrupt free: the
> main C compiler (constants, variables, integer arithmetic, flow control and
> procedures), memxxx(), isxxx(), strxxx(), scanf, sprintf, etc. Basically, I
> think anything that you can do without the libraries, or memory only
> functions, or character only functions should be interrupt clean. Any
> functions which call fileio will most likely call an interrupt, including
> some you wouldn't expect at first, like printf().
>
> Darn, I'm going to sound arrogant here, this is a lesson on how to 'think'
> about PM DPMI applications:
> Basically, you are switching between two "OS's" which are completely
> separate. That includes interrupt tables. Those two "OS's" are "RM BIOS &
> DOS" and "PM DPMI." Of course, RM BIOS & DOS is fairly functional. But, PM
> DPMI only has a stripped down memory manager (the DPMI calls), no actual
> operating system. So, to do anything useful, you must switch back and forth
> to RM, calling DOS or BIOS as necessary. Some of this is handled by the
> DPMI host and/or DOS-extender. Some is handled by the C libraries.
> Everything else isn't. Some RM interrupts are also supposed to trigger the
> same PM interrupt per the DPMI specs. Most don't. This is called
> 'reflection' which is done via a 'real mode callback'. When a decent number
> of PM interrupts are setup to trigger the same RM interrupt, it's called a
> DOS-extender. Now, your program is running in PM, so when DOS or BIOS calls
> int 0x08, int 0x1c, or int 0x21 this is in RM and your PM program is
> 'unaware' of it. If the interrupt isn't reflected by the DPMI host, you can
> 'reflect' it using a 'real mode callback'. The 'real mode callback'
> switches from RM to PM and calls a PM routine you specify and then switches
> back to RM from PM. It's a wrapper around your routine which handles the
> PM/RM or "OS" switching. If you set a RM interrupt vector to point to a
> real mode callback which points to a routine in your PM code, your PM
> application is getting RM interrupts via reflection.
>
>
> Rod Pemberton
>
>
>
>
>
>
- Raw text -