X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <43E3884C.8050308@mainstreetsoftworks.com>
Date: Fri, 03 Feb 2006 11:43:56 -0500
From: Brad House <brad AT mainstreetsoftworks DOT com>
User-Agent: Mail/News 1.5 (X11/20060131)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: TSR issues (with code)
References: <43E12016 DOT 2070308 AT mainstreetsoftworks DOT com> <7t88b3-d2q DOT ln1 AT news DOT infowest DOT com> <43E1863D DOT 8080308 AT mainstreetsoftworks DOT com> <fgt8b3-c4u DOT ln1 AT news DOT infowest DOT com> <43E216B4 DOT 70509 AT mainstreetsoftworks DOT com> <43E243F8 DOT 7060401 AT mainstreetsoftworks DOT com> <1o8ab3-2i71 DOT ln1 AT news DOT infowest DOT com> <k2qab3-d7b1 DOT ln1 AT news DOT infowest DOT com> <43E2C6DA DOT 4080700 AT mainstreetsoftworks DOT com> <4mcbb3-q1f1 DOT ln1 AT news DOT infowest DOT com>
In-Reply-To: <4mcbb3-q1f1.ln1@news.infowest.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

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
> 
> 
> 
> 
> 
>