🚀 go-pugleaf

In article <334@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>The way Zortech supports interrupts is via a library package. You can
>set up a normal C function as an interrupt service routine. Into that
>service routine is passed a pointer to the register state at the time
>of the interrupt. The registers can thus be examined and modified.
>Within the interrupt routine, you can call the previous interrupt handler
>via another call to a library function. Upon return from the handler, you
>can choose to return from the interrupt or chain to the previous handler,
>by having a 0 or non-0 return value.
>
>The interrupt service routine can be set up to be called with its own local
>stack, or use the caller's.

Kudos to Zortech for this.  ZTC's interrupt package is without a doubt
the right way to handle the entire question, unlike the Turbo
interrupt kludge which Microsoft unfortunately picked up (it amazes me
that manufacturers striving for ANSI compatibility would install such an
amazing mess at the same time they are fixing up old kludges by turning
far into _far, etc.)  Zortech's method is altogether incredibly clever.

BUT...

Zortech has yet to ship a working copy of their int_intercept routine.
A caller that asks int_intercept() to use the normal stack will find
that all works well until int_restore() is called, at which point the
heap checker thinks the heap has been trashed.  I thought I had a wild
pointer somewhere and spent days looking for this.  This problem was
reported way back around v2.11 of the library and still exists in the
currently shipping v2.18.  There is a good version on the Zortech BBS.
Let's hope v3.00 is better.

Norbert