🚀 go-pugleaf

here's yet another semi-dumb question from me....  I've just released
a program for Amateur Radio (a packet radio terminal program, to be exact),
and it seems to have one little problem.

on slower systems (so far, primarily XT clones, and ONCE on a 286), it
seems that if there are any particularly badly behaved TSRs (the type
that grab the system clock interrupt and don't give it back to the
system, or insist on being the only program attached to that interrupt),
the program crashes, and sends the computer off into the land of null
pointers.

this program does use some functions that operate in the background,
and requires the clock tick interrupt to do this.

is there any way (short of simply telling people not to use those TSRs)
to either
   1) detect that this is GOING to be a problem, or
   2) prevent the problem in advance?

if (1) can be done, is there a way to identify which TSR is associated
with the danger?

also, does anyone know of any problems with Turbo C++ 1.0 (after the 2
patches found on SIMTEL20 are applied) that might cause this?

PS:  the windowing lib, which provides for the background functions, is
UltraWin version 2.10, if that helps people be more familiar with exactly
what I'm using.

any help appreciated.
   --jim

\input std_disclaimer                     % 73 DE N5IAL (/9)
------------------------------------------------------------------------------
"[...] the plural of `mongoose' ought to be `polygoose'." [Jargon file 2.9.10]

INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO:  n5ial@n9hsi (Chicago.IL.US.Earth)
------------------------------------------------------------------------------