From: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: longjmp() from interrupt handler
Date: Mon, 20 Jul 1998 23:07:39 +1200
Organization: NetLink Wellington, New Zealand.
Lines: 18
Message-ID: <35B324FB.4A9A38AE@taniwha.tssc.co.nz>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980716155410 DOT 18013E-100000 AT is> <6omtlb$9gs$1 AT wolfman DOT xtra DOT co DOT nz>
NNTP-Posting-Host: nzlu02.tssc.co.nz
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Steve Ball wrote:
> 
> Thanks for your help to my tricky problem. I couldn't agree more that
> forcefully bombing the BIOS out of a hung call is a dangerous idea. But what
> can you do?

What about making the BIOS call from a real-mode stub (so you have an rm
place to return to) and catch the timer interrupt in real-mode?  Now I
could be wrong (Charles? help?) but I beleive there won't be any
*visible* mode changes you would have to worry about and thus as
everything is done in real-mode, you won't confuse the DPMI server. 
Now, I'm pretty certain this will work with cwsdpmi as it actually uses
real-mode (or vcpi) when running rm code, but I'm not sure what windows
does.

Bill
-- 
Leave others their otherness.