Share this post

Link to post

Share on other sites

lod3n 3

lod3n 3

Actually, I did see that, but I decided to just address and take advantage of what's actually happening instead of muck about in the binaries of my programs. My way seems a little safer and easier, and it took me about 2 minutes to develop a working model.

However, your way is much more interesting! Kudos on that work!

Edit: Oops! I see now that it wasn't you that wrote the one that messes with the binary, you wrote Stub.exe, which is pretty awesome. Still, I like my method a lot because I can do it in pure AutoIt, and with ConsoleRead on the child process, I can even have two way communication, again in pure AutoIt.

Share this post

Link to post

Share on other sites

vim 0

vim 0

If you read it wasn't possible, you didn't fully read what you read. See here.

That's some very interesting reading. I was suprised that someone went to all that trouble to hack AutoIt or knew where to do the hack. I could foresee all kinds of problems if his hack code was used extenstively and the support or lack thereof.

That "stub coding" of your was very impressive.

ViM

Edited August 26, 2006 by vim

Share this post

Link to post

Share on other sites

Valik 471

Valik 471

Inter-process communication using std handles, ironically enough, was suggested by me to DaveF. That is a different concept than communicating with a console window. It also does not require reflecting the stream data through the command interpreter at all since both processes have read or write handles to the communication stream.

To communicate with a console, you're not going to be "pure AutoIt" unless you hack the binary. You're just using a feature of the command interpreter and find.exe to direct the stdout stream of a GUI-subsystem application to the console. The stub I wrote reflects all 3 std streams so that the GUI-subsystem application looks and behaves just like a console application. Your solution is very limited in what it can do. My solution is only limited if you try to access the framebuffer of the console directly, which isn't supported.

I would argue that stub.exe is a better choice because:

It eliminates a lot of overhead involved with piping the data into find.exe.

It eliminates the overhead of find.exe searching the data for an empty string.

Share this post

Link to post

Share on other sites

Valik 471

Valik 471

Your solution is very limited in what it can do. My solution is only limited if you try to access the framebuffer of the console directly, which isn't supported.

I stand corrected. I've just done some experimenting and with a single line of code (that is not requried in a true console application), all the Console functions defined by the Windows API become available for a GUI application to use on Stub.exe's console window.

Simply using DllCall() to call "AttachConsoel(-1)" will associated the AutoIt script with Stub.exe's console window. Then all calls to WriteOutput or any other console related Windows API function will work correctly. I've just successfully written red text to a console window reflected by Stub.exe from a non-compiled AutoIt script.

I also found a bug in Stub.exe. Maybe someday if I'm bored and remember, I'll fix Stub.exe, put together a couple examples and upload it all to it's own thread. The moral of the story is Stub.exe is more powerful than I ever imagined and is the perfect tool for reflecting std stream data from a console to/from a GUI-subsystem application.

Edit: Just a small hint. After calling AttachConsole(), the AutoIt script has to open the screen buffer by calling CreateFile() directly (via DllCall()). You need the actual handle returned by CreateFile() and not the pseudo-handle AutoIt returns.

Share this post

Link to post

Share on other sites

archjonesy 0

archjonesy 0

Is it possible to use stub.exe to allow autoit to interface with console applications? If so how?

I'd like to use autoit to interface with different console apps, but the only thing I can come up with is blind writing to the console and hope it doesn't take longer than the sleep I put in... there HAS to be a better way.