X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <43E2C6DA.4080700@mainstreetsoftworks.com>
Date: Thu, 02 Feb 2006 21:58:34 -0500
From: Brad House <brad AT mainstreetsoftworks DOT com>
User-Agent: Mail/News 1.5 (X11/20060201)
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>
In-Reply-To: <k2qab3-d7b1.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

Wow, thanks for the insight.  Actually, I think what I posted
actually hooks 0x1c instead of 0x08 (I have it as a define at
the top) since some docs I saw said it was safer, though I don't
know if that is really relevant to this situation, other than
maybe PMODETSR reflects 0x08 but not 0x1c...  As for reflecting
0x28 from realmode to protected mode, all I see that doing is
improving latency since my app wouldn't execute while the
InDos flag was set unless it was set because it was inside
of an int28, so it wouldn't account for the actual lockups,
since without my app being triggered by an int28, it would always
assume when the indos flag is set, that it must not execute.

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 ?

Btw, dosmemget() doesn't call an interrupt, does it?  Want to
make sure I don't need to use nearptrs to access the memory
directly ... I would be ironic if the dosmemget() to retrieve
the inDos and CritErr flags was the culprit!

Thanks!

-Brad



Rod Pemberton wrote:
> "Rod Pemberton" <dont_have AT bitbucket DOT cmm> wrote in message
> news:1o8ab3-2i71 DOT ln1 AT news DOT infowest DOT com...
>> "Brad House" <brad AT mainstreetsoftworks DOT com> wrote in message
>> news:43E243F8 DOT 7060401 AT mainstreetsoftworks DOT com...
> 
>>> 2) With PMODETSR the program seems to terminate totally instead
>>>     of becoming a TSR.  DOS is still fully functional, just my
>>>     program seems to go away.
>> I'll try that first.  Likely indicates a programming error of some sort.
> 
> Yes. It failed.  So I decided to check the RM interrupt addresses to see if
> they were being hooked, i.e., did they change?  And, lo and behold, for both
> the working CWSDPMI and 'failed' PMODETSR, _neither_ had changed the RM
> interrupt addresses.  Hmm, okay, did you setup PM interrupts?  Yup.  You've
> setup PM interrupts.  For DJGPP, the only interrupts available in PM are the
> DPMI spec and any interrupt that gets reflected to PM by the DPMI host,
> i.e., int 0x08 etc.  Apparently, PMODETSR doesn't reflect int 0x08 from RM
> to PM, so it appears to not work.  There is no int 0x28 in PM, which is why
> your int 0x28 routine isn't being called.  For OpenWATCOM, you'll also have
> any of the DosExtender interrupts available.   I think you'll probably want
> to rewrite the code to trap the RM interrupt and reflect it to PM using a
> realmode callback...
> 
> 
> Good luck and keep in touch,
> 
> Rod Pemberton
> 
> 
> 
>