AutoIt v3.3.9.12 Beta

[Richard Robertson]

It's a side effect of getting tenary to work at the start of a line. I could block it but it's allowed in most other languages so seems like it's OK.

It's a case of having to write extra code to block it as opposed to adding code for a useless feature.

Seems fair. Does this mean mid-expression assignments will be a thing?

[Jon]

I'm not planning to.  I've broken god knows how many lines of C by doing those. It usually triggers a warning these days so I don't think it's a great idea to encourage it.

[Richard Robertson]

Hmm. Not to mention the fact that it would break a very significant number of existing scripts too.

[Jos]

The latest Beta of Autoit3Wrapper is working fine.

I don't know why Aut2Exe fails then compiling with the out-directive, because despite the error "Aut2exe.exe ended errors because the target exe wasn't created, abandon build.rc:9999" the target exe is created successfully and it is working as expected.

This is simple: it checks for the wrong output file when using the last production version of Autoit3Wrapper... hence you need to use the Beta version.

Jos

[Trong]

Good job Jos! 

[jaberwacky]

Hi.  Is it no longer possible to run an exe which has a #RequireAdmin statement from within a script which does not have administrator elevation?

[Rich071]

I apoligize if I posted this is in the wrong section. I have installed the 3.3.9.12 Beta on top of ver 3.3.8.1 and ran the toggle AU3 Beta to make sure I was working with the latest beta. This is the first time working with the beta version.

I am having issues with Windows XP SP3 as I get an Aut2Exe error, unable to parse line 1677 in the StructureConstants.au3 file. I needed the beta installed because of the include files, needed, were not included with 3.3.8.1.

Is there a link that specifies the correct usage setup when working with the beta versions. I have 3.3.8.1 in a one VM and it works great. I decided to test the beta in a different VM. Personally, I would like just to have the beta version installed without the 3.3.8.1 to avoid any conflicts, but I know that is not possible.

I have searched the forum for answers on the parsing error but didn't come up with anything that helped.

Thanks in advance for any insight to this issue.

Rich

[Jos]

What do you mean when you say you installed it on top of 3.3.8.1?

When you run the installer, it will create an Beta directory in AutoIt3 which contains the whole Beta setup in its own environment.

Use SciTE to run or compile your scripts where F5 & F7 use the latest production and Alt+F5 & Alt+F7 use the installed Beta.

Jos

[Jos]

Hi.  Is it no longer possible to run an exe which has a #RequireAdmin statement from within a script which does not have administrator elevation?

How did you establish and test this?

[Rich071]

Jos,

When I said I installed on top of 3.3.8.1, I meant that 3.3.8.1 had to be installed first. Yes, the beta directories are there and everything should be ok. I think we found the issue. The key combinations, the Alt+F5 and the Alt+F7, do absolutely nothing. No errors, no beeps and the file does not get compiled.

The VM is basically clean and used for testing. Very little software installed. I will do a test install inside the other XP SP3 VM along with a Win 7 SP1 to see if they have issues.

I am using VMware WS 8 and never had issues like this before.

I will update this after I try a few things.

Thanks,

[Richard Robertson]

Rich071, did you install the full edition of SciTE or are you using the mini version that comes with the AutoIt install?

[Jos]

Jos,

When I said I installed on top of 3.3.8.1, I meant that 3.3.8.1 had to be installed first. Yes, the beta directories are there and everything should be ok. I think we found the issue. The key combinations, the Alt+F5 and the Alt+F7, do absolutely nothing. No errors, no beeps and the file does not get compiled.

The VM is basically clean and used for testing. Very little software installed. I will do a test install inside the other XP SP3 VM along with a Win 7 SP1 to see if they have issues.

I am using VMware WS 8 and never had issues like this before.

I will update this after I try a few things.

Thanks,

For those to work you need to install the separate installer listed in my Signature. The Basic SciTE editor that comes with AutoIt3 doesn't support all these extra's

Jos

[Richard Robertson]

Jos.

[Rich071]

Jos and Richard,

Yes, that was my problem. Installed the full version of the editor and it is working fine. I had seen it out there and I should have looked at it closer because of the later date.

I appreciate the quick response from both of you. I wish all support groups were as efficient. But that's life.

Keep up the good work on making this a top notch program.

Thanks again,

Rich

[jaberwacky]

How did you establish and test this?

 

Ok, this set-up demonstrates the issue.  The following script can be interpreted or compiled.

#RequireAdmin ; Run this script once and then comment this line and run the script again.

Run(@ScriptDir & "\Admin.exe")

Run(@ScriptDir & "\NonAdmin.exe")

Compile the following two scripts.

Admin.exe

#NoTrayIcon

MsgBox(0, '', @ScriptName)

NonAdmin.exe

#RequireAdmin

#NoTrayIcon

MsgBox(0, '', @ScriptName)

When the first script is ran with #RequireAdmin then both NonAdmin.exe and Admin.exe will run.  When the #RequireAdmin is disabled then only Admin.exe will run.  Tried on latest beta and production.

Edited July 27, 2013 by jaberwocky6669

[Jos]

I can reproduce this indeed.

Need to see where this is coming from.

Jos

Edited July 27, 2013 by Jos

[jpm]

Ok, this set-up demonstrates the issue.  The following script can be interpreted or compiled.

#RequireAdmin ; Run this script once and then comment this line and run the script again.

Run(@ScriptDir & "\Admin.exe")

Run(@ScriptDir & "\NonAdmin.exe")

Compile the following two scripts.

Admin.exe

#NoTrayIcon

MsgBox(0, '', @ScriptName)

NonAdmin.exe

#RequireAdmin

#NoTrayIcon

MsgBox(0, '', @ScriptName)

When the first script is ran with #RequireAdmin then both NonAdmin.exe and Admin.exe will run.  When the #RequireAdmin is disabled then only Admin.exe will run.  Tried on latest beta and production.

My god,

some work for Jon

I go the same under Win8-64bit with the compiles in x86

[Jon]

No investigation needed, it's pretty much by design in place of a "hack" we used in the previous version. Here is what is going on.  The quick answer is that you need to use ShellExecute() instead.

There are two ways to launch a program in Windows: CreateProcess (which we wrap up using Run()) and ShellExecute(which we wrap up using ShellExecute()).  Executables (general executables, nothing to do with AutoIt) have a manifest section added to a resource which says the level they should run at. Typically this is asInvoker (runs as a user) or requireAdministrator (wants to run as admin).

The weird part is when we are running as user (by default with UAC) and we CreateProcess a file that is tagged with requireAdministrator the OS actually fails and returns a "can't run, this needs elevation" error code. CreateProcess (Run()) cannot execute a process in such a way that it moves from a user to administrator level.  Try it on other "admin" executables and they will all fail in the same way.

ShellExecute() on the other hand is the way that most things are launched in windows.  Double click a file, double click a file extension. Type in a file extension in cmd.exe, etc.  This does have elevation code in it and it is the place where you get the UAC prompt.  Going through this ShellExecute+UAC code is the only way to elevate.

Run/ShellExecute have different features, especially around capturing process IDs, and ShellExecute was a later addition to AutoIt so we've all gotten in the habit of using Run all the time. The default function to use would be ShellExecute really.

So how come this used to work in 3.3.8.1?  Well in the beta #requireadmin causes the compiled exe to have a proper manifest resource.  This means it acts completely like a normal exe - this is a much better solution. But in 3.3.8.1 we didn't have the facility to properly write the manifest file so we tagged all files as "asInvoker".  Then when the compiled exe ran the first thing that happened is that we detected that the script contained #requireAdmin and then silently reran itself using ShellExecute.  So it looked that you ran the script once, but it actually ran twice. You see this sort of thing in a number of Windows programs like Disk CleanUp. By default it is manifested "asInvoker" and runs as a user, but then you can click a button to "clean up system files" and it vanishes for a second before working - this is because it's doing a similar rerun trick.

You might ask why can't I leave the new proper manifest behaviour in and put the rerun hack back in. Well, think about it for a second and you'll see why.  (Edit: actually there is a sort of workaround by decoupling #requireadmin and #pragma compile but I'm not sure it would be too confusing)

[jpm]

Thanks Jon for this Strong explanation.

My only concern is should we have some warning in Run() doc?

[jaberwacky]

Thanks for the explanation Jon.  Tested and works fine!

Edit: Does Run() still have a purpose?  Should it be removed or would that be too big of a script breaker?

Edited July 28, 2013 by jaberwocky6669