A3X on 64 bit systems ???

[storme]

G'day All

I'm changing over to using A3X instead of EXE to avoid the false positive issue with Anti Virus products.

One future concern is what if a script should be run with the 64bit interpreter for technical reasons but is compiled to A3X instead of EXE.

Does it run under the 32Bit interpreter or the 64Bit interpreter?

If not... could something be added to the A3X files so that they are tagged as 64bit or 32bit then at least a switcher app could be created to decide on which interpreter to use.

This will enable seamless running of A3X files as we have with EXE.

Thanks guys and keep up the great work!

John

I originally posted this under general help but we haven't got a good solution to the situation.

'?do=embed' frameborder='0' data-embedContent>>

So I thought I'd ask the guys that have all the answers.

 

[trancexx]

a3x is compressed/encoded au3 readable by AutoIt executable, nothing more. It can be associated with any kind of interpretter.

MHz pretty much said the same thing in that other thread, so it seems you don't understand the concept fully.

But don't worry, you aren't the only one. I had one unrelated conversation with Jon recently and he had the same issues . Only I said nothing to him. Hopefully his reasons are different than yours .

[storme]

Hi trancexx

I understand the concept perfectly.

However, that reality doesn't match well with how the A3X "should" be able to be used.

I.E. A replacement (when run by the interpreter(s)) for an EXE that combines the script and a "selected" 32/64bit interpreter.

Coupled this with the fact that it wouldn't be difficult to allow the compiled A3X files to be checked and run under the "correct" interpreter.

As MHZ doesn't know the exact format of the A3X file "maybe" there is a undocumented flag that Jon added so these directives aren't just ignored for A3X files.

#AutoIt3Wrapper_Compile_Both=y
#AutoIt3Wrapper_UseX64=y

BTW I'd already "assumed" that the A3X was just a "compressed/encoded au3" but assumptions are  by there very essence based on incomplete information.  So as we all should do I went on a "fact" finding exercise.  MHZ isn't a developer so maybe there is something undocumented that does tell the difference between A3X files compiled with those directives.

Thanks for your observations

John

[Jos]

Those 2 Mentioned directives have no relation to AutoIt, only to autoit3wrapper.

Jos

Edited October 6, 2013 by Jos

[storme]

Those 2 Mentioned directives have no relation to AutoIt, only to autoit3wrapper.

Jos

Autoit3wrapper uses those directives to inform the "compiler" (term used loosely) Aut2Exe what to do with the AU3 file.

So I can only assume that Autoit3wrapper would run Aut2Exe with the "X64" option set when I enter "#AutoIt3Wrapper_UseX64=y".

No matter if I choose EXE or AU3 as the output file.

[trancexx]

Aut2Exe ignores bitness options when it's instructed to produce a3x. That's because a3x is not executable format. Period.

Speaking about Aut2Exe, beta version has some bugs as result of butchering after I left development, that no one noticed or cared about enough to report so I'm talking about stable version. Theoretically speaking, same thing should apply to beta.

[storme]

Aut2Exe ignores bitness options when it's instructed to produce a3x. That's because a3x is not executable format. Period.

Yes I understand that A3x is not executable in the strictest sense of the word.

However, that doesn't preclude the  "bitness options" being embedded in the a3x file.  But as you have seen the source I bow to your greater knowledge.

So now that the "status quo" has been set!

To the Developers (which is why I asked here)

Could something be added to the A3X files so that they are tagged as 64bit or 32bit then a switcher app could be created to decide which interpreter to use?

This is important to some operations (e.g. registry).

This will enable seamless running of A3X files as we have with EXE as expand it's use and convenience.

[Jos]

Could something be added to the A3X files so that they are tagged as 64bit or 32bit then a switcher app could be created to decide which interpreter to use?

This is important to some operations (e.g. registry).

This will enable seamless running of A3X files as we have with EXE as expand it's use and convenience.

 

I don't understand the question. The associate or Shelled Autoit3 program version dictates the 64 or 32 bit choice and the a3x is merely the script.

You as the developer of the script need to ensure that the script logic has the proper tests for x64/x86 to ensure things will work correctly.

.. or am I missing the point you are trying to make here?

Jos

Edited October 6, 2013 by Jos

[Mat]

Make another file extension called .a3x64 or something, that is associated with the 64 bit interpreter.

[storme]

I don't understand the question. The associate or Shelled Autoit3 program version dictates the 64 or 32 bit choice and the a3x is merely the script.

You as the developer of the script need to ensure that the script logic has the proper tests for x64/x86 to ensure things will work correctly.

.. or am I missing the point you are trying to make here?

