Re: Putting A GUI Onto A Command Line Program With AutoIt3
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Tue, 1 Dec 2009 00:07:16 -0600
Actually, unix and windows are different not just because of the OS interface,
but also because windows is more GUI driven. Perhaps using stdin and stderr is
to simple a model -- how dows the slave program handle I/O?
To simplify the unix way of doing things, write pseudo C code to first fork a
child process (see below) then exec the program that you want to control.
Notes: Forking a process creates 2 nearly identical copies of the parent
process -- you determine the process you are in by looking at the return value
of fork. For example, type
pid = fork();
Then analyze pid to determin what's going on -- if pid==0, you know you are in
the child process and can go ahead and connect up the pipes and exec the
program -- note that a call to exec() never returns -- it overwrites the
process image with the new program and starts executing it as if it were called
from the shell. You lose sight of the pipes, which have one end in the parent
process, but are tied to stdin and stdout in the child -- the stdin and stdout
survive the exec operation. In fact, stderr also survives, but all other
filenames are lost.
Now, back to pid, if pid == -1 you have a fatal error -- you are still in the
parent process and no child was created. Handle it as best you can.
Finally, if pid is anything else, treat it as the unix process id for the child
process -- you are in the parent process. Save the value of pid for later use
and go on doing whatever you want in the parent process. Note that this can
include stopping at some point to wait for the child process to complete.
Ok, so that's the unix magic -- a little of what happens under the covers. I
don't know what additional magic goes on in windows. I don't even know if
windows supports anything like fork/exec.
I haven't brought myself to downloading and reading the book on windows kernel
and internals. I am a real nerd when it comes to learning new thechnology -- I
start from the inside and work my way out. Perhaps that is backward, but it has
worked in surprisingly many projects.
What I need is a tutorial on writing a windows app -- com and .net and all that
stuff. Any pointers welcome. Meanwhile, feel free to pick my brain on stuff I
do have experience in.
Happy hacking.
--le
----- Original Message -----
From: Tyler Littlefield
To: programmingblind@xxxxxxxxxxxxx
Sent: Monday, November 30, 2009 7:31 PM
Subject: Re: Putting A GUI Onto A Command Line Program With AutoIt3
Hello,
Having done something similar in both windows and unix, I really highly
recommend the unix idea. I don't believe windows even supports a fork call, and
their pipes are really weird as opposed to something on unix using a fork and
then writing from a pre-created pipe.
On Nov 30, 2009, at 4:24 PM, qubit wrote:
Hi Jim and all --
I've been following this thread and wanted to suggest one thing, which may
or may not apply in this environment... On unix, when you have one program
controlling another, you have to take care to differentiate between the stdin
and stdout of your host program and the stdin and stdout of the slave program.
What i did once in writing a game on unix was to fork a child process for each
slave program and create a pipe for stdin and a pipe for stdout of the child
program. This had to be done before running exec to run the child program. Well
this requires some unix knowledge, but the upshot was that pipe a was tied to
stdin of the child and so the host program write to pipe A, and pipe B was tied
to stdout and so the host program read from pipe B.
I don't know autoinit so can't compare, but I hope you get the idea. The
host program obviously reads from the user and writes to the GUI, so that is
unchanged. The child or captive process has its environment altered.
If you have any questions about unix process control, this is one area I am
familiar with, as I have worked on debuggers and games and other software that
fiddles with process environments and controls. But again, I still need to
learn windows' way of doing it -- my background is in unix.
Sounds like a fun project. Enjoy.
--le
----- Original Message -----
From: Homme, James
To: programmingblind@xxxxxxxxxxxxx
Sent: Monday, November 30, 2009 12:40 PM
Subject: RE: Putting A GUI Onto A Command Line Program With AutoIt3
Hi Tyler,
Are you saying that once I find stdin and stdout that I just input my
commands into stdin and look for the responses in stdout? And that’s it?
Thanks.
Jim
Highmark recipients, Read my accessibility blog
"If a green on green tree falls in the forest and you're there, can you
see it?"
"Not unless you have a screen reader." :)
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler Littlefield
Sent: Monday, November 30, 2009 1:01 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Putting A GUI Onto A Command Line Program With AutoIt3
Hello james,
AutoIt sounds fine. what you'll have to do is retrieve the handles and
write to the stin and read from the program's stdout. You can send more than
one command through stdin, and that would be the same as typing it at a console.
HTH,
On Nov 30, 2009, at 10:50 AM, Homme, James wrote:
Hi Tyler,
Thanks for saying this. Now I’m remembering that languages like Perl can
run another program and read their output that normally would go to the screen.
To interpret what you say, then, it sounds like I’d want to find a similar
function in AutoIt.
If I’m right, my next question is that if the program is still running,
would I need to figure out a way to send it more commands? If so, how would my
program find where to send them? Is it possible to do that without displaying
the input to the screen?
Let me explain what I’m up to here. I found a chess playing engine called
Crafty, which is one of the best free chess engines, as far as I have read.
Anyway, I’d like to see if I can make an accessible GUI and use that to control
the chess engine. I know about Winboard for JAWS. I’m not a C programmer at
all, and I thought that maybe I could make a GUI using AutoIt3. If this isn’t
the best way to go, I’d entertain doing it in some other language, but I had to
pick something, so I picked AutoIt.
Thanks.
Jim
Highmark recipients, Read my accessibility blog
"If a green on green tree falls in the forest and you're there, can you
see it?"
"Not unless you have a screen reader." :)
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Tyler Littlefield
Sent: Monday, November 30, 2009 11:40 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Putting A GUI Onto A Command Line Program With AutoIt3
hello jim,
What you'll have to do is capture the stdin and stdout handles, and
possibly stderr to monitor for input and allow for writing to the program.
HTH,
On Nov 30, 2009, at 9:05 AM, Homme, James wrote:
Hi,
I don't understand how this kind of thing works in the first place, so
I'm not sure what to ask. I'll just start at the beginning.
When any program runs another one in Windows, and it wants to see its
output, where does it look?
Thanks.
Jim
Highmark recipients, Read my accessibility blog
"If a green on green tree falls in the forest and you're there, can you
see it?"
"Not unless you have a screen reader." :)
--------------------------------------------------------------------------
This e-mail and any attachments to it are confidential and are intended
solely for use of the individual or entity to whom they are addressed. If you
have received this e-mail in error, please notify the sender immediately and
then delete it. If you are not the intended recipient, you must not keep,
use, disclose, copy or distribute this e-mail without the author's prior
permission. The views expressed in this e-mail message do not necessarily
represent the views of Highmark Inc., its subsidiaries, or affiliates.
Other related posts: