Editbin to make an AutoIt3 exe a console app.

[Valik]

Any perceived gain is just variance in your system. It's the same code being executed the same way so don't jump to false conclusions.

As for why ConsoleRead() doesn't work, that could be an implementation issue since AutoIt wasn't designed to be run as CUI. Or not, I don't know, haven't looked at that code in a long time.

[Zacharot]

I created a script that ran a loop 65536 times, which takes about 1000ms~, I then ran this loop 256 times, and checked the times, each was no more than 2ms higher or lower than the average, I checked for any that were outside the range (none were), and got an average per loop, I then subtracted the difference between gui and cui modes, this came to be 1066 on gui, and 1011 on cui, gives me 55ms, or .0008ms for each iteration. It's not flutter since it's a sustained difference with scatter within the ms threshold. if you perform it yourself, you will see that you get very level results without much difference each time you run your loops. PS, turn off all your background crap, any interruption will give you the scatter valik talked about, but in a controlled enviroment, you will get good results.

[Zacharot]

I apologize for the double post, but I feel this stands on it's own. Valik, I revised my test, and would like to show you my results, and get your thoughts, because Console is something I have wanted for a long time, and feel that this speedup is a great one. to test this, I revised my code, and present it here for review.

Local $time, $nTime
$time = TimerInit()
For $i = 1 to 10000000
    
Next
$nTime = TimerDiff($time)
ConsoleWrite(@HOUR&":"&@MIN&":"&@SEC&" : "&$nTime&@LF)

times for GUI:

12:22:41 : 27676.2706779016

12:23:25 : 27551.7020873597

12:24:04 : 27753.5053327992

27.6-27.8 seconds

times for CUI:

12:24:47 : 22074.4949219817

12:25:30 : 22183.1640101845

12:26:04 : 22066.3586946501

22.1-22.2 seconds

0.000560178 ms per iteration difference.

I also apologize for making a fuss about this, but I think my numbers support my numbers last night. I wasnt seeing smoke and mirrors, and I believe this deserves deeper investigation.

-

Edit: added this

But what about it DOING something you ask?

Local $time, $nTime, $r,$g,$b,$a, $px[307201][5]
$time = TimerInit()
For $i = 1 to 960
    For $j = 1 to 240
        $r = Random(0,256,1)
        $g = Random(0,256,1)
        $b = Random(0,256,1)
        $a = Random(0,256,1)
        $px[$i*$j][1] = $r
        $px[$i*$j][2] = $g
        $px[$i*$j][3] = $b
        $px[$i*$j][4] = $a
    Next
Next
$nTime = TimerDiff($time)
ConsoleWrite(@HOUR&":"&@MIN&":"&@SEC&" : "&$nTime&@LF)

GUI:

12:54:13 : 35035.7355374117

12:54:57 : 35059.8785432566

12:55:43 : 35037.3807181134

CUI:

12:56:25 : 30144.2889684893

12:57:08 : 30129.929046868

12:57:53 : 30107.197393189

-

edit: added yet more:

I tried a while loop, to see if it was just a 'feature' related to the For loop.

Local $c, $time, $nTime
$time = TimerInit()
While 1
    $c+=1
    $nTime = TimerDiff($time)
    If $nTime>=1000 Then ExitLoop
WEnd
ConsoleWrite($c&@LF)
ConsoleWrite($nTime&@LF)

GUI:

19913

1000.0243047582

CUI:

27518

1000.00335238044

Edited June 21, 2007 by Zacharot

[Richard Robertson]

You declared an array with 307201 elements? I didn't think AutoIt supported that high a subscript count.

[Jos]

You declared an array with 307201 elements? I didn't think AutoIt supported that high a subscript count.

mmmm

15. What are the current technical limits of AutoIt v3?

Here are details of the current technical limits of AutoIt. Please note that some of the limits are theoretical and you may run into performance or memory related problems before you reach the actual limit.

Maximum length of a single script line: 4,095

