Using autoit to make console applikations

[piccaso]

AllocConsole and AttachConsole are not needed.

using them will result in an empty console window poping up

maybe autoit does that on startup (for the console* funcs)...

expandcollapse popup

Func _ConsoleSetTitle($NewTitle)
    Local $call = DllCall("kernel32.dll", "int", "SetConsoleTitle", "str", $NewTitle)
    Return $call[0]
EndFunc  ;==>_ConsoleSetTitle

Func _ConsoleGetStdHandle($nStdHandle = -11)
    Local $call = DllCall("kernel32.dll", "long", "GetStdHandle", "long", $nStdHandle)
    Return $call[0]
EndFunc  ;==>_ConsoleGetStdHandle

Func _ConsoleWrite($hConsoleOutput, $sBuffer)
    Local $buffer_n, $buffer_ptr
    $buffer_n = StringLen($sBuffer) + 1
    $buffer_ptr = DllStructCreate("char[" & $buffer_n & "]")
    DllStructSetData($buffer_ptr, 1, String($sBuffer))
    Local $call = DllCall("kernel32.dll", "int", "WriteFile", "long", $hConsoleOutput, "ptr", DllStructGetPtr($buffer_ptr), "long", $buffer_n, "long", 0, "long", 0)
    Return $call[0]
EndFunc  ;==>_ConsoleWrite

Func _ConsoleInput()
    Local $sInput
    While 1
        If (ConsoleRead(0, True)) Then
            $sInput = ConsoleRead()
            Return $sInput
        EndIf
        Sleep(20)
    WEnd
EndFunc  ;==>_ConsoleInput


;-------------------------
Local $hConsole, $in, $temp
$hConsole = _ConsoleGetStdHandle()
_ConsoleWrite($hConsole, "Whats up?")
$temp = ConsoleRead()
$in = _ConsoleInput()
_ConsoleWrite("'" & $in & "'")

_ConsoleWrite() does the same as ConsoleWrite()

but i cant get this input stuff to work...

[Valik]

piccaso, there is a difference between creating a console programmatically and being launched from (and connected to a console). In the latter case, the program has to be built as CUI application. In the former case, a Windows (or Console) application creates a console. Yes, it is blank, because its under the direct control of the program. Its not a CLI (Command Line Interpreter) like cmd.exe, its just a console window. There is a difference between the two. Creating/attaching a console window, in my experience, is not very useful for anything more than being able to use std streams from a GUI application for debugging purposes. Its much easier to use the STL streams than it is about anything else for formatting output.

[layer]

piccaso, there is a difference between creating a console programmatically and being launched from (and connected to a console). In the latter case, the program has to be built as CUI application. In the former case, a Windows (or Console) application creates a console. Yes, it is blank, because its under the direct control of the program. Its not a CLI (Command Line Interpreter) like cmd.exe, its just a console window. There is a difference between the two. Creating/attaching a console window, in my experience, is not very useful for anything more than being able to use std streams from a GUI application for debugging purposes. Its much easier to use the STL streams than it is about anything else for formatting output.

Ahh, thanks. That's exactly what I was trying to get through, about in order to be a real console application it has to be built as one, not just a console screen from a GUI application.

[piccaso]

Thanks Valik for the explanation.

And thanks again for writing that stub.

I wrote a 'stubloader' that alows you to combine the stub and the autoit exe (source included)

stubloader.zip

Use it like this:

copy /B stubloader.exe + stub.exe + ctest.exe test.exe

stubloader.exe is the stubloader i wrote.

stub.exe is Valiks Wrapper (i hope you dont mind Valik, i put it in the zip too)

ctest.exe is the exe generated by autoit

test.exe is the outputfile

Looks Like this:

Side Effects:

Adds 17,5 Kb to the file (valiks stub was only 3k, damn i have to learn C++ someday...)

Reduced to 11,7 Kb (because size does matter...)

@scriptdir = %temp% because the script is executed in the temp dir

(consider using @workingdir)

@ScriptName is random

test.exe cant have a Icon or Resouce information

(IMO a console programm doesent need that)

This still is an experiment so

Use it at your own risk!

some usefull console Func's comeing up next...

Edited October 31, 2005 by piccaso

[piccaso]

IMO there would be 2 usefull api functions

SetConsoleTextAttribute wich doesent work with the wraper (but works with the 'dirty' patch)

and

SetConsoleCursorPosition wich cant be called from autoit because the COORD struct has to be passed BYREF and i dont know how (so it may be possible...)

Edited October 30, 2005 by piccaso

[Klaatu]

Something strange is happening when I use the stub.exe program. It seems that the stub.exe program is somehow receiving the STDERR stream from a process that is started through the AU3 file and outputing that as part of its STDERR stream. Let me try to explain better.

Here is the line in the autoit script:

_RunOut($wol & ' ' & $sMac, @WorkingDir, @SW_HIDE)

$wol is the program I'm running (a Wake-On-LAN utility if you couldn't guess) followed by the MAC address. But I suspect any program that has output to its STDERR stream would work to demonstrate the problem.

And here is the _RunOut function itself (basically the same as w0uter's RunSTD function):

;**********************************************************************
; Run a command without showing any window.
; Returns the output of the command.
;**********************************************************************
Func _RunOut($sCommand, $sWorkDir = @WorkingDir, $iShowMode = @SW_HIDE)
   Local $sResult = '', $iPID = Run($sCommand, $sWorkDir, $iShowMode, 2)
   While Not @Error
      $sResult &= StdoutRead($iPID)
   Wend
   Return $sResult
EndFunc;==>_RunOut

Very simple function to capture the STDOUT stream from a command. Notice nowhere do I ask for the STDERR stream.

Now, the strange part is the STDERR output from this RUNed program is being received by stub.exe and stub.exe is outputing that text as part of its STDERR stream. I can tell by redirecting the different streams to different outputs. Also I noticed that if I changed the call to _RunOut to just Run (i.e., no STDOUT handle was requested), there was no output to STDERR.

This looks more like an issue with AutoIt itself, not stub.exe. It seems to me AutoIt shouldn't be sending this STDERR stream from a RUNed process out AutoIt's STDERR stream, which in this case stub.exe is picking up. Not that I mind in this case as I wanted that info output anyway, but still..

Can anyone reproduce this? I hesitate to call it a bug at this point, as I don't know if this is by design or not.

[piccaso]

Klaatu, i thing the stream handling feature of Run isnt ready to takeoff right now.

Everytime i used it something strange happened

Try unsing this to capture StdOut. ( i think its called pipe )

#include <file.au3>
$WowStdOutTmp = FileGetShortName(_TempFile())
RunWait($wol & ' ' & $sMac & ' >' & $WowStdOutTmp, @WorkingDir, @SW_HIDE)
$WowStdOutStr = FileRead($WowStdOutTmp,FileGetSize($WowStdOutTmp))

did you use the stub or the stubloader?

do you get the same problems when running interpreted or compiled as gui?

[Klaatu]

It's called redirection, and it only works when you run the program under the command interpreter like this:

RunWait(@ComSpec & ' /c' & $wol & ' ' & $sMac & ' >' & $WowStdOutTmp, @WorkingDir, @SW_HIDE)

I'm very familiar with the process, as it was the only common way to send input to or get output from RUNed programs pre-current-beta. Piping is when you send the output of one command/program and feed it into the input of another command/program.

I have not used the stubloader at all at this point; just trying to see what can be done with stub right now. So far I have not bothered to compile anything, as I feel that is best left to when things are debugged.

Edited November 1, 2005 by Klaatu

[DaveF]

Now, the strange part is the STDERR output from this RUNed program is being received by stub.exe and stub.exe is outputing that text as part of its STDERR stream. I can tell by redirecting the different streams to different outputs. Also I noticed that if I changed the call to _RunOut to just Run (i.e., no STDOUT handle was requested), there was no output to STDERR.

This looks more like an issue with AutoIt itself, not stub.exe. It seems to me AutoIt shouldn't be sending this STDERR stream from a RUNed process out AutoIt's STDERR stream, which in this case stub.exe is picking up. Not that I mind in this case as I wanted that info output anyway, but still..

Can anyone reproduce this? I hesitate to call it a bug at this point, as I don't know if this is by design or not.

This is by design. Remember, with the original AutoIt Run function there was no connection / interaction with the console I/O at all, and all output was going to appear in the child process's console window, though the window itself was typically hidden. Thus, no STDERR connection to stub.exe, so no STDERR output.

When AutoIt "takes responsibility" for any of the console I/O of a child process, e.g. STDOUT only, it actually has to provide handles for the other pipes, as well. The current implementation connects handles that we don't care about to the console of the parent process (AutoIt), which I judged was the expected behavior.

So, a console is created when stub.exe runs. stub.exe runs the compiled AutoIt script, which inherits a connection to the console's STDERR. AutoIt runs the WoL tool, which inherits AutoIt's connection to STDERR, which is connected to the console, thus any error / non-data messages appear from the WoL tool appear in the console window.

[DaveF]

Klaatu, i thing the stream handling feature of Run isnt ready to takeoff right now.

Everytime i used it something strange happened

As always, please post any bugs on the bug forum with a small script that demonstrates the problem.

[piccaso]

As always, please post any bugs on the bug forum with a small script that demonstrates the problem.

I havent been working long enough with that feature to write a bug report.

The strage happenings could be my fault.

(I sayd 'I think')

but if i run into it again i'll post it (in the right forum)

[Valik]

This is by design. Remember, with the original AutoIt Run function there was no connection / interaction with the console I/O at all, and all output was going to appear in the child process's console window, though the window itself was typically hidden. Thus, no STDERR connection to stub.exe, so no STDERR output.

When AutoIt "takes responsibility" for any of the console I/O of a child process, e.g. STDOUT only, it actually has to provide handles for the other pipes, as well. The current implementation connects handles that we don't care about to the console of the parent process (AutoIt), which I judged was the expected behavior.

So, a console is created when stub.exe runs. stub.exe runs the compiled AutoIt script, which inherits a connection to the console's STDERR. AutoIt runs the WoL tool, which inherits AutoIt's connection to STDERR, which is connected to the console, thus any error / non-data messages appear from the WoL tool appear in the console window.

I like it when the "expert" on the subject chimes in and tells me what I already think it happening.

[Klaatu]

When AutoIt "takes responsibility" for any of the console I/O of a child process, e.g. STDOUT only, it actually has to provide handles for the other pipes, as well. The current implementation connects handles that we don't care about to the console of the parent process (AutoIt), which I judged was the expected behavior.

Although I'm not running a compiled AutoIt script as I said earlier, I take your point and assume the same thing happens whether the script is compiled or not.

So, do you think I would only need to ask Run for a STDERR stream to get the output to go there instead of AutoIt's STDERR stream (if you know what I mean)? In other words, would the WoL tool's STDERR be redirected to someplace else (where the StderrRead function could read it), and not appear on AutoIt's STDERR stream?

[DaveF]

So, do you think I would only need to ask Run for a STDERR stream to get the output to go there instead of AutoIt's STDERR stream (if you know what I mean)? In other words, would the WoL tool's STDERR be redirected to someplace else (where the StderrRead function could read it), and not appear on AutoIt's STDERR stream?

That would work but, as we explored in our other thread, if there was more than 10kb or so of STDERR output the STDERR pipe buffer would fill up and the child process would block. If you wanted you could prevent it from happening by StderrRead-ing the output and throwing it away...

[Klaatu]

OK, thanks. That's what I figured too about having to read the stream and throw it away. That is, until and unless something changes later in the beta to obviate the need of course.

[Valik]

DaveF, since you have played with this stuff more and I'm lazy, what would happen if I set the pipe handles to non-inheritable in stub.exe? If I had to guess, I'd say that stub.exe would receive no output from its child since the child wouldn't be able to inherit the handle. Would that be consistent with what you've read or would perhaps Windows allow the child process to inherit the handle but nothing else?

[DaveF]

DaveF, since you have played with this stuff more and I'm lazy, what would happen if I set the pipe handles to non-inheritable in stub.exe? If I had to guess, I'd say that stub.exe would receive no output from its child since the child wouldn't be able to inherit the handle. Would that be consistent with what you've read or would perhaps Windows allow the child process to inherit the handle but nothing else?

I think the child would just be denied access to the handles, and CreateProcess would fail. If you wanted to provide the option to supress all child output you could jack with the flags of the process info structure so that it didn't inherit the handles and hid the child console window. If you wanted to supress just some of the child output... you could get a writable handle to the NUL pseudo-file and try providing that to the child for the output you didn't want. I haven't tried it, but I'd be interested in what results you'd get.

[jaenster]

here is the source

OPEN COMMAND$ FOR BINARY SHARED AS #1
    GET$ #1, LOF(1), Tmp
    CLOSE #1

    MID$(Tmp, 221, 1) = CHR$(3)
    
    OPEN COMMAND$ FOR OUTPUT AS #1
    PRINT #1, Tmp;
    CLOSE #1

or use a hex editor...

i'll do it in autoit when i got more time...

qbasic ftw

[blinko2008]

didnt read the full post, but incase ppl are still looking for this there is a consoletools.exe file that came back as infected with

a Trojan horse BackDoor.Agent.JLM

[Jos]

didnt read the full post, but incase ppl are still looking for this there is a consoletools.exe file that came back as infected with

a Trojan horse BackDoor.Agent.JLM

I case you are interested: This is now a standard option in aut2exe so there was no need to resurrect this old thread.