delorie.com/archives/browse.cgi | search |
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 |
To: | djgpp AT delorie DOT com |
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |