Date   : Sat, 22 Dec 1984 16:06:00-EST
From   : Leor Zolman <LEOR@Mit-Mc.ARPA>
Subject: RST 6

Some early versions of BDS C v1.5 did indeed use RST 6, but as soon as I
realized this was wiping out console I/O vectors left and right I stopped
distributing it that way. The usage of a RST vector is solely connected with
the CDB (C symbolic debugger) mechanism...when you do not intend to use  CDB
on a program, there is no reason for any RST locations to be clobbered. The
reason I originally had the run-time package write into RST 6 was for the case
where someone creates a COM file intended for use under CDB (and thus filled
with RST 6 calls), then tries to run it standalone. It would bomb if CDB were
not there to intercept the RST 6 calls. So, I had the run-time package put
a little "no-op" subroutine at location 30h. Bad idea.

The way it works NOW is: the mechanism for writing the dummy subroutine is
still there, but it is not enabled until you go in and change some EQU's and
reassemble the run-time package. Apologies to those of you who have wasted
time puzzling over bombing BDS C programs because of this.

One more note: the phenomena where BDS C-coded utilities refuse to put out
characters until the keyboard is hit can be fixed by recompiling the programs
under v1.5. Eariler versions of the library did indeed do the wrong thing
when looking at the return value from "check consle status". This problem
is likely to keep popping up and biting people until the binary versions of
programs like SQ-USQ are updated with more current libraries.
       -leor