From: Phil Hibbs on
OK, sorry about my somewhat flippant reply, here's a better one.

My original Y was to automate the launch of a Telnet window, log in to
it, and check whether the user is getting a message warning them that
their password is about to expire.

So, I used the technique that I described in my original post,
stuffing the commands into the keyboard buffer and scraping the
console buffer into the clipboard and checking for the expiry warning
(or at least I will when I get the warning because I don't know
exactly what to look for yet).

Now, I am trying to make this into a generic Command Prompt automation
suite, so I can quickly throw together scripts that send commands to a
Command Prompt and interrogate the screen, not limited to STDIO
either, I want this to work with screen-drawing applicatons,
eventually I want to write a Nethack bot with it.

So, I appreciate that you are probably trying to subtly tell me "don't
do that, just do your simple telnet thing another way", but I really
do want to do what I want to do. Telnet is just a MacGuffin.

Phil.
From: m on
So you want to create an application that can process low-level console
input in raw mode? As you have already noted, the key is to get the console
input & output handles. AFAIK, the only way to get these handles is to run
in-process and use GetStdHandle, or to specify them when the process is
launched (as Jonathan has already mentioned). Look at ReadConsoleInput &
ReadConsoleOutput in MSDN for more details on how to read low-level console
input.

"Phil Hibbs" <snarks(a)gmail.com> wrote in message
news:40d9ddc2-8f9a-4abe-919f-d9914ffba236(a)z11g2000yqz.googlegroups.com...
> OK, sorry about my somewhat flippant reply, here's a better one.
>
> My original Y was to automate the launch of a Telnet window, log in to
> it, and check whether the user is getting a message warning them that
> their password is about to expire.
>
> So, I used the technique that I described in my original post,
> stuffing the commands into the keyboard buffer and scraping the
> console buffer into the clipboard and checking for the expiry warning
> (or at least I will when I get the warning because I don't know
> exactly what to look for yet).
>
> Now, I am trying to make this into a generic Command Prompt automation
> suite, so I can quickly throw together scripts that send commands to a
> Command Prompt and interrogate the screen, not limited to STDIO
> either, I want this to work with screen-drawing applicatons,
> eventually I want to write a Nethack bot with it.
>
> So, I appreciate that you are probably trying to subtly tell me "don't
> do that, just do your simple telnet thing another way", but I really
> do want to do what I want to do. Telnet is just a MacGuffin.
>
> Phil.

From: Phil Hibbs on
On Mar 31, 11:15 pm, "m" <m...(a)b.c> wrote:
> So you want to create an application that can process low-level console
> input in raw mode?  As you have already noted, the key is to get the console
> input & output handles.  AFAIK, the only way to get these handles is to run
> in-process and use GetStdHandle, or to specify them when the process is
> launched (as Jonathan has already mentioned).  

> Look at ReadConsoleInput &
> ReadConsoleOutput in MSDN for more details on how to read low-level console
> input.

Yes, ReadConsoleOutput is exactly what I want to do, but I don't know
how to get the handle. I'm running the Telnet (or cmd.exe or
nethack.exe whatever) process, but the language and function I'm using
doesn't provide the facility to specify a console buffer. I'm using
AutoIt, and here's a link to my script and to the help page on the Run
function.

http://www.autoitscript.com/forum/index.php?showtopic=112372
http://www.autoitscript.com/autoit3/docs/functions/Run.htm

AutoIt does have wrappers for many of the lower-level API functions,
so if there's another API that lets me specify my own console buffer
for a new process, then I might be able to use that. I'll probably
need to specify the DLL hook for the API functions to create a console
buffer. I've not delved into this kind of thing much before, but I'm
not scared of it. Well, maybe a little.

Phil Hibbs.
From: m on
I have never used, or even heard of, AutoIt before, so take my answer with
that in mind.

The handle you need to use with ReadConsoleOutput is the stdout handle for a
console. If the IO is redirected to a pipe or a file the call will fail,
but with an actual console it succeeds. I missed the first part of this
thread, but if you are creating the process, you can specify the console to
use; otherwise the easiest way is to attach to it and get the handle from
there (AttachConsole + GetStdHandle)

Hooking will not help in this case because the console is not usually
created by the process directly (either by the loader, or by a parent
process like cmd.exe)


"Phil Hibbs" <snarks(a)gmail.com> wrote in message
news:bf66d149-f9d8-4192-8a71-d1708d1096b5(a)8g2000yqz.googlegroups.com...
> On Mar 31, 11:15 pm, "m" <m...(a)b.c> wrote:
>> So you want to create an application that can process low-level console
>> input in raw mode? As you have already noted, the key is to get the
>> console
>> input & output handles. AFAIK, the only way to get these handles is to
>> run
>> in-process and use GetStdHandle, or to specify them when the process is
>> launched (as Jonathan has already mentioned).
>
>> Look at ReadConsoleInput &
>> ReadConsoleOutput in MSDN for more details on how to read low-level
>> console
>> input.
>
> Yes, ReadConsoleOutput is exactly what I want to do, but I don't know
> how to get the handle. I'm running the Telnet (or cmd.exe or
> nethack.exe whatever) process, but the language and function I'm using
> doesn't provide the facility to specify a console buffer. I'm using
> AutoIt, and here's a link to my script and to the help page on the Run
> function.
>
> http://www.autoitscript.com/forum/index.php?showtopic=112372
> http://www.autoitscript.com/autoit3/docs/functions/Run.htm
>
> AutoIt does have wrappers for many of the lower-level API functions,
> so if there's another API that lets me specify my own console buffer
> for a new process, then I might be able to use that. I'll probably
> need to specify the DLL hook for the API functions to create a console
> buffer. I've not delved into this kind of thing much before, but I'm
> not scared of it. Well, maybe a little.
>
> Phil Hibbs.