Jos

The point is at compile time be it to EXE (with Shield) or A3X (script only) the developer chooses either 32 or 64 bit depending on their requirements.

So for EXE there story ends there, the right Type 32/64 of AutoIT is combined with the compiled script and all is well.

However, for a3x it will all depend on what is set up to run them on the clients computer AutoIT.exe or AutoIT_X64.exe and the developer has no control over what happens.

He could put some checks in to make sure if it's a 64bit app that it isn't run on the 32bit interpreter.

However, standard install is set to 32bit to run a3X ("C:Program Files (x86)AutoIt3AutoIt3.exe" "%1" %*) so that means that ALL a3x files that need 64bit architecture will fail.

Alternatively if its changed so that all A3X are run on the 64Bit interpreter that will potentially cause problems for any A3X that needs assumes 32bit architecture (the majority).

Hope that clears things up.

[storme]

Make another file extension called .a3x64 or something, that is associated with the 64 bit interpreter.

There are multiple work-arounds.

1. your extension idea isn't a bad idea

      #AutoIt3Wrapper_Outfile=test.a3x

      #AutoIt3Wrapper_Outfile_x64=test.a3x64

2. add _x64 into the file name (use a switcher to change to 64bit

      #AutoIt3Wrapper_Outfile=test.a3x

      #AutoIt3Wrapper_Outfile_x64=test_X64.a3x

3. use Fileinstall to put something in the a3x that could be used as a switch.

4. Add a function that would check @AutoItX64 then check @AutoItExe to ensure it was running on the right bit type.  If not it could use @AutoItExe (modified to preferred bit type) to rerun itself under the preferred version.

However they are workarounds and It'd be better to have a standard approach to the situation.

If nothing can be done to standardise handling of a3x 64bit scripts it I'll adopt your solution.  Thanks!

Come to think of it your approach would be an easy way to standardize it for Autoit.

- Add the a3x64 extension to the registry at AutoIt install

- Modify Aut2Exe so that it takes note of the 64bit switch and sets the extension to a3x64 if a3x is specified as the output file.

Thanks Mat!  A very elegant solution!

John

Edited October 6, 2013 by storme

[BrewManNH]

.a3x files aren't compiled so they have no "bitness" settings. When you compile a script to an .exe the script interpreter is added to the file, that interpreter is the part that determines whether you're running an x64 or an x86 program. (this is a simplified version of how it works)

There is absolutely nothing in the .a3x file that tells it to run under x64 or x86, YOU have to choose to use the AutoIt3.exe or AutoIt3_x64.exe interpreter to run when you run your a3x file.The workarounds are the only way for it to ever work the way you'd like it to.

[storme]

.a3x files aren't compiled so they have no "bitness" settings. When you compile a script to an .exe the script interpreter is added to the file, that interpreter is the part that determines whether you're running an x64 or an x86 program. (this is a simplified version of how it works)

Yes it's all been said before in this thread!

So let's move on to what CAN/COULD BE DONE!

 

There is absolutely nothing in the .a3x file that tells it to run under x64 or x86, YOU have to choose to use the AutoIt3.exe or AutoIt3_x64.exe interpreter to run when you run your a3x file.The workarounds are the only way for it to ever work the way you'd like it to.

NOT the ONLY WAY!

This is the "Developers" forum! A place for "possibility" thinking or am I wrong?

What does/did A3X stand for? There would have been some reasoning behind it at the time.

My assumption was it's a combination of AU3 and EXE ("AutoIT3 Executable") so shouldn't it be treated as such.

All that is needed is some form of "flag" to be added to the A3X file format to indicate the bittiness of the file.

This seems like the logical thing to do with "AutoIT3 Executable" files to support the users of the language.

Mats workaround could easily be added to the next release (As I've stated above) to solve the problem with no workaround needed in future.

So yes I'll give up now trying to improve the language and use Mats work around.

Just a shame that something that could be add/changed so easily needs a work-around by the users of the language when it could so easily be fixed/improved.

[guinness]

Just a shame that something that could be add/changed so easily needs a work-around by the users of the language when it could so easily be fixed/improved.

Don't presume something is "easy" to add please.

[Richard Robertson]

I don't see why it's so difficult to understand that the a3x format HAS NO BITNESS. It's still a script. It's just an au3 file but encoded.

If you want it to run as x32, you load it with an x32 AutoIt. And the same goes for x64. If it has things that only work in one bitness or another, they should be coded as such using the macros to check.

[MHz]

Here is a registry change for Windows 7+. Unsure if Vista supports this. I will give some basic examples of how it works. Bold items will be default items in the context menu. Explorer will run the bold items by default. The command prompt does not follow this switching. This idea uses a wildcard * and the suffix of the file name to determine what is shown and used as default by explorer.

Explaination:

A file named A.a3x will show in the context menu as

Open

"Open" is default so AutoIt3.exe is run.

A file named A_x86.a3x will show...

Open

Run *_x86.a3x

"Run *_x86.au3" is default so AutoIt3.exe is run.

A file named A_x64.a3x will show ...

Open

Run *_x64.a3x

"Run *_x64.a3x" is default so AutoIt3_x64.exe is run.

So, a recap. A file ending with _x64.a3x will use AutoIt3_x64.exe. A file ending with _x86.a3x will use AutoIt3.exe. Any other will use Open default which in this case is AutoIt3.exe as set. If you double click a file in explorer then it will follow the conditions mentioned above. The verb names showing in the context menu are fancy as to show what is selected.

The "AppliesTo" registry entries hides the entry unless the file name condition is true. The "DefaultAppliesTo" registry entries set the default if the file name condition is true.

AutoIt Script to add the registry entries:

expandcollapse popup

#RequireAdmin

Const $PROGRAMFILES = _ProgramFiles_x86()
If $PROGRAMFILES == '' Then Exit 1

Const $MAINKEY = 'HKLM\SOFTWARE\Classes\AutoIt3XScript'

; make a backup of the mainkey and then delete the main key
If Not FileExists(@ScriptDir & '\AutoIt3XScript_Backup.reg') Then
    RunWait('reg export ' & $MAINKEY & ' "' & @ScriptDir & '\AutoIt3XScript_Backup.reg"', '', @SW_HIDE)
EndIf
RegDelete($MAINKEY)

$key = $MAINKEY
RegWrite($key, '', 'REG_SZ', 'AutoIt v3 Compiled Script')

$key = $MAINKEY & '\DefaultIcon'
RegWrite($key, '', 'REG_SZ', $PROGRAMFILES & '\AutoIt3\Icons\au3script_v10.ico')

$key = $MAINKEY & '\Shell\Open\Command'
RegWrite($key, '', 'REG_SZ', '"' & $PROGRAMFILES & '\AutoIt3\AutoIt3.exe" "%1" %*')

$key = $MAINKEY & '\Shell\Run_x64'
RegWrite($key, '', 'REG_SZ', 'Run *_x64.a3x')
RegWrite($key, 'AppliesTo', 'REG_SZ', 'System.FileName:"*_x64.a3x"')
RegWrite($key, 'DefaultAppliesTo', 'REG_SZ', 'System.FileName:"*_x64.a3x"')
$key &= '\Command'
RegWrite($key, '', 'REG_SZ', '"' & $PROGRAMFILES & '\AutoIt3\AutoIt3_x64.exe" "%1" %*')

$key = $MAINKEY & '\Shell\Run_x86'
RegWrite($key, '', 'REG_SZ', 'Run *_x86.a3x')
RegWrite($key, 'AppliesTo', 'REG_SZ', 'System.FileName:"*_x86.a3x"')
RegWrite($key, 'DefaultAppliesTo', 'REG_SZ', 'System.FileName:"*_x86.a3x"')
$key &= '\Command'
RegWrite($key, '', 'REG_SZ', '"' & $PROGRAMFILES & '\AutoIt3\AutoIt3.exe" "%1" %*')

Exit

Func _ProgramFiles_x86()
    ; return the path to Program Files x86
    Local $path
    $path = EnvGet('ProgramFiles(x86)')
    If $path == '' Then $path = EnvGet('ProgramFiles')
    If $path == '' Then SetError(1)
    Return $path
EndFunc

This script will backup the registry key of AutoIt3XScript to AutoIt3XScript_Backup.reg, delete the key and then add the entries that I described above.

Tested on Windows 7. Use with caution.

Edit: A cosmetic fix to context verb names.

Edited October 7, 2013 by MHz

[storme]

@MHZ

Thanks for the effort!

However, I'm going to go with Mat's solution (new file extn.) as I need something that can be used on a client machine to seamlessly run A3X scripts that are meant to be run on the 64Bit interpreter on the 64bit interpreter.

I will however download your code and have a look through it as I want to add a few menu options to this computer.  THANKS!

[storme]

I don't see why it's so difficult to understand that the a3x format HAS NO BITNESS. It's still a script. It's just an au3 file but encoded.

If you want it to run as x32, you load it with an x32 AutoIt. And the same goes for x64. If it has things that only work in one bitness or another, they should be coded as such using the macros to check.

Sigh I wish people would read a thread totally before replying.

If I have a script that will only run "properly" on the 64bit interpreter and I compile it to A3X how will a client "seamlessly"  make sure it's run under the  64bit interpreter?

Macros are useless as the script is already running under whatever is configured as the interpreter to run A3X files.

So as I've explained before A3X may not have a Bitness HOWEVER.... the script contained in that A3X can have and there is the Problem.

Anyway it's all academic as there is a workaround (Mat's) that I'll script up and use in due course.

[wraithdu]

Are you too wrapped up in preaching that you can't see the solution? I mean, it's not hard, most if it is there for you already.

1) Script runs. Use the @AutoItX64 macro to determine if you're running the required bitness. If you are, you're done.

2) If not, check @OSArch to be sure you're running an x64 OS. If not, then you're done.

3) If so, ie you're running in 32-bit mode on a 64-bit OS, then find the correct AutoIt3_x64.exe. You can use the registry to find the AutoIt3 install path at HKLMSOFTWAREWow6432NodeAutoIt v3AutoIt - InstallDir, or assume that the x64 interpreter is in the same location as @AutoItExe.

4) Relaunch your a3x using the x64 interpreter. Done.

Edit:

I see you consider this a 'workaround' as opposed to a solution (your point #4 in post #11). Why exactly is this not a solution when it is transparent to the end user and would work on all systems? Aside from your creating one utility function, I don't see the problem.

Edited October 7, 2013 by wraithdu

[storme]

Are you too wrapped up in preaching that you can't see the solution? I mean, it's not hard, most if it is there for you already.

I should leave this but I can't help but to rectify inaccuracies.

Is it preaching to try and improve the user experience of this language and to reply to comments.

One of the things we were taught at University is to strive for "continual improvement" in any software we maintain.

BTW this thread has been marked as "solved" so I have found a "solution" for myself so I have seen at least one personal solution.

 

1) Script runs. Use the @AutoItX64 macro to determine if you're running the required bitness. If you are, you're done.

2) If not, check @OSArch to be sure you're running an x64 OS. If not, then you're done.

