Using autoit to make console applikations

[piccaso]

A other solution (whithout patching) can be found down here

i wrote a little prog that patches byte 221 to chr(3) (which turns a gui into a console applikation)

and backwards too.

but you have to patch AutoitSC.bin before compiling.

consoletools.zip

Beware:

This tool is modifying the Header of PE's

(generic not only for autoit, so it should work with all versions)

dont expect support from the dev's after patching

use on your own risk!

use it like this:

change to aut2exe dir
make sure to back up autoitsc.bin it will be replaced
type: amp autoitsc.bin
if it says 'Error' something went wrong
if it says 'OK' everything went fine
now you can compile your script and consolewrite() wil write to the console...

amp can undo the changes by running it again.

i dont know why but consolewrite(@cr) deletes the whole line so use @lf for line breaks.

and gimme some feedback...

how do you create console apps.

i found a lot of trys in the forum but no solution

i played around a bit and created tools to get interactive input and change the color

the source of all tools is included now.

start them to see a small info on how to use or check au3test.au3 and see how i used them

Edited October 30, 2005 by piccaso

[B3TA_SCR1PT3R]

suggestion 1: ALWAYS POST SOURCE CODE!!!

[w0uter]

if you dont trust his exe just patch the bin manually.

[MHz]

suggestion 1: ALWAYS POST SOURCE CODE!!!

I do not think you can compile it with Aut2Exe B3TA_SCR1PT3R, as it is 14kb only.

[piccaso]

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...

[Valik]

