Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE30136C079@probe-2.acclaim-euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Help with interrupt wrapper, PLEASE = ( Date: Wed, 5 May 1999 10:21:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: djgpp AT delorie DOT com Miguel A. Ordorica V. writes: > In theory, the wrapper allows for two different functions to be > called: one with interrupts disabled and the other one with > interrupts enabled. This is so that very long functions can be > associated with an irq without having interrupts disabled long > enough to mess up the program. Unfortunately, DPMI interrupts don't work the way you seem to be expecting. You cannot just modify the stack and then iret to a different part of the code, and even if that did work the same way as in real mode, your __wrapper_isr_after routine isn't going to work because it is calling C code without first setting up a valid stack or selectors (the whole point of having a wrapper is that you need to do that before you start running flat memory model code like the gcc output). I don't really understand why you need to split the handler like this: what is wrong with just reenabling interrupts in the middle of your handler? Allegro does a lot of that, and it works fine: in fact the whole point of writing these custom wrappers rather than using the go32 versions from libc was that my routine dynamically allocates the interrupt stack, so it can correctly deal with reentrant interrupts. If the second part of your handler absolutely cannot run in an interrupt context, you need to use the djgpp signal handling mechanism to defer processing into the mainline code: just raise a signal in your IRQ handler, and hook it elsewhere. That causes its own set of difficulties, though, for example if you are hooking a timer interrupt, your signal handler will be frozen whenever real mode code is being executed. That may or may not be a problem depending on what you are trying to do: it may be ok to defer redrawing a mouse cursor until after the DOS code has finished running, but it is bad news if you start loosing keypresses, or if the music stops playing whenever the disk is accessed :-) Shawn Hargreaves.