Sign in to follow this  
Followers 0
VinitMeta

Single AutoIt executable to be used on 32 and 64 bit architecture

21 posts in this topic

Hi all,

I am using AutoIt 3.3.0.0.(latest release).

I dont know the architecture on which my script will ge getting executed. What i noticed that when i compile AutoIt scrpt for 32 bit windows architecture it do not

run on 64 bit and If i cretaed executable with /x64 switch, it only works with 64 bit windows architecture.

So now i need to maintain two executables for each of script separately for 32 bit architecture and 64 bit architecture.

So my problem here is :

Is their any way i can use the same executable on any system without concerning the architacture of the system.

I am really very badly stuck up because of this problem.

Anybody, if know the solution or have any pointer in this direction please guide me.

Thanks in advance.

Regards

Vinit Meta

Share this post


Link to post
Share on other sites



Hi all,

I am using AutoIt 3.3.0.0.(latest release).

I dont know the architecture on which my script will ge getting executed. What i noticed that when i compile AutoIt scrpt for 32 bit windows architecture it do not

run on 64 bit and If i cretaed executable with /x64 switch, it only works with 64 bit windows architecture.

So now i need to maintain two executables for each of script separately for 32 bit architecture and 64 bit architecture.

So my problem here is :

Is their any way i can use the same executable on any system without concerning the architacture of the system.

I am really very badly stuck up because of this problem.

Anybody, if know the solution or have any pointer in this direction please guide me.

Thanks in advance.

Regards

Vinit Meta

32 bit should run on both.

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

You are doing something wrong, a 32-bit compiled exe should run on 64-bit Windows. Maybe provide more info about the script / environment.

Share this post


Link to post
Share on other sites

You are doing something wrong, a 32-bit compiled exe should run on 64-bit Windows. Maybe provide more info about the script / environment.

More info in what respect. Can you please suggest me some things? Do you mean to provide some information in script or while compiling the script.

Share this post


Link to post
Share on other sites

More info in what respect. Can you please suggest me some things? Do you mean to provide some information in script or while compiling the script.

I would still like to hear your reasoning why you need an x64 version. Ignoring answers is rude.

Share this post


Link to post
Share on other sites

I would still like to hear your reasoning why you need an x64 version. Ignoring answers is rude.

I have COM dll. So i am doing call to obj create function. The scripts involves Interprocess communication through COM dll using Pipes. I want to execute script on XP 64 bit pro. But when i execute the primitive something is breaking. id ont know now its the problem with COM or something.

And as a automation task i dont know on which architecture my script will be going to execute as it will all be decided at run time.

regards

Vinit meta

Share this post


Link to post
Share on other sites

And as a automation task i dont know on which architecture my script will be going to execute as it will all be decided at run time.

regards

Vinit meta

That's easy. Make one script for each platform then FileInstall them into a "launcher" script that uses @OSArch to Run() the needed one.

Share this post


Link to post
Share on other sites

That's easy. Make one script for each platform then FileInstall them into a "launcher" script that uses @OSArch to Run() the needed one.

Nice idea... but I'm still curious on why the 32bit is having issues on the 64bit OS. I would think every 32 bit app he has would run into an issue then. Unless he's specifically using API calls that are 64 bit specific :) ?

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

I'm trying to run an AutoIt script compiled for standard 32 bit but running on Win XP 64. I'm using ObjCreate() to instantiate a COM object. It fails on my Win XP 64 system. Not 100% sure but I believe it is a 64 bit problem, but haven't tried it on Vista 64 yet to verify.

Basically looks like this.....

$myCOMObj= ObjCreate("MyCOM.MyObject")
    If IsObj($myCOMObj) Then
        $pass = True
    Else 
        $pass = False
    EndIf

If I compile the AutoIt script in x64 mode it works fine, but then I need to make a 64 bit release of my script code. Everything else executes with no problems. Is there any other way around this?

Share this post


Link to post
Share on other sites

So why not compile for x64, will the world really end just because your script gets a few kb extra?

No, the world won't end. But I need my package to be deployable on all OSs including both 32 and 64 bit versions. I'd rather have only one version to deploy (i.e. 32 bit) especially since this is a small portion of the functionality and it appears to be the only problem area. If I have to deploy two versions (32 and 64 bit) that's OK, I'm just trying to make sure that is the only alternative here.

What I'm really curious about is it if the implementation of ObjCreate() and/or the way COM objects are handled in AutoIt is dependent on the OS architecture in some way.

Share this post


Link to post
Share on other sites

What I'm really curious about is it if the implementation of ObjCreate() and/or the way COM objects are handled in AutoIt is dependent on the OS architecture in some way.

Well only the devs would knows that for sure (I don't), but I can give you an idea how to handle both x86 and x64 code in what seems to be one executable (to the end-user atleast), see THIS thread from yesterday.

Share this post


Link to post
Share on other sites

Well only the devs would knows that for sure (I don't), but I can give you an idea how to handle both x86 and x64 code in what seems to be one executable (to the end-user atleast), see THIS thread from yesterday.

LOL! Vinit and I are on the same development team. Let's close this thread and use the other.

Share this post


Link to post
Share on other sites

Can you provide more information on the COM object? Possibly show an error message like the one in the help file for the COM error event.

Share this post


Link to post
Share on other sites

Nice idea... but I'm still curious on why the 32bit is having issues on the 64bit OS. I would think every 32 bit app he has would run into an issue then. Unless he's specifically using API calls that are 64 bit specific :) ?

Hi all. Vinit and I are on the same dev team working on the same problem. I started this thread here but we should continue the discussion in the same thread (this one only) since it's the same exact problem.

A little background here. We are building some automation for testing our company's product software. Everything works great on both 32 and 64 bit except for one COM object. This COM object is from a DLL that does two main things: 1) uses a named pipe to communication log messages and results data back to our main system records system and 2) gets and retrieves data into a SQLite DB using System.Data.SQLite.

The DLL is written in C#. I'm wondering if:

  • There is a problem with ObjCreate() that makes it specific to the OS architecture it is on
  • There is a problem with the underlying Win32 call that forces us into using 64 bit compiled AutoIt executables in order to use ObjCreate()
  • The fact that the COM DLL is written in .NET and is therefore executed natively (i.e. the IL is interpreted and run by .NET x64 Framework) highlights this problem only in .NET COM, and if the COM DLL was written in native 32 (i..e C++, etc.) and executed under WoW64 we wouldn't see the problem
  • Something else we aren't seeing

Share this post


Link to post
Share on other sites

Also forgot to mention that this failure only occurs if we are on 64 bit system and running with 32 bit compiled AutoIt executable. If it's on a 32 bit system and 32 bit compiled AutoIt executable it works fine, and if it's on a 64 bit system with 64 bit compiled AutoIt executable it works fine. We are wondering why it is failing on 64 bit systems with 32 bit compiled AutoIt, and if there is a work-around or fix.

Share this post


Link to post
Share on other sites

I don't expect my post to be helpful to you, but I just wanted to note that I've experienced what may be a similar problem. To be brief, I have an AutoIt application that uses four different COM objects. At Christmas time, I installed the application on my mother-in-law's NEW computer, which is running Vista 64 (don't ask...).

I have been running this application on my Windows XP and Vista 32 machines for several months, without problem. On the Vista 64 machine, the application did not run "well" -- it normally displays its GUI window in less than a second, but was taking over half a minute on the Vista 64 machine. I only had time to trace it down to one specific ObjCreate. The ObjCreate did NOT fail, but it took about 35 seconds for the object to initialize; that is, for the next AutoIt statement to execute. The vendor of the activex control claims no problem under Vista 64. This is as far as I got (my mother-in-law lives in Arizona and I live in Michigan), but it is an example of where a 32-bit AutoIT program may not run correctly under Vista 64. I realize there could be a zillion reasons why, but I was at least careful to ensure there was no virus scan running. The Vista event log showed absolutely no problems. At the time, I didn't perceive it as a potential AutoIt problem -- I expected more likely it was a problem withe the control. Vista 64 simply is very low for me on the priority list. I only post in case you may perceive relevance.

Hi all. Vinit and I are on the same dev team working on the same problem. I started this thread here but we should continue the discussion in the same thread (this one only) since it's the same exact problem.

A little background here. We are building some automation for testing our company's product software. Everything works great on both 32 and 64 bit except for one COM object. This COM object is from a DLL that does two main things: 1) uses a named pipe to communication log messages and results data back to our main system records system and 2) gets and retrieves data into a SQLite DB using System.Data.SQLite.

The DLL is written in C#. I'm wondering if:

  • There is a problem with ObjCreate() that makes it specific to the OS architecture it is on
  • There is a problem with the underlying Win32 call that forces us into using 64 bit compiled AutoIt executables in order to use ObjCreate()
  • The fact that the COM DLL is written in .NET and is therefore executed natively (i.e. the IL is interpreted and run by .NET x64 Framework) highlights this problem only in .NET COM, and if the COM DLL was written in native 32 (i..e C++, etc.) and executed under WoW64 we wouldn't see the problem
  • Something else we aren't seeing

Share this post


Link to post
Share on other sites

The ObjCreate did NOT fail, but it took about 35 seconds for the object to initialize; that is, for the next AutoIt statement to execute.

Impossible to tell if it's related but in our case the ObjCreate() returns immediately with a failure.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0