Mail Archives: djgpp/1996/05/03/06:39:19
> I run this program and it works: it shows me the error string and terminate
> the application returning to the dos prompt. Now everithing seems to be good
> (the original int 0x24 is restored and works well) but if I run another
> program that want to handle directly the interrupt my system reboots.
>
> Why this? There's a bug in my code or this behaviour is due to the DPMI
> interface used by DJGPP programs?
I am no expert on the detailed workings of these, but my hazarded (and
probably hazardous!) guess would be that there is something that's been
forgotten in the free_int24h function, and that it leaves the system in a
state not exactly as the program left it and this anomaly rears its head
when other programs try to reset the interrupt a third time. All of this I
discern applying the techniques of computational forensics (like traffic
accident forensics: first you reconstruct the crash, etc. :-)) Here the
only thing the program can "know" that is rebooting the machine is that
your program redirected the interrupt. Your program is presumably meant to
do this whole thing "clean", i.e. leaving the computer in the exact state
it was in before the program was called, and the free_int24h function is
meant to do this. Since the program evidently does not leave the machine
"clean", the culprit is either free_int24h or the dpmi functions, on whose
shoulders the responsibility for "cleanness" lies.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." ,------------------------------------------------
-- B. Mandelbrot | Paul Derbyshire (PGD) ao950 AT freenet DOT carleton DOT ca
- Raw text -