3) If so, ie you're running in 32-bit mode on a 64-bit OS, then find the correct AutoIt3_x64.exe. You can use the registry to find the AutoIt3 install path at HKLMSOFTWAREWow6432NodeAutoIt v3AutoIt - InstallDir, or assume that the x64 interpreter is in the same location as @AutoItExe.

4) Relaunch your a3x using the x64 interpreter. Done.

Yep I already stated that as a possible "work-around" in the other thread

You'd also have to add a check to make sure that the script is a A3X and not an AXE file.

It does however require that this code be added to "every" 64bit project that is written just in case it's compiled to A3X.

 

Edit:

I see you consider this a 'workaround' as opposed to a solution (your point #4 in post #11). Why exactly is this not a solution when it is transparent to the end user and would work on all systems? Aside from your creating one utility function, I don't see the problem.

A solution is something that fixes a problem. So for me Mat's suggestion is a "solution" for me.  One that I will be implementing.

However, all of these suggestions I consider just workarounds as the next person to run into this inadequacy may not even know they have a problem until the project is rolled out to his/her users.  They will then spend hours trying to work out why their code works perfectly on their computer but not on their clients computers.  Maybe they will happen upon this thread and implement one of the suggestions.here.

Of course this is doomed to be repeated for every user that uses A3X and "thinks" they are compiling to 64bit as that is what they set in the script.

e.g.

#AutoIt3Wrapper_Outfile_type=a3x

#AutoIt3Wrapper_UseX64=y

Yes I know that A3X doesn't have BITNESS but I didn't at the start of this Odyssey and I don't think many users would either.

However, code does and code (in this case) is contained in a A3X container so the "package" does have bitness to a user.

As you said your suggestion is "transparent to the end user" meaning the "code writers" solution what will be run on a computer somewhere and "would work on all systems". 

Which is true!

My point has always been the "end user" of the "AutoIt language" are the "code writers" and this situation is not transparent to them and all depends on what system (64/32Bit EXE/A3X) they use on what their code will do.  Unless they know everything that has been brought to light in this and the other thread.

 

A "solution" (IMO) would be to implement something in the mechanics of this language to improve it and remove the necessity for each user to know this problem exists and make changes/additions to work around the problem. 

But of course that is my opinion which like yours and the others is just as valid.

Thank you for your feedback

John

EDIT:

To Clarify when I refer to "user" I mean the "AutoIt user/developer" (i.e. Code writers) not the client using the program developed by AutoIt Users.

Edited October 8, 2013 by storme