Maximum string length: 2,147,483,647 characters

Number range (floating point): 1.7E308 to 1.7E+308 with 15-digit precision

Number range (integers): 64-bit signed integer

Hexadecimal numbers: 32-bit signed integer (0x80000000 to 0x7FFFFFFF)

Arrays: A maximum of 64 dimensions and/or a total of 16 million elements

Maximum depth of recursive function calls: 384 levels

Maximum number of variables in use at one time: No limit

Maximum number of user defined functions: No limit

Maximum number of GUI windows: 1024

Maximum number of GUI controls per window: 4096

[piccaso]

0.000560178 ms per iteration difference.

if it makes you happy...

As for why ConsoleRead() doesn't work, that could be an implementation issue since AutoIt wasn't designed to be run as CUI. Or not, I don't know, haven't looked at that code in a long time.

Your probably right, because this way it works just fine:

Func _InputLine()
   Local $aTmp
   If @Unicode Then
      $aTmp = Ø[
    ][ÝÛÝÜ  ][ÝË  ][ÝÝÜÝÙXÛ ][ÝË  ][Ý×ÙÙ]ÜÉ][ÝË   ]÷C·w7G"gV÷C²ÂgV÷C²gV÷C²¢VÇ6P b33c¶F×ÒFÆÄ6ÆÂgV÷C¶×7f7'BæFÆÅÕ½Ðì°ÅÕ½ÐíÍÑÈé°ÅÕ½Ðì°ÅÕ½ÐíÑÌÅÕ½Ðì°ÅÕ½ÐíÍÑÈÅÕ½Ðì°ÅÕ½ÐìÅÕ½Ðì¤   EndIf
   If Not @error Then Return $aTmp[0]
   Return ""
