Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: Please help me with TC ssignal
Message-ID: <22f06fd2@ralf>
Date: 29 Jul 88 12:30:10 GMT
Sender: netnews@pt.cs.cmu.edu
Lines: 25
In-Reply-To: <11061@cgl.ucsf.EDU>

In article <11061@cgl.ucsf.EDU>, kneller@cgl.ucsf.edu (Don Kneller) writes:
}Although not familiar with TC's ssignal() [ How does it differ from
}signal()? ]

ssignal() is a purely software signal, and is invoked only by gsignal().

}BTW, does anyone know the difference between ^C and ^BREAK?  I have
}found that if ^C is *not* the first character in the type-ahead buffer,
}DOS won't abort, but ^BREAK will always make DOS abort.  Is this
}perhaps a function of my software buffer expander?

No, the keyboard routine in ROM generates an INT 1Bh when it detects ^Break,
and DOS traps that interrupt and sets the ^C flag.  The keyboard routine also 
clears the keyboard buffer, but that may not affect your buffer expander.
A ^C has to be the first character in the buffer because DOS peeks at the next
character only, since it doesn't buffer keyboard input itself (you'd see some
strange results with programs that use the BIOS functions to read the kbd if
it did).


--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school)
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/31
Disclaimer? I     |Ducharm's Axiom:  If you view your problem closely enough
claimed something?|   you will recognize yourself as part of the problem.