Editbin to make an AutoIt3 exe a console app.

[Jos]

Somebody (I lost the EMail so don't remember the name) sent me an Email a while ago to ask if I could support the EditBin program that comes with the MASM32 package from Microsoft.

I was wondering if anybody has played with it and knows the PRO's and Con when doing this.

I played a bit with it and when I compiled this script called test.au3 :

ConsoleWrite("test" & @crlf)
ConsoleWrite("test" & @crlf)
ConsoleWrite("test" & @crlf)

..and then ran it from the CMD prompt it obviously didn;t display anything.

Then did this command: editbin.exe /subsystem:console test.exe

After that ran it again from the commandprompt and this time it did display the consolewrites.

I have seen many people asking for Console app support and this looks too easy to be true ...

[BrettF]

Somebody (I lost the EMail so don't remember the name) sent me an Email a while ago to ask if I could support the EditBin program that comes with the MASM32 package from Microsoft.

I was wondering if anybody has played with it and knows the PRO's and Con when doing this.

I played a bit with it and when I compiled this script called test.au3 :

ConsoleWrite("test" & @crlf)
ConsoleWrite("test" & @crlf)
ConsoleWrite("test" & @crlf)

..and then ran it from the CMD prompt it obviously didn;t display anything.

Then did this command: editbin.exe /subsystem:console test.exe

After that ran it again from the commandprompt and this time it did display the consolewrites.

I have seen many people asking for Console app support and this looks too easy to be true ...

Yes..... Yes it does Great Job JdeB! Would it maybe be posible to make a simple script, to parse every line of code, and create a new script, having the function of the other script, but doing a console write on every line?? I might just go do that

[Jon]

Console support is only a linker switch after all, so it could be that easy.

[Jos]

Console support is only a linker switch after all, so it could be that easy.

Yea I know but was wondering if anybody knew the implications of doing this.

I have seen many people asking for Console app support and when its this easy to safely change it, I could add support for it in the wrapper, but think its important to understand all implications first and warn about it when supporting it.

(guess I am to lazy to test and search for it myself at this moment )

[steve8tch]

JdeB - just tried this on an application that does some work and displays a debug screen. Very pleased so far. (This will allow this appilication to survive a logoff - at the moment as a windows app - this application will close when a user logs off)

I had no problem running editbin.exe /subsystem:console test.exe on my works laptop (this has Visual Studio 6 installed), however, when I copied editbin.exe to my home PC I could not run editbin.exe without error

Error message said something like "linker error" - I will retest and post full error message this evening.

Good find

[Richard Robertson]

I don't understand the want for console applications anymore. Something I do find amusing is that Microsoft had winipcfg GUI in 9x systems, but now there is ipconfig CUI in NT systems. What's up with that?

[Jos]

JdeB - just tried this on an application that does some work and displays a debug screen. Very pleased so far. (This will allow this appilication to survive a logoff - at the moment as a windows app - this application will close when a user logs off)

I had no problem running editbin.exe /subsystem:console test.exe on my works laptop (this has Visual Studio 6 installed), however, when I copied editbin.exe to my home PC I could not run editbin.exe without error

Error message said something like "linker error" - I will retest and post full error message this evening.

Good find

You need these files as well:

link.exe

mspdb50.dll

Not sure any others are needed yet, need to test some on a clean PC...

[Siao]

So basically this is a 1 byte change to the PE header. No need for M$ linkers and dlls, one could even write a simple Autoit script to do it...

[Jos]

So basically this is a 1 byte change to the PE header. No need for M$ linkers and dlls, one could even write a simple Autoit script to do it...

True and it was done before but it needs to be "fools proof" ... (or full proof if you like) ...

[Siao]

You mean Autoit is not reliable?

[GaryFrost]

You mean Autoit is not reliable?

No, the users are not reliable.....

[Jos]

If I remember correctly, the script that changed an AutoIt3 EXE into a consoleapp only worked on a particular version of AutoIt3 ... and you don't want to feed the mouths that tried to make it work anyways ..

Edited June 18, 2007 by JdeB

[Siao]

No, the users are not reliable.....

But that has nothing to do with the tool being used, whether it's editbin+linker from VS6, Autoit script (as a part of AutoIt3Wrapper, lets say) or some small application coded in any other language.

Just don't add those 600kb of worthless ballast to Autoit package, pretty plz.

If I remember correctly, the script that changed an AutoIt3 EXE into a consoleapp only worked on a particular version of AutoIt3 ... and you don't want to feed the months that tried to make it work anyways ..

Ok, here's example which works on any program:

$openpath = FileOpenDialog( "Select executable to patch into Console...", @ScriptDir, "Exe (*.exe)", 1)
$hRead = FileOpen($openpath, 16)
$bR = FileRead($hRead)
FileClose($hRead)
If BinaryMid($bR, 1, 2) <> "MZ" Then
    MsgBox(0, "Error", "File is not an executable.")
    Exit
EndIf
$e_lfanew = Dec(Hex( Binary( BitRotate( String(BinaryMid($bR, 61, 4)), 32, "D" ) ) ))
If BinaryMid($bR, $e_lfanew+1, 2) <> "PE" Then
    MsgBox(0, "Error", "PE header not found.")
    Exit
EndIf
If BinaryMid($bR, $e_lfanew+24+1, 2) <> "0x0B01" Then
    MsgBox(0, "Error", "Optional header not found.")
    Exit
EndIf
$new = BinaryMid($bR, 1, $e_lfanew+24+68) & Binary("0x0300") & BinaryMid($bR, $e_lfanew+24+68+2+1)
$savepath = FileSaveDialog( "Save Console executable as...", "", "Exe (*.exe)", 18)
$hWrite = FileOpen($savepath, 18)
FileWrite($hWrite, $new)
FileClose($hWrite)

Nevermind my lolsome code, I'm sure you can optimize it, but what's important is that the logic of locating the Subsystem value is about as generic and "fool proof" as it gets, provided that the executable is valid to begin with (it's possible to get more paranoic, but come on...).

PE header explained here.

Edited June 18, 2007 by Siao

[FuryCell]

This is awesome. I've always wanted console output in autoit. Thanks for sharing. Where would we be without JDEB.

P.S.

Is this the script you were talking about?

http://www.autoitscript.com/forum/index.php?showtopic=17380

Edited June 18, 2007 by SolidSnake

[flyingboz]

Are there any implications for signed applications here? Or is this just going to be a script I run as a post-compile

command on my console interactive programs?

... I'm starting to smell a post-processor directive, if this becomes the de facto methodology for creating console mode applications.

I'd still _really_ love to be able to select the option to choose the 'standard windows app','true console mode', 'service mode' natively at

compile time, but this would be a great step in the right direction.

[flyingboz]

I don't understand the want for console applications anymore.

Some things just don't lend themselves well to a windows environment.

Do you have any windows services running on your machine? They're not windows apps -- they may have windows front ends, but they aren't windows applications.

Need an application running without a user logged on?

Desire a small, quick application to act as a logger or server?

Want a utility that does conversions, accepts console input, and writes messages / progress directly to the screen w/o bothering to code a gui?

CUI apps are becoming more, not less common -- netsh , ipconfig , monad (powershell) , all are finally giving windows users the ability to utilize /live from a command line.

Heck, even mac users can have a command line now that they've gone *nix based -- used to be the only way you could get to a console prompt on a mac was to

purchase the developers kit....

Correspondingly, the need for admins / technicians who understand what's really happening when you click an icon is increasing, rather than decreasing.

Edited June 19, 2007 by flyingboz

[Valik]

Doing this is safe, I guess. At least for compiled scripts. AutoIt3.exe is signed, obviously, and changing it will break the signature. Having looked closely at all the startup code MSVC compiles into an application and also comparing executables compiled with and without the switch, the binaries are identical save for the single byte (Technically not true, there's a timestamp which is different too, but that's easily ignored if you're expecting that difference). My previous comments and reservations about switching the flag were based on me having never taken the time to investigate things completely.

Ideally, this should just be implemented in Aut2Exe as an option. It's a rather trivial thing to do as it just requires reading a little bit of the PE Header and re-saving with 1 byte changed. I've known this for well over 6 months now. The problem during that time for me has always been testing. You can't change AutoIt3.exe from one subsystem to the other because it's signed. AutoIt3.exe is a GUI application. That means there would be no way for people to test the CUI version without compiling the script with that flag set in Aut2Exe, then running that. This is inconsistent which is why I never pursued implementing the flag in Aut2Exe. My preference is for as much to be common between non-compiled and compiled as possible.

I'm sure Jon is familiar enough with the PE Format by now to effect this change in Aut2Exe with little effort. However, it's imperative that it be documented that running a script non-compiled will *ALWAYS* run in GUI mode and that only compiled scripts have the option of being compiled as either CUI or GUI applications.

[piccaso]

Valik, i didn't test this with the current version but back there when you wrote this stub there was a different behaviour between your stub and running a modified version.

The way you implemented the user input feature in the test script which was in the archive you posted only worked with your stub.

Back there i didn't find a way to get user input without an external tool.

ConsoleRead always hung using the changed subsytem way.

And i remember some console related api's behaving different too, but i don't know which one any more.

Edit:

ConsoleRead still behaves that way.

For reference the topic is here.

Edited June 19, 2007 by piccaso

[Zacharot]

I decided to check overhead, and concluded that a For loop is 0.0008~ milliseconds faster on each iteration when run in a console. that number scales up into a still unnoticeable amount when doing very large loops, but I like the idea. So there is a gain to be had when running in console!

Edited June 20, 2007 by Zacharot

[Richard Robertson]

How did you measure that 0.0008 milliseconds?