Ctrl-C vs Ctrl-Break

[alank2]

I've always been curious about this. Ctrl-C is ASCII code 3, right? What is Ctrl-Break? How are they connected/alike? Different?

 

[mbbrutman]

If you are referring to DOS, they are different.

As you noted, Ctrl-C is just another ASCII character. DOS by convention treats it as "quit" or "cancel", but if you do your own keyboard handling through BIOS calls you can treat it as a normal character.

Ctrl-Break generates a scan code that gets intercepted by DOS and causes a Ctrl-Break handler to be called. The default Ctrl-Break handler for DOS usually just ends the program. You can install a different handler and then choose your own behavior. For example, if you need a very controlled shutdown for your program you can install a Ctrl-Break handler that sets a global variable when Ctrl-Break is pressed. And in your main program loop you can monitor that global variable and start a controlled shutdown of your program when it is safe to do so.

All of my networking code has to install a Ctrl-Break handler so that I can do a graceful shutdown of the program. If I don't, then other interrupts that I hooked will still be firing after the program ends those would be more than likely to cause crashes. If the default DOS handler isn't safe enough then you have to install your own.

Search for DOS Int 23 for more details. (http://www.techhelpmanual.com/563-int_23h__ctrl_break_exit_address.html is a good start.)

 

[Makefile]

For the purposes of the BREAK ON/BREAK OFF command are they equivalent though? As far as how often command.com checks for one of them to cancel an internal command?

 

[Krille]

As I understand it, Control-Break and Control-C are effectively the same. DOS hooks interrupt 1Bh and invokes interrupt 23h whenever Control-Break is pressed. So you only need to hook interrupt 23h to ensure a clean exit. Or am I missing something?

 

[mbbrutman]

As I understand it, Control-Break and Control-C are effectively the same. DOS hooks interrupt 1Bh and invokes interrupt 23h whenever Control-Break is pressed. So you only need to hook interrupt 23h to ensure a clean exit. Or am I missing something?

They are only the same if you use DOS to do your keyboard handling. If you use a BIOS routine to read the keyboard, Ctrl-C just becomes another ASCII value that gets passed back to you with no special handling.

 

[Krille]

Right, but I was referring to the need to ensure a clean exit. If you're only using the BIOS for keyboard handling and the user hits Control-Break then the BIOS will invoke interrupt 1Bh, right? And since DOS has hooked that interrupt it will in turn invoke interrupt 23h. So all I need to do is hook interrupt 23h to be able to quit gracefully. At least that's my understanding of how it works.

 

[mbbrutman]

Right, but I was referring to the need to ensure a clean exit. If you're only using the BIOS for keyboard handling and the user hits Control-Break then the BIOS will invoke interrupt 1Bh, right? And since DOS has hooked that interrupt it will in turn invoke interrupt 23h. So all I need to do is hook interrupt 23h to be able to quit gracefully. At least that's my understanding of how it works.

Correct. Always provide a Ctrl-Break handler if you need to do an orderly exit, regardless of how you read the keyboard, or if you even read it at all.

 

[Phil_G]

I think the break on/break off and scrllock toggles were more often used to enable/disable the function of a tsr. I often used them in mine.

 

[Chuck(G)]

Ctrl-C can be treated as a standard character; see, for example, the "Page Down" function in WordStar. That's not true of Ctrl-Break.

 

[Phil_G]

Ctrl-C can be treated as a standard character; see, for example, the "Page Down" function in WordStar. That's not true of Ctrl-Break.

Depends at what level Chuck. Ctrl-Break is just a scancode like any other, what you do with that scancode is up to you

 

[Chuck(G)]

Well sure--back in the day, I wrote a popup utility (ConFormat) that did its own keyboard decoding by intercepting interrupt 9. The idea being that you could continue work as usual while your floppies were formatted.

Even at the DOS level, there are exceptions. See, for instance Int 21h, AH=6 DL=0xFF. Does not check for either Ctrl-break or Crtl-C, unlike, say, Int 21h, AH=1.

But that's probably more than the OP wanted to know.

 

[Svenska]

Depends at what level Chuck. Ctrl-Break is just a scancode like any other, what you do with that scancode is up to you

At a hardware level (on an AT or newer), the BREAK key is quite special. It does not follow the make/break (down/up) convention, and needs to be handled specially in the state machine if you want to detect it. It is not possible to detect when the key is released either. So not strictly a scancode like any other.

 

[Phil_G]

My own keyboard driver for 3270 IRMA boards which was part of the standard BT build, assumed a release immediately after operating on the press scancode (IIRC, it was maybe 35 years ago)
Since 'break' & modifier-break were momentary & no repeat, this worked fine for us

 

[Makefile]

Well sure--back in the day, I wrote a popup utility (ConFormat) that did its own keyboard decoding by intercepting interrupt 9. The idea being that you could continue work as usual while your floppies were formatted.

Even at the DOS level, there are exceptions. See, for instance Int 21h, AH=6 DL=0xFF. Does not check for either Ctrl-break or Crtl-C, unlike, say, Int 21h, AH=1.

But that's probably more than the OP wanted to know.

Nice, I remember that from DOS Stuff Microsoft Forgot.