Date: Wed, 11 Nov 1998 12:19:35 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Michele Manzato cc: djgpp AT delorie DOT com Subject: Re: Return from interrupts to a different location In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Tue, 10 Nov 1998, Michele Manzato wrote: > How can I return to a different location on a different stack from an > hardware interrupt service routine? Sorry, AFAIK you can't do that in the DPMI environment. The DPMI spec explicitly prohibits this, and the way most DPMI servers work, it is extremely hard, if not impossible, to work around this limitation. This is the single most important reason that DJGPP doesn't support multi-processing a-la Unix fork/exec paradigm. > It seems that the DPMI server switches to a local stack when the expected > hardware interrupt is generated, and only then my ISR gets called. So > (apparently) I have no way of knowing neither the CS:EIP nor the ES:ESP > where the execution was at when the hw interrupt was generated, let alone > changing them to return to a different CS:EIP, SS:ESP upon IRET. > > Is there any way out? The only reasonable way out is to use the DJGPP signal facility, and make the signal handler for SIGALRM switch the stacks. This works (somebody even wrote a multitasking package based on this idea), because signal delivery in DJGPP is delayed until the interrupt handler returns and you are back in protected mode with all your selectors set up as usual. The drawback of this method is that signals aren't delivered when the CPU is in real mode (like if the program is in the middle of a real-mode interrupt, e.g. a DOS call). So you can only have useful multi-tasking as long as the program doesn't call DOS/BIOS functions; if it does, multi-tasking is effectively disabled until the real-mode service returns. For more details about the DJGPP signal-handling machinery, read the documentation of the `signal' library function in the library reference.