lubkt@vax1.cc.lehigh.edu (05/03/90)
Thanks a lot to those people who responded with very intelligent comments, suggestions and leads to the question I posted earlier this week (subj: "An advanced DOS question .."). Last time my question was rather open-ended. Let us see if I am able to say all I want to this time. Last time I asked how to run a program which does not accept I/O redirection. I got several leads to some of the public domain software such as KEYFAKE and FAKEY. Some one also sent me a C-code to modify the keyboard buffer directly. A lot of program seem to work fine with these approaches. I was able to fire-up Turbo C, WordPerfect, etc., without any trouble at all. Then I fired-up the same approach for the program it is supposed to work. Sadly, it did not work. After gaining insight to this problem (thanks to you guys), it seems to me that this approach would not work if there is program which flushes its keyboard buffer: you fill the keyboard buffer, then fire-up the program. After the program is loaded into the memory, the keyboard buffer is flushed--whatever it had in it, it is gone! I do not know why a program might want to flush the keyboard buffer. There may be a valid reason for it. I don't know. If someone knows, then please post it on the net. For those of you who are wondering what program I am talking about, it is TN3270.EXE from Clarkson University (CUTCP/CUTE package). I beleive this package has some enhancements over the NCSA Telnet package. I am not frustated enough to give up my effort yet. I guess I can do something and in that respect may be some of you guys can help me. Here is a proposal. A program that flushes a keyboard buffer *probably* (should that be *must*?) does so via one of the ISR (12H may be?). If there is a TSR that watches for this, then it can intercept the interrupt, save the keyboard buffer (which presumably contains some keystrokes, say via KEYFAKE or FAKEY) somewhere, let the ISR routine clear the buffer and then restore the buffer back. Admittedly this approach is unwieldy, but I just have to do once and I am not concerned so far about the efficiency or the neatness of the code. There is a serious flaw with the above approach. If the above approach is implemented, it will definitely intercept all the calls to 12H service routines, right? What if there some case where the keyboard buffer must be flushed. For example, Alt-Break normally flushes the keyboard buffer and sometimes it may be necessary to do so. In that case the above approach would not work as stated; some work-arounds need to determined. There is yet another approach. This is inspired by the techniques used in MS-Kermit (I forget the version). In Kermit, there are two commands: INPUT and OUTPUT. These commands are used to communicate with the host you are connected to via a PC (Recall that Kermit is a communication package from Columbia University). The INPUT command takes a parameter which is string (say *str*). The effect of this command is to wait until it finds the string *str* from the output generated at the host-level. The OUTPUT command sends the string--specified as its parameter to the the host. Hence the following set of commands can be used to connect to a host computer automatically: KERMIT-MS> input "Username:" ;wait until host displays this string KERMIT-MS> output "<your actual username here>" ;send out username KERMIT-MS> input "Password:" ;now wait until the password prompt KERMIT-MS> output "<your password here>" ;send out password KERMIT-MS> connect ;connect to the host Admittedly, the situation is little different here. The communication is via a serial line and the INPUT command probably reads all the characters generated by the host via a serial link. When it finds the string "Username:", it sends out the username; when it reads the string "Password:", it sends out the password. But this is exactly what I need. I need to fill in the keyboard buffer appropriately and at some fixed point in time. If you permit me to use the word handshaking (which has a lot of *technical* meanings), it is exactly what is required. With this development, my question is how does one monitor what is being spewed on the terminal screen. May be have a TSR that reads *stdout* and searches for the string? When it finds the desired string, it will fill in the keyboard buffer with appropriate keystrokes. But then, isn't there a possibility that *stdout* may not be defined if an I/O routine bypasses DOS's bios and uses DOS interrupts directly? I am not quite inclined to favor a TSR to do that, but I can be persuaded to do so. It will a totally new experience to write a TSR :-). Any comments guys? I will appreciate a lot. Thanks a lot for your comments to my previous posting. Binod Taterway, User Consultant, Lehigh University Computing Center BT00@lehigh.BITNET Bethlehem, PA 18015 LUBKT@vax1.cc.lehigh.EDU (Internet) Disclaimer: I disclaim nothing; I think I ought to be responsible for whatever I say.
toma@tekgvs.LABS.TEK.COM (Tom Almy) (05/03/90)
In article <10151.263f01fa@vax1.cc.lehigh.edu> lubkt@vax1.cc.lehigh.edu writes: >I do not know why a program might want to flush the keyboard buffer. >There may be a valid reason for it. I don't know. If someone knows, >then please post it on the net. Easy. You flush the input buffer to get rid of any unintentional typeahead. Imagine a typist quickly typing: erase *.* (A typing error, as it turns out) yyy foo ( runs program yyy) The erase program prompts "are you sure?", only to immediately snarf the "y", and erases the directory! If you use the command interpreter 4DOS then the KEYSTACK function will do exactly what you want (it can handle buffer flushing). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply