m21827@mwunix.mitre.org (Ken Stillson) (05/30/91)
Question for any 4dos experts out there:
I'm trying to write a program for 4dos that will impliment active functions
[like the `command` in unix], and have determined that I would like to
intercept the command-input routine of 4dos. That is, after a command has
been typed in, I would like to interrupt and have the ability to modify
what the user entered.
The standard interrupt interfaces defined in 4dos.doc don't allow this,
because they all occur before the command is entered. However, I've got
a program that re-maps some characters [called 4map I think], so I know
it's possible. It seems to use int 0x2f to change some vectors, presumably
pointers to a post-command parser or such. I don't care to completely
dis-assemble the program; so does anyone know how this mechanism works?
Thanks in advance.
- Ken Stillson, stillson@mitre.org
--
panic: cannot read .signature file for kds@uiuc.edu
Abort, Retry, Ignore, Explode? phys169@csc.canterbury.ac.nz (05/31/91)
In article <m21827.675606610@mwunix.mitre.org>, m21827@mwunix.mitre.org (Ken Stillson) writes: > I'm trying to write a program for 4dos that will impliment active functions > [like the `command` in unix], and have determined that I would like to > intercept the command-input routine of 4dos. That is, after a command has > been typed in, I would like to interrupt and have the ability to modify > what the user entered. > There are three suggestions, some of which might not work with 4DOS... (1) Intercept in 2E. DS:DI points to the command to execute, change it and pass the result on to the original 2E handler. This doesn't work! I include it here because it is the easiest thing to try, and it *should* work! Neither 4DOS nor COMMAND.COM seems to call it. Perhaps some versions of COMMAND.COM do, but not mine. (2) Intercept interrupt $2F, and watch for AX=AE00, DX=FFFF. This is the "correct" way to extend COMMAND.COM's command processing (from version 3.3 onwards). If 4DOS doesn't support it, jump up and down until it does, because it should. COMMAND.COM makes this call, with DS:BX pointing to the command line, before executing a command; you can change the command line and return 0 in AL, or you can process it yourself and return FF in AL (telling COMMAND.COM not to bother doing anything more with it). (3) Intercept the keyboard input, either with int 16 or int 21. Messy! If you are that desparate, use my own COMMAND.COM replacement, which does what you want plus most of the 4DOS extensions (My system uses [! command] instead of using `command`, since people tend to get ' and ` confused too easily, and because it allows nested active parameters - besides, I'm a fan of AOS/VS). Hope this helps, Mark Aitchison, Physics, University of Canterbury, New Zealand.
TOMIII@MTUS5.BITNET (Thomas Dwyer III) (06/01/91)
While we're on the topic of command lines, how does one change the command line *before* the ENTER key is pressed (ie - highlight text on the screen with the mouse and click a button to place the text at the cursor in the command line) ? On the AT machines, there is an "Insert character in keyboard buffer" call, but if the buffer fills you lose the end of the command. Any pointers or source code examples would be greatly appreciated. Thanks, Thomas Dwyer III tomiii@mtu.edu tomiii@MTUS5.BITNET
hollen@megatek.UUCP (Dion Hollenbeck) (06/04/91)
In article <91151.122254TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes: > > While we're on the topic of command lines, how does one change the command > line *before* the ENTER key is pressed (ie - highlight text on the screen > with the mouse and click a button to place the text at the cursor in the > command line) ? > One way which comes to mind is to be the command interpreter and be constantly getting characters from the keyboard buffer. In this manner, you can do anything you want to them. This is why 4DOS can implement command-line editing, it is in control of getting the characters one by one and then echoing them in the proper manner depending on position in the buffer, and insert/overstrike mode. Short of being the command interpreter, you could intercept the keyboard BIOS interrupt vector, but the problem there is that you could never have enough smarts to know whether you were processing keystrokes at the command line, or in an application. There is another way possible to get keys from the mouse as you suggest. It however relies on the mouse operating "like a keyboard". The smarts would need to reside in the mouse software to be able to snatch the characters from the screen. When you made the appropriate button press to "stuff" the captured chars, then the mouse software would put the characters, one at a time, in the keyboard buffer. This is how my Logitech Mouse works now (with stuffing chars, it cannot cut from the screen, it is not smart enough). If I have the motion output set to generate arrow keys, then moving the mouse inserts appropriate arrow keys in the keyboard buffer as if I had typed them from the keyboard. Should be no problem with cut and paste text either, as long as the mouse driver is smart enough to know how to cut and paste. If there is not an existing mouse driver which does this, it would be not an excessively hard task to write one. > On the AT machines, there is an "Insert character in keyboard buffer" call, > but if the buffer fills you lose the end of the command. If you are using this and it solves your problem successfully, then the solution to missed keystrokes is a TSR which expands the size of the keyboard buffer. I use a 128 char buffer and I have never overflowed the buffer. If you need more, make sure to get a keybord enhancer which supports buffer size, and make it as big as necessary. Of course, keep in mind the DOS command line length limitation. If you go over that, even if it was in the buffer, DOS will not process more than 128 chars anyway. -- ----- Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp