Sign in to follow this  
Followers 0
LxP

@AutoItVersion relies on VERSIONINFO

5 posts in this topic

Hi devs,

If I were to compile the following script using CompileAU3 and AutoIt v3.1.1.82, and run it:

#Compiler_Res_FileVersion = 1.0
Local Const $SCRIPT_VER = '1.0'

MsgBox(0x40, @ScriptName, 'MyScript v' & $SCRIPT_VER & @LF & 'Compiled with AutoIt v' & @AutoItVersion)

then I would receive this box:

MyScript v1.0

Compiled with AutoIt v1.0.0.0

Should the @AutoItVersion macro be relying on the VERSIONINFO resource of a compiled EXE? To me it seems quite likely that an AutoIt scripter may want to override the appropriate field within this resource to reflect the version of their script, while still being able to report the AutoIt version used to compile the script for debugging purposes.

Currently this seems to be impossible without either hard-coding the script version into the script or reporting a false script version in the VERSIONINFO.

Share this post


Link to post
Share on other sites



A couple of bug reports have been posted for this but it is normal behaviour when you hack the resources to change the version. CompileAu3 will allow you to choose a custom resource entry for your script version or you can use the macro to reflect your script version rather then the AutoIt version.

When you choose to hack the original AutoIt resource information, then you accept any side affects that it may cause. This can work in your favour if handled correctly.

Share this post


Link to post
Share on other sites

I said this in another thread:

the moment anybody changes the subsystem, you are no longer dealing with AutoIt and as far as I'm concerned are no longer entitled to post support requests.

However, I should make that more generic.

If you change any bytes within an AutoIt binary, you are no longer dealing with standard AutoIt and are no longer entitled to post support requests. You also accept full responsibility for any alterations in behavior AutoIt obtains as a side effect to your modifications.

Its like invoking undefined behavior in C++; once you go that route, you are no longer abiding by the rules set forth so you are on your own and anything can and may happen and the full responsibility lays on your shoulders as the person who went into the verboten realm.

Share this post


Link to post
Share on other sites

Thanks for the responses guys. It is of course logical behaviour now that I've been reminded of what was indeed being done to the binary. I suppose it was simply surprise more than anything else that the @AutoItVersion macro reads its information from there (although it really isn't that surprising).

Out of curiosity, would it be likely that this might change in the future? I would imagine that more people will want to take advantage of modifying the VERSIONINFO in the future than less, so it may come up again.

Share this post


Link to post
Share on other sites

If you change any bytes within an AutoIt binary, you are no longer dealing with standard AutoIt and are no longer entitled to post support requests. You also accept full responsibility for any alterations in behavior AutoIt obtains as a side effect to your modifications.

Maybe this should be mentionned in the help file under @AutoITVersion. Or at least in the SCITE manual. If nobody has time to write the line, I might be able to help a bit. Send me a line.

Obi Wan Celeri


I am endeavoring, ma'am, to construct a mnemonic circuit using stone knives and bearskins.SpockMy UDFs:Deleted - they were old and I'm lazy ... :)My utilities:Comment stripperPolicy lister 1.07AutoIT Speed Tester (new!)

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