[[ÂÛÛÛÛUÜ]J   ][ÝÒKÚ]È[Ý[YOÉ][ÝÊBÌÍÜÓ[YHHÒ[][J
BÛÛÛÛUÜ]JÔ    [È ][ÝÒ[È   ][Ý2fײb33c·4æÖRfײgV÷C²ÂB÷W"VçFW"¶Wb333²gV÷C²fײ5"¥å¹ÁÕÑ1¥¹ ¤(

I noticed a funny feature of scite.

if you run that code interpreted and put focus on scite's output window

(preferably before hitting F5) you can type into the window and scite forwards this

to autoit

[Zacharot]

if it makes you happy...

If I said 10-20% would you reply differently? That's the translation in simpler terms. Edited June 21, 2007 by Zacharot

[Richard Robertson]

Oh, I was probably thinking 64 when I posted that.

[piccaso]

If I said 10-20% would you reply differently? That's the translation in simpler terms.

i would have not replied because i would think that your just mistaking

anyway you made me curios and i tried this on a compiler that supports both subsytems (freebasic to be specific)

#Include "windows.bi"
#Define _RandomInt(nlow,nHigh) Int(Rnd * (nHigh - 1)) + nlow

Dim As LongInt nTimerStart,nTimerEnd,nFrequency
Dim As Double nSum,nCnt
Dim As Integer r,g,b,a,i,j,n
ReDim px(307201,5) As Integer

Randomize(0,3)
QueryPerformanceFrequency(@nFrequency)

For n = 1 To 10
    QueryPerformanceCounter(@nTimerStart)
    For i = 1 To 960
        For j = 1 To 240
            r = _RandomInt(0,2147483647)
            g = _RandomInt(0,2147483647)
            b = _RandomInt(0,2147483647)
            a = _RandomInt(0,2147483647)
            px(i*j,1) = r
            px(i*j,2) = g
            px(i*j,3) = b
            px(i*j,4) = a
        Next
    Next
    QueryPerformanceCounter(@nTimerEnd)
    nSum = (nTimerEnd - nTimerStart) / nFrequency * 1000
    nCnt += nSum
    Print nSum
Next
Print "-----"
Print nCnt

but everytime i run the test there is another winner

in that case gui won:

GUI
 70.83805343975281
 61.81930943737262
 62.84374131349096
 65.87317661881608
 61.92211579963375
 63.74804619022809
 66.3439068373215
 60.89656646305606
 65.06050349974647
 61.78327133755827
-----
 641.1286909369766

CUI
 73.9887332049185
 67.6633482747109
 64.50400819098516
 61.5893919478593
 65.95726551838293
 67.63792604926046
 61.49720145996209
 66.92833865756681
 60.13473779488734
 67.09623709158566
-----
 656.997188190119

so i still beleve its just system variance...

[Valik]

I tested using the following code which is only a slight modification of your code:

Local $c, $time, $nTime
$time = TimerInit()
While 1
    $c+=1
    $nTime = TimerDiff($time)
    If $nTime>=1000 Then ExitLoop
WEnd
MsgBox(4096, "", $c & @CRLF & $nTime)

Now, explanation time. Your code used ConsoleWrite(). This is a very clear indicator of a fundamental logic flaw in your test(s). You are running the GUI test non-compiled, presumably from SciTE. I know this because otherwise you wouldn't see the output. However, you are running the CUI test compiled, which I know because AutoIt3.exe is signed and changing the subsystem would break the signature. So essentially, you have failed to isolate all the variables in the two tests and are comparing nothing more than compiled versus non-compiled performance.

Here are my results from the script I posted above:

GUI Compiled: ~70,000 iterations in 1 second

CUI Compiled: ~70,000 iterations in 1 second

GUI NON-Compiled: ~67,000 iterations in 1 second

There is no performance difference between CUI and GUI AutoIt.

Edited June 27, 2007 by Valik
Missing words confusing sentences make.

[FuryCell]

Are there any plans of this being added to autoit3wrapper? That would make a useful tool even better.

Edited July 5, 2007 by P5ych0Gigabyte

[Jos]

Are there any plans of this being added to autoit3wrapper? That would make a useful tool even better.

reluctant to add the 600Kb to the installer at this moment just to set one byte and haven't found a simple/fast program yet that is reliable enough to include...

Didn't have to time to see if I can translate the posted script into a fast program.

maybe later unless somebody else has a good/fast/small program for it ...

Till then you can use it as a run after program ...right ?

Edited July 5, 2007 by JdeB

[FuryCell]

reluctant to add the 600Kb to the installer at this moment just to set one byte and haven't found a simple/fast program yet that is reliable enough to include...

Didn't have to time to see if I can translate the posted script into a fast program.

maybe later unless somebody else has a good/fast/small program for it ...

Till then you can use it as a run after program ...right ?

Run after should work for now. Thanks for the idea.

[piccaso]

here is another approach using windows image helper:

it isn't necessary but it also corrects the checksum...

expandcollapse popup

Global Const $gs_SetPeSubsystem_IMAGE_NT_HEADERS = "DWORD Signature;SHORT Machine;SHORT NumberOfSections;DWORD TimeDateStamp;DWORD PointerToSymbolTable;DWORD NumberOfSymbols;SHORT SizeOfOptionalHeader;SHORT Characteristics;SHORT Magic;BYTE MajorLinkerVersion;BYTE MinorLinkerVersion;DWORD SizeOfCode;DWORD SizeOfInitializedData;DWORD SizeOfUninitializedData;DWORD AddressOfEntryPoint;DWORD BaseOfCode;DWORD BaseOfData;DWORD ImageBase;DWORD SectionAlignment;DWORD FileAlignment;SHORT MajorOperatingSystemVersion;SHORT MinorOperatingSystemVersion;SHORT MajorImageVersion;SHORT MinorImageVersion;SHORT MajorSubsystemVersion;SHORT MinorSubsystemVersion;DWORD Win32VersionValue;DWORD SizeOfImage;DWORD SizeOfHeaders;DWORD CheckSum;SHORT Subsystem;SHORT DllCharacteristics;DWORD SizeOfStackReserve;DWORD SizeOfStackCommit;DWORD SizeOfHeapReserve;DWORD SizeOfHeapCommit;DWORD LoaderFlags;DWORD NumberOfRvaAndSizes"
Global Const $gs_SetPeSubsystem_LOADED_IMAGE = "PTR ModuleName;PTR hFile;PTR MappedAddress;PTR FileHeader;PTR LastRvaSection;UINT NumberOfSections;PTR Sections;UINT Characteristics;BYTE fSystemImage;BYTE fDOSImage;BYTE fReadOnly;UBYTE Version;BYTE Links[8];UINT SizeOfImage"
Global Const $gi_SetPeSubsystem_dwSignature = 17744 ; "PE"
Global Const $IMAGE_SUBSYSTEM_WINDOWS_GUI = 2
Global Const $IMAGE_SUBSYSTEM_WINDOWS_CUI = 3

;===============================================================================
;
; Function Name:    _SetExeSubsystem
; Description:      Changes the subsystem byte in specified executeable
; Parameter(s):     $sExeFile, Relative or absolute path to exe file
;                   $nNewSubSystem, New Value for Subsystem
; Requirement(s):   
; Return Value(s):  True on Success or sets @error to:
;                       1 - Error calling MapAndLoad
;                       2 - No PE file
;                       3 - Error calling UnMapAndLoad
; Author(s):        piccaso
;
;===============================================================================
;

Func _SetExeSubsystem($sExeFile, $nNewSubsytem)
    Local $aTmp, $LOADED_IMAGE, $IMAGE_NT_HEADERS, $nOldStubsystem
    $LOADED_IMAGE = DllStructCreate($gs_SetPeSubsystem_LOADED_IMAGE)
    $aTmp = DllCall("imagehlp.dll", "int", "MapAndLoad", "str", $sExeFile, "str", "", "ptr", DllStructGetPtr($LOADED_IMAGE), "int", 0, "int", 0)
    If @error Then Return SetError(1, 0, False)
    If $aTmp[0] = 0 Then Return SetError(1, 0, False)
    $IMAGE_NT_HEADERS = DllStructCreate($gs_SetPeSubsystem_IMAGE_NT_HEADERS, DllStructGetData($LOADED_IMAGE, "FileHeader"))
    If DllStructGetData($IMAGE_NT_HEADERS, "Signature") = $gi_SetPeSubsystem_dwSignature Then
        $nOldStubsystem = DllStructGetData($IMAGE_NT_HEADERS, "Subsystem")
        DllStructSetData($IMAGE_NT_HEADERS, "Subsystem", $nNewSubsytem)
    Else
        DllCall("imagehlp.dll", "int", "UnMapAndLoad", "ptr", DllStructGetPtr($LOADED_IMAGE))
        Return SetError(2, 0, False)
    EndIf
    $aTmp = DllCall("imagehlp.dll", "int", "UnMapAndLoad", "ptr", DllStructGetPtr($LOADED_IMAGE))
    If Not @error Then
        If $aTmp[0] <> 0 Then Return SetError(0, $nOldStubsystem, True)
    EndIf
    Return SetError(3, 0, False)
EndFunc   ;==>_SetPeSubsystem

;------------
;  Example
;------------

_SetExeSubsystem("test.exe", $IMAGE_SUBSYSTEM_WINDOWS_CUI)
Switch @error
    Case 1
        ConsoleWrite("Error calling MapAndLoad (imagehlp not present, exe not found)" & @CRLF)
    Case 2
        ConsoleWrite("Not a PE file" & @CRLF)
    Case 3
        ConsoleWrite("Error calling UnMapAndLoad" & @CRLF)
    Case 0
        Switch @extended
         Case $IMAGE_SUBSYSTEM_WINDOWS_CUI
            ConsoleWrite("Changed, old subsytem was: CUI" & @CRLF)
         Case $IMAGE_SUBSYSTEM_WINDOWS_GUI
            ConsoleWrite("Changed, old subsytem was: GUI" & @CRLF)
         Case Else
            ConsoleWrite("Changed, old subsytem value is unknown")
      EndSwitch
      ConsoleWrite(@CRLF)
EndSwitch

edit:

i translated LOADED_IMAGE wrong, fixed that.

there goes my reliability

Edited July 7, 2007 by piccaso

[piccaso]

I'm currently playing with tcc and wanted to practise a little c so i wrote a little

commandline tool called MakeCUI which does the same thing as the function i posted above.

compiled with gcc its 35kb but with tcc its only 1,5kb

and since i'm still learning c i wouldn't rely on it blindly

but to use it anyway put it somewhere in %PATH% and use it from scite this way:

#AutoIt3Wrapper_run_after=MakeCUI "%out%"
ConsoleWrite("hello" & @CRLF)

MakeCUI.zip

Edited July 12, 2007 by piccaso

[Zedna]

I'm currently playing with tcc and wanted to practise a little c so i wrote a little

commandline tool called MakeCUI which does the same thing as the function i posted above.

compiled with gcc its 35kb but with tcc its only 1,5kb

and since i'm still learning c i wouldn't rely on it blindly

but to use it anyway put it somewhere in %PATH% and use it from scite this way:

#AutoIt3Wrapper_run_after="MakeCUI %out%"
ConsoleWrite("hello" & @CRLF)oÝ÷ Ûú®¢×¢,½êòRwè®Û§j×¥(­v¬mÂä÷§Â+a¶¬rëyË^vÇ+ZºÚ"µÍÐÛÛ[ÕÙU[ØÛÛ[Ü[ØYSXZÙPÕRH   ][ÝÉ[Ý]  I][ÝÂÛÛÛÛUÜ]J    ][ÝÚ[É][ÝÈ [ÈÔ

makecui says: No PE Signature.

[piccaso]

must have got corrupted somehow.

I recompiled the c code which was in the archive (with the same compiler) and it worked but the binary in the archive didn't...

anyway i uploaded a updated version.

[Zedna]

must have got corrupted somehow.

I recompiled the c code which was in the archive (with the same compiler) and it worked but the binary in the archive didn't...

anyway i uploaded a updated version.

Thanks piccaso!

Now it works good even on UPX compressed EXE.

[kamyers1]

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

Guys, this may be real old news by now, but just FWIW, you can run editbin.exe on AutoIt3.exe, producing a new version of AutoIt3.exe that allows writes to a console window directly from uncompiled scripts.

It is common to use this technique with the GIMP and other *nix based software that runs under Windows. Typically, console mode is enabled while debugging an application, and turned off for the production release. But it can always be turned back on by the user by using editbin, if desired.

I believe that the only disadvantage to turning on console mode is that any console mode app *must* have a console window in order to run. Because of this, a console mode app will actually start its own console window if the app wasn't started directly from console window. This can be confusing for users of a GUI app who aren't expecting to see the extra console window and try to close it, etc.

Hope that makes sense and some of it may be useful.

Kevin M.

[PsaltyDS]

Guys, this may be real old news by now, but just FWIW, you can run editbin.exe on AutoIt3.exe, producing a new version of AutoIt3.exe that allows writes to a console window directly from uncompiled scripts.

It is common to use this technique with the GIMP and other *nix based software that runs under Windows. Typically, console mode is enabled while debugging an application, and turned off for the production release. But it can always be turned back on by the user by using editbin, if desired.

I believe that the only disadvantage to turning on console mode is that any console mode app *must* have a console window in order to run. Because of this, a console mode app will actually start its own console window if the app wasn't started directly from console window. This can be confusing for users of a GUI app who aren't expecting to see the extra console window and try to close it, etc.

Hope that makes sense and some of it may be useful.

Kevin M.

That's very interesting, but EDITBIN.EXE with the /SUBSYSTEM:Console switch appears to be a full blown VisualStudio component. Any hope for those of us without such heafty budgets?