jim@applix.UUCP (Jim Morton) (03/17/87)
We have a terminal driver which maps certain keys to our functions, and we want to use control-P. Apparently DOS maps control-P to PrtSc, and if you don't have a PRN device, this goes into a slow, abnoxious loop telling you it can't write to the PRN device. I can't find this key mapping (^P) anywhere in the DOS documentation. Does anyone out there know how to disable this key mapping? TIA, Jim Morton, APPLiX Inc. ...decvax!frog!halleys!applix!jim
chapman@fornax.uucp (John Chapman) (03/17/87)
> We have a terminal driver which maps certain keys to our functions, and > we want to use control-P. Apparently DOS maps control-P to PrtSc, and > if you don't have a PRN device, this goes into a slow, abnoxious loop > telling you it can't write to the PRN device. I can't find this key > mapping (^P) anywhere in the DOS documentation. Does anyone out there > know how to disable this key mapping? > > TIA, > Jim Morton, APPLiX Inc. > ...decvax!frog!halleys!applix!jim This sounds like a holdover from some CPM systems where ctrl/p echo'd all console output to the printer until ctrl/n was entered. It may be that the key codes are not mapped into the prtsc keycode but that the function is wired into dos for that control code (ctrl/p). *** REPLACE THIS LINE WITH YOUR MESSAGE ***
nortond@well.UUCP (Daniel A. Norton) (03/17/87)
Unfortunately, it isn't very easy to disable this function. It is performed
at just about the lowest level in the BIOS. The only successful way that
I have heard of is to capture the keyboard interrupts (where scan codes
are presented).
--
Daniel A. Norton ...!lll-lcc!{lll-crg,ptsfa}!well!nortondralf@b.gp.cs.cmu.edu (Ralf Brown) (03/17/87)
Ctrl-P is only mapped into Ctrl-PrtSc if the CON device is in "cooked" mode (which happens to be the default), in which case DOS also checks for ^S and ^C between each and every character output. I have two little programs (40 and 44 bytes when assembled) that put CON into "raw" mode (no ^P, ^S, or ^C checking) and back into cooked mode. I will post them tonight, as they are at home. An added benefit of putting the console into raw mode is a great speed increase--DOS output on a PC can be nearly the speed of cooked output on an AT. In fact, by using NANSI.SYS, raw mode, and avoiding scrolling, a file browser that I picked up recently achieves virtually the same performance as a file browser that writes directly to the screen memory! The drawback of raw mode is that neither ^C nor ^Break is checked, so it is not possible to interrupt a long TYPE command in the middle. -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
kneller@socrates.ucsf.edu (Don Kneller%Langridge) (03/18/87)
In article <243@fornax.uucp> chapman@fornax.uucp (John Chapman) writes: > We have a terminal driver which maps certain keys to our functions, and > we want to use control-P. Apparently DOS maps control-P to PrtSc, and > if you don't have a PRN device, this goes into a slow, abnoxious loop > telling you it can't write to the PRN device. I can't find this key > mapping (^P) anywhere in the DOS documentation. Does anyone out there > know how to disable this key mapping? > It's quite simple to disable the DOS interpretation of ^P and PrtSc (and as bonuses: ^S is disabled, and screen IO via DOS calls is faster). Basically, you want to change the input routines to use "raw" mode. This is done with the DOS IOCTL interrupt (sorry, don't have the number at hand). Use the IOCTL interrupt to determine the flags for the standard input device (device number 0). Save the original flags, set the "raw" bit (0x80, I think), then use the IOCTL interrupt to set the new flags. This will disable ^P, PrtSc and ^S completely and they will be treated as normal characters by DOS. Also, DOS won't check for ^C in the input buffer everytime a character is output to the screen, so screen IO using DOS calls will be faster (subjectively about 2-3 times as fast). When working on PC HACK, I thought I would have to also change the standard output device (device number 1) to raw mode to get faster IO, but this is unnecessary. Make sure you restore the original flags before your program exits since DOS doesn't do it for you. Otherwise ^S won't pause and ^C won't stop a "dir". ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
dlnash@ut-ngp.UUCP (Donald L. Nash) (03/18/87)
In article <18@b.gp.cs.cmu.edu>, ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > > An added benefit of putting the console into raw mode is a great speed > increase--DOS output on a PC can be nearly the speed of cooked output on > an AT. In fact, by using NANSI.SYS, raw mode, and avoiding scrolling, a > file browser that I picked up recently achieves virtually the same > performance as a file browser that writes directly to the screen memory! > > The drawback of raw mode is that neither ^C nor ^Break is checked, so it is > not possible to interrupt a long TYPE command in the middle. > Another drawback of putting the console in raw mode is that some programs don't like it. I found this out the hard way when I put the console in raw mode and then tried to use Microsoft Link version 3.02. Nothing I typed at Link's prompts would be read. Since ^C and ^Break were disabled, the only way out was Ctrl-Alt-Del. Running with the console in raw mode is fine if you are careful, but beware of programs which don't like it. Remember, you don't have ^C anymore. Don Nash UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash ARPA: dlnash@ngp.UTEXAS.EDU BITNET: CCEU001@UTADNX, DLNASH@UTADNX TEXNET: UTADNX::CCEU001, UTADNX::DLNASH UUU UUU U U The University of Texas at Austin U TTTTUTTTTTTTTT Computation Center U T U TT T U U TT "The world is basically non-linear." UUUUUUU TT TT TTTT
chapman@fornax.uucp (John Chapman) (03/19/87)
> In article <243@fornax.uucp> chapman@fornax.uucp (John Chapman) writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > We have a terminal driver which maps certain keys to our functions, and > > we want to use control-P. Apparently DOS maps control-P to PrtSc, and > > if you don't have a PRN device, this goes into a slow, abnoxious loop > > telling you it can't write to the PRN device. I can't find this key > > mapping (^P) anywhere in the DOS documentation. Does anyone out there > > know how to disable this key mapping? > > > > It's quite simple to disable the DOS interpretation of ^P and PrtSc . . Just aminor point but I didn't write the text attributed to me above. I did post a reply to the original article but the above isn't it. John Chapman ...{ihnp4,watmath,uw-beaver}!ubc-vision!sfucmpt!sfulccr!chapman or !ubc-vision!fornax!chapman
nortond@well.UUCP (Daniel A. Norton) (03/19/87)
In article <4853@ut-ngp.UUCP>, dlnash@ut-ngp.UUCP (Donald L. Nash) writes: > Remember, you don't have ^C anymore. I ran the program provided in a recent posting to set the output to "raw" mode (setraw), my screen speeded up and CTRL-C still works. One difference, perhaps, is that I have "BREAK=ON" in my CONFIG.SYS. -- Daniel A. Norton ...!lll-lcc!{lll-crg,ptsfa}!well!nortond
nortond@well.UUCP (03/21/87)
I had commented earlier on this subject that I had heard that the only
sucessful solution to this problem was by filtering keystrokes at the
scan code interrupt level, and recent experiences with the code
suggested indicate that my initial comments were correct.
I have been corrected, however, that the CTRL-P function is not
performed in the BIOS.
The recently posted "setraw" and "setcookd" programs did not solve the
CTRL-P problem completely. These examples only set raw mode for
standard output and this allowed the CTRL-C to pass through. When I
modified it to also set standard input to raw mode, the CTRL-C had no
effect during output. Unfortunately, the CTRL-C was not passed through
on calls to read the keyboard. If you set both stdin and stdout to raw
mode, the CTRL-P does not cause printer-echo to toggle, but the
keystroke is not passed through either. Somehow, the CTRL-P does cause
some internal flag to be toggled, for when I toggle it and press CTRL-C
(while waiting for input), the "^C" characters appear on my printer.
I am running MS-DOS (not PC-DOS) 3.2 on a Toshiba XT computer with 640k
of memory. What follows is a shell archive of the modified "setraw"
and "setcookd" programs:
------------------------------ CUT HERE ------------------------------
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# setcookd.asm
# setraw.asm
# setcookd.uue
# setraw.uue
#
# This archive created: Sat Mar 21 13:36:50 1987
#
if test -f 'setcookd.asm'
then
echo shar: will not over-write existing "'setcookd.asm'"
else
echo extracting "'setcookd.asm'"
sed 's/^X//' >setcookd.asm <<'SHAR_EOF'
X;----- dos ----------------------
X; Call DOS function # n.
Xdos macro fn
X mov ah, fn
X int 21h
X endm
X
Xcode segment para public 'CODE'
X assume cs:code
X
X org 100h
X
X;----- Setcookd -------------------------------------------
X; Sets cooked state of stdout if it is a device.
X; Returns errorcode in AX if DOS error.
Xsetcookd proc near
X DOS 30h
X cmp al,2
X jb dos1_exit
X mov bx,0
X mov al, 0
X DOS 44h
X jc sc_stdo
X test dl, 80h ; It it a device?
X jz sc_stdo ; nope- do nothing.
X ; Current mode in DX
X and dx, 00cfh ; clear old raw bit and hi byte,
X mov al, 1
X DOS 44h
Xsc_stdo:
X mov bx,1
X mov al, 0
X DOS 44h
X jc sc_exit
X test dl, 80h ; It it a device?
X jz sc_exit ; nope- do nothing.
X ; Current mode in DX
X and dx, 00cfh ; clear old raw bit and hi byte,
X mov al, 1
X DOS 44h
Xsc_exit:
X DOS 4Ch
Xdos1_exit:
X int 20h
Xsetcookd endp
X
Xcode ends
X end setcookd
SHAR_EOF
if test 1229 -ne "`wc -c < 'setcookd.asm'`"
then
echo shar: error transmitting "'setcookd.asm'" '(should have been 1229 characters)'
fi
chmod 666 setcookd.asm
fi
if test -f 'setraw.asm'
then
echo shar: will not over-write existing "'setraw.asm'"
else
echo extracting "'setraw.asm'"
sed 's/^X//' >setraw.asm <<'SHAR_EOF'
X;----- dos ----------------------
X; Call DOS function # n.
Xdos macro fn
X mov ah, fn
X int 21h
X endm
X
Xcode segment para public 'CODE'
X assume cs:code
X
X org 100h
X
X;----- Setraw -------------------------------------------
X; Sets Raw state of stdout if it is a device.
X; Returns errorcode in AX if DOS error.
Xsetraw proc near
X DOS 30h
X cmp al,2
X jb dos1_exit
X mov bx,0
X mov al, 0
X DOS 44h
X jc sr_stdo
X test dl, 80h ; It it a device?
X jz sr_stdo ; nope- do nothing.
X ; Current mode in DX
X and dx, 00cfh ; clear old raw bit and hi byte,
X or dx, 20h ; set RAW bit
X mov al, 1
X DOS 44h
Xsr_stdo:
X mov bx,1
X mov al, 0
X DOS 44h
X jc sr_exit
X test dl, 80h ; It it a device?
X jz sr_exit ; nope- do nothing.
X ; Current mode in DX
X and dx, 00cfh ; clear old raw bit and hi byte,
X or dx, 20h ; set RAW bit
X mov al, 1
X DOS 44h
Xsr_exit:
X DOS 4Ch
Xdos1_exit:
X int 20h
Xsetraw endp
X
Xcode ends
X end setraw
SHAR_EOF
if test 1310 -ne "`wc -c < 'setraw.asm'`"
then
echo shar: error transmitting "'setraw.asm'" '(should have been 1310 characters)'
fi
chmod 666 setraw.asm
fi
if test -f 'setcookd.uue'
then
echo shar: will not over-write existing "'setcookd.uue'"
else
echo extracting "'setcookd.uue'"
sed 's/^X//' >setcookd.uue <<'SHAR_EOF'
Xbegin 666 setcookd.com
XMM##-(3P"<CB[ "P +1$S2%R#_;"@'0*@>+/ + !M$3-(;L! + M$3-(7(/
X5]L* = J!XL\ L &T1,TAM$S-(<T@
X
Xend
SHAR_EOF
if test 121 -ne "`wc -c < 'setcookd.uue'`"
then
echo shar: error transmitting "'setcookd.uue'" '(should have been 121 characters)'
fi
chmod 666 setcookd.uue
fi
if test -f 'setraw.uue'
then
echo shar: will not over-write existing "'setraw.uue'"
else
echo extracting "'setraw.uue'"
sed 's/^X//' >setraw.uue <<'SHAR_EOF'
Xbegin 666 setraw.com
XMM##-(3P"<D"[ "P +1$S2%R$_;"@'0.@>+/ ('*( "P ;1$S2&[ 0"P +1$
X=S2%R$_;"@'0.@>+/ ('*( "P ;1$S2&T3,TAS2#*
X
Xend
SHAR_EOF
if test 131 -ne "`wc -c < 'setraw.uue'`"
then
echo shar: error transmitting "'setraw.uue'" '(should have been 131 characters)'
fi
chmod 666 setraw.uue
fi
# end of shell archive
exit 0
--
Daniel A. Norton ...!lll-lcc!{lll-crg,ptsfa}!well!nortond