Mail Archives: djgpp/1999/05/05/08:47:56
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.
- Raw text -