64bit vs 32bit

[drego]

During the AutoIt installer it gives the option to install 32bit or 64bit tools. Most systems these days are 64bit. Should I be creating autoit programs for both? Do autoit compiled applications really benefit from being 64 vs 32? If compiled for 64bit will there be a problem using the mass of UDFs available or does that not matter?

Under what circumstances is compiling for 64bit going to make my program run better? Are there any downsides? Any differences in how I develop, use UDFs, DLLs, anything?

Also, if I install 64bit Autoit tools can I still compile for 32bit and what about IE browser controls will they then be the 64bit IE?

Thanks.

Edited January 18, 2015 by drego

[Bowmore]

One thing to watch out for when compiling AutoIt applications as 64Bit, is if you are COM libraries etc. your script may not work. The reason is that a lot of programs that have COM interfaces to allow functionality to be used in application like AutoIt, have not yet written 64Bit versions, even though the main program may have a 64Bit version.   

[hydranix]

 

Should I be creating autoit programs for both?

Whichever your target system supports.

 

Do autoit compiled applications really benefit from being 64 vs 32?

There's no benefit in performance, however if the target OS is 64 bit, and for whatever reason lacks the 32bit comparability layer (SysWoW64), then 32 bit compiled script will not run.

 

 If compiled for 64bit will there be a problem using the mass of UDFs available or does that not matter?

No. It's worth noting though that AutoIt isn't truly compiled. The 'compilation' process is simply embedding the finished script with the interpreter. 

 

Under what circumstances is compiling for 64bit going to make my program run better?  Are there any downsides? 

See answer number 2.

 

Any differences in how I develop, use UDFs, DLLs, anything?

No.

 

Also, if I install 64bit Autoit tools can I still compile for 32bit and what about IE browser controls will they then be the 64bit IE?

Yes you can still compile for 32.

Generally, you'll want to use 32bit AutoIt for automating other 32bit processes. and 64bit AutoIt for automating 64bit process, IE included.

[newniman]

My home network consists of a single Win7 64 bit AutoIt tcp client and Win7 32 bit tcp server(s).

My (poorish) memory is that 64 bit AutoIt was installed on the 64 bit client machine.

That client machine recently suffered catastrophic hardware failure. After receipt of a Win 7 64bit replacement I created a system image (via AOEMI backupper, over the network to the server machine)  but am not totally sure if that image was before/after I had installed 32 bit AutoIt on it.

In any case, my AutoIt client/server script no longer works (hope I don't have to describe that problem) and, after a lot of head scratching/testing, my guess is the 32 bit AutoIt install is/could be the problem...for example this exists in my Win7 64 bit script:

#include <WinAPIFiles.au3>
_WinAPI_Wow64EnableWow64FsRedirection(False)

(that also exists in my Win7@ 32 bit script though)

Anyway, since i'm:

(i) not sure whether my system image was before/after the seemingly ill judged AutoIt 32 bit install

&

(ii) I won't have an external usb drive capable to reload the image until after the Festive period (and being a little nervous of doing that for the very first time ever) 

It seems an easy fix is (or could be) to uninstall the 32 bit AutoIt  (v3.3.14.2) via Windows Control panel then install 64 bit AutoIt.

Question:

My question is whether my easy fix seems sensible or should I be concerned that Windows Control Panel 32 bit uninstall will leave a "mess" (in the registry, for example).

I'm just leaving on a short-break so thanks if there should be any replies and if there are any required clarifications i'll get back to those in a couple of days.

(...or maybe I should just describe the problem & fix the current setup?)

====================================================================================================================================================================================================================

Solved (for the record):

In the above description, psexec is used to start the remote server scripts from within the client script. For psexec to operate successfully the client script must already have set the redirection as False:

#include <WinAPIFiles.au3>
_WinAPI_Wow64EnableWow64FsRedirection(False)

However, if redirection remains False prior to TCPStartup on the client - that fails, i.e. to fix the failure include:

_WinAPI_Wow64EnableWow64FsRedirection(True)

Immediately prior to TCPStartup()

Edited December 19, 2016 by newniman
case specific solution