Please put a disclaimer stating that you are modifying AutoIt in a way that is very dangerous (Do you know all the implications of changing the subsystem in this manner?). Also please state that once this modification is made, people are no longer using standard AutoIt and are not entitled to general support requests (I don't have a problem if you provide support).

[jftuga]

Also please state that once this modification is made, people are no longer using standard AutoIt and are not entitled to general support requests (I don't have a problem if you provide support).

Just exactly what kind of support are people "entitled to" when they use the standard, unpatched version? AFAICT, no one is obligated to answer questions in the forums and participation is completely voluntary.

That said, it would be nice when posting a question to mention that you have a patched version of the AutoIt binary.

-John

[Klaatu]

All piccaso seems to be doing is responding to a need in the AutoIt community that the developers appear not to be interested in pursuing. I know I don't know all the implications of making this change as he did, but appreciate it anyway. There are more than a few, I'm sure, that would want to see something like this incorporated into the current AutoIt beta, but if a hack is all we have so be it.

Edited October 27, 2005 by Klaatu

[Valik]

Just exactly what kind of support are people "entitled to" when they use the standard, unpatched version? AFAICT, no one is obligated to answer questions in the forums and participation is completely voluntary.

People are allowed to ask a question. Nobody has to answer it but somebody can choose.

That said, it would be nice when posting a question to mention that you have a patched version of the AutoIt binary.

What would be nice is if they didn't post at all. The moment you change a single byte in the AutoIt binaries, anything may go wrong. Do you hack your explorer.exe and then call Microsoft asking them why it crashes all the time and what are they going to do about it? Its the same thing here. If you change the binary from what we distribute, it's unreasonable to ask questions about it because the problem that is being experienced may stem from a combination of hardware and software issues as well as being an unwanted side effect of the modification.

All piccaso seems to be doing is responding to a need in the AutoIt community that the developers appear not to be interested in pursuing. I know I don't know all the implications of making this change as he did, but appreciate it anyway. There are more than a few, I'm sure, that would want to see something like this incorporated into the current AutoIt beta, but if a hack is all we have so be it.

Nobody said he shouldn't post it. What I did say is that there needs to be a warning that it is not safe and anybody using it accepts full responsibility for the modification.

Also, let me remind everybody that AutoIt was designed from the beginning to be a Windows application and not a DOS application. There is a fundamental difference and it's not really any less subtle than the difference between Mac and Windows or Linux and Windows. If AutoIt does not meet the requirement for being a console application, then there are several options including find a language which is console-centric.

A more interesting approach would be to look for a thin wrapper which is built as a console application and can read/write from the standard streams of an application. This application could be used to forward the command line/stdin to the child process (A GUI subsystem application) and it would also dynamically redirect the output to its own stdout/stderr streams which are connected to a console. I'm sure such a tool already exists, it's really trivial to write. It should be doable in less than 300 lines of C++.

[piccaso]

come on Valik.

I just wanted to share what i did because i found it usefull.

but your right a warning was missing.

btw: would a wrapper make a difference?

pretty much the same for me...

[Valik]

Well, you obviously don't care to concern yourself with the potential risks involved with changing the subsystem of a binary compiled for one subsystem but now being forced to run under another. So perhaps a wrapper doesn't sound like a big deal to you. Perhaps I am jaded because I understand the system more. However, the advantage that I see to a wrapper is that you do business as usual (If you call writing to std streams business as usual from a GUI subsystem-application) to write a script/program and make calls to the std streams. The wrapper which is a properly compiled CUI application will trap the data going to these streams and forward it out to the console. The wrapper is more akin to a proxy than anything since it connects two disjoint entities and allows them to communicate when they otherwise can't. Its a less hack-ish approach and ensures that all applications involved will have genuine bugs and mistakes and not strangeness resulting from having the binary hacked.

Disclaimer: I am not slamming you for your preference so don't attempt to misconstrue my words. I'm merely pointing out that given a choice between altering a single byte and potentially introducing unknown bugs, I'd rather spend an hour searching the web or writing a simple program which will serve as a proxy/wrapper so I don't have to modify anything to make things work. There are enough beginner C++ people on this forum that if such an application can't be found by our good friend Google, one of them should be able to write one as a good learning exercise.

[piccaso]

i do understand your point.

maybe i could write a wrapper.

but i cant put the result together in one exe.

and all binders i know have gui model

afer all i dont have that kind of time so if anybody likes to write a wrapper...

i just have to be happy with the hack.

many people use that kind of hack, aslong as it works i dont have a problem with it.

about the disclaimer:

yes it reflects what you say, but its still true?

or did i miss the point here, i dont know the meaning of 'misconstrue' because engish in not my native language...

[Valik]

I said it would take 300 lines or less to write a wrapper; it took 155.

Included in the archive below is the C++ source to the proxy (aka stub) as well as the Visual C++ 7.1 project files. Also included is the test AutoIt script I used. I also compiled the test script and compiled the project (The stub is a massive 2.5 KB because of how I linked it).

To use stub.exe, you have to pass it the path of a file to run (In fact, you can pass a complete command line, but the first argument must be a path to an executable). For example, to run the test script, open the Release directory in a console window and type:

stub.exe ..\Test.exe

At this point, the stub will launch Test.exe. You can type into the console and this will be forwarded to the AutoIt script (Upon pressing Enter). AutoIt will then spit the text back to prove that it works. Type "Exit" to exit the AutoIt script which in turn exits stub.exe.

Stub.zip

[piccaso]

@Valik

wow

thanks

test.au3 -> damn its easy to get console input, i taught the keyboard is handled 'special' and didnt even try it out...

there you have it, knowlege is power

Edited October 28, 2005 by piccaso

[Klaatu]

I said it would take 300 lines or less to write a wrapper; it took 155.

Wow. This looks really good Valik. Thanks a lot, and I mean a lot! It might have been trivial for you, but many of us don't have your skills either. This will come in so handy. Many things I do are through the command line and command files I write, and to now be able to use AutoIt in a new way to assist in that will be invaluable.

Thanks again.

[piccaso]

maybe a dumb idea...

but cant the autoitsc.bin be compiled as console app ?

i still cant stuff the stub and a compiled autoit exe into one exe but i am still trying ...

[Valik]

maybe a dumb idea...

but cant the autoitsc.bin be compiled as console app ?

i still cant stuff the stub and a compiled autoit exe into one exe but i am still trying ...

AutoIt is a Windows application. Personally, I don't even want to see AutoItSC.bin anymore (it's not really necessary with some minor modifications to AutoIt). The last thing I want to see is two copies of a file I don't think we need.

[themax90]

I've always tried to use C++ but this will come in handy, thank you very much for creating it. Hopefully autoit in the future will have console functions like Console window create, If ConsoleFunc($func) IsTyped Then

ETC

[Valik]

Its already possible to use the Windows API Console functions via DllCall().

[layer]

Yea, a while ago I wanted to make simple applications that _looked_ like console applications. I don't know how far I can get, but this is from like a month ago and I've never worked on it since, because I've been kinda busy...

[Needs latest BETA; or BETA that started supporting DllStructs with the latest syntax]

Func _ConsoleCreate($title="")
    Local $call, $struct, $struct
    $call = DllCall("kernel32.dll", "int", "AllocConsole")
    $struct = DllStructCreate("dword")
    DlLStructSetData($struct, 1, "AutoIt3.exe")
    DllCall("kernel32.dll", "int", "AttachConsole", "int", DllStructGetData($struct, 1))
    _ConsoleSetTitle($title)
    DlLStructDelete($struct)
    Return $call[0]
EndFunc

Func _ConsoleDelete()
    Local $call = DllCall("kernel32.dll", "int", "FreeConsole")
    Return $call[0]
EndFunc

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

;Func _ConsoleGetScrBuffhWnd()
;    Local $call = DllCall("kernel32.lib", "hwnd", "CreateConsoleScreenBuffer", "

;Func _ConsoleWriteData($scrBuffhWnd, $szData)
    



MsgBox(0, "create", _ConsoleCreate("AUTOIT APP"))
Sleep(2000)
MsgBox(0, "settitle", _ConsoleSetTitle("test"))
Sleep(2000)
MsgBox(0, "del", _ConsoleDelete())

Some of the structs like one of them in _ConsoleCreate may not be necessary because it worked without them, but like I said, this isn't close to done, nor is it intended to make 'real' console applications.

Edited October 30, 2005 by layer