Run() fails to run certain apps

[Ascend4nt]

For certain applications, the Run() command does not work.

For example, for ACDSeePro 2.5, I get this error:

"ACDSeePro25.exe - Unable to Locate Component

This application has failed to start because ACDInTouch70U.dll was not found. Re-installing the application may fix the problem"

This is the call:

Run("C:\Program Files\ACD Systems\ACDSee Pro\2.5\ACDSeePro25.exe","C:\Program Files\ACD Systems\ACDSee Pro\2.5")

The paths are both correct, I've even verified against the shortcut to the app, and have tried fiddling with different Working Directory paths, but to no avail - always the same error.

I'm wondering if this has to do with MSI-installed applications, which were causing problems with ShellExecute() when it used what *was* the default "open" command. (After testing, "open" was found to be at fault, and the default in a later release version is being changed to simply "")

See the discussion here for some info: http://www.autoitscript.com/forum/index.ph...st&p=666476

There's also a tracking ticket opened up by Jon somewhere, to lazy to look it up now.

Anyway, it would be great if someone tested this out on Microsoft OFfice (I don't have this installed, but it was giving Jos errors on running the shortcut) - if an attempt is made to Run() the program directly from its folder, I'd like to see if it results in the same type of error code I'm getting (some missing DLLs or somesuch)

Thanks for your help,

Ascend4nt

[Inverted]

Does it work when the compiled script is in the same folder ? Alternatively, what happens if you move this ACDInTouch70U.dll and any other files in the script's folder ?

If it works, then, it's 100% a problem with working directory. Maybe it needs a trailing slash for good measure ? lol

Edited June 12, 2009 by Inverted

[GEOSoft]

Just on a hunch try running it this way and see what happens

$sWorking = @WorkingDir
FileChangeDir(@ProgramFilesDir & "\ACD Systems\ACDSee Pro\2.5\")
Run("ACDSeePro25.exe")
FileChangeDir($sWorking)

[Valik]

Tell the makers of this software to stop writing shitty software. You can't run ACDSee from a command line (@COMSPEC) either.

Here's how it works. When you launch ACDSeePro25.exe using Windows Explorer (Start->Run, shortcut, invoke the executable directly) then it looks up "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\ACDSeePro25.exe". Go there and you will see a string value called "Path". Windows prepends the data from the Path string value to %PATH% when that process is launched. When you use something not Windows Explorer (AutoIt, command window, et cetera) then this path information is not prepended. Since the DLL in question is located at "C:\Program Files\Common Files\ACD Systems\EN\ACDInTouch70U.dll" it can't be found using the standard DLL search order. Thus the application fails to start.

Try this out. Compile the following script twice. The first time compile it to the name "ACDSeePro25.exe" and run it. Now compile it to "ARandomName.exe". Run each and compare the output:

If Not @Compiled Then
    MsgBox(4096, "", "Compile first")
Else
    MsgBox(4096, "", EnvGet("PATH"))
EndIfoÝ÷ Ù.ßÙebq騭ë-¹÷ëzV­yÛh Òyì!z{ayì^rÛnW§jg¢²«¨´I箹{ªºS+"±ªh¢¹ruë"wjeƭȶ+.²)à­z«µë-¡¨ZrH§¢·^®Ú,¶Þ²ìyèËZÖ«vZjبÄáÉë-欲驶*'¶­¶¢ú$z¸¬jÊÈ(x-¢Þ¥éݶ¦Ú¶Zµ«h¶©jØh~Ø^¦º ­©+jvÞ­ë(÷y«"'§¢è!Â+aëh"Ô^iÛay¦è½éبçkz¬¶¼¤{%,x­ wöÁ'¼g­jwDôµû§rبƬméhÂÚayéïº'éí~íêk¢
ÚV®Èb¶Ø^·­º¹í¡«ë-j׺Ú"µÍØØ[ÛÛÝ   ÌÍÜÔ][H[Ù]
    ][ÝÔU ][ÝÊBØØ[ÛÛÝ  ÌÍÜÐ]HYÔXY
    ][ÝÒÑVWÓÐÐSÓPPÒSIÌLÔÓÑÐTIÌLÓZXÜÜÛÙ   ÌLÕÚ[ÝÜÉÌLÐÝ[Ú[ÛÌLÐ]ÉÌLÐPÑÙYTÌK^I][ÝË  ][ÝÔ] ][ÝÊB[Ù]
    ][ÝÔU ][ÝË  ÌÍÜÐ]   [È ][ÝÎÉ][ÝÈ  [È ÌÍÜÔ][B[    ][ÝÐÎÌLÔÙÜ[H[ÉÌLÐPÑÞÝ[ÉÌLÐPÑÙYHÉÌLÌIÌLÐPÑÙYTÌK^I][ÝË    ][ÝÐÎÌLÔÙÜ[H[ÉÌLÐPÑÞÝ[ÉÌLÐPÑÙYHÉÌLÌI][ÝÊB[Ù]
    ][ÝÔU ][ÝË  ÌÍÜÔ][

Edit: For those who want to know how I discovered all this, the following steps were taken:

• Start a Windows XP Pro SP3 virtual machine.
• Install ACDSee trial.
• Start Process Explorer.
• Run ACDSee via AutoIt and via the Desktop shortcut.
• View the detailed properties in Process Explorer for the two ACDSee processes. Comparing the environment variables I noticed the difference.
• Stop and think for a moment, "How can one process have a different environment than the other?"
• Recall AppPaths feature.
• Open the AppPaths key and find ACDSeePro25.exe and see the Path string value.
• Append "C:\FUCKYOU" to the string value.
• Re-run ACDSee and check the PATH environment variable to see that "C:\FUCKYOU" is now present confirming that Windows is prepending the AppPath data to the path of the process.
• Write post explaining how it works.
• Edit post with the text you are reading.

Edited June 12, 2009 by Valik

[James]

• Write post explaining how it works.
• Edit post with the text you are reading.

Love the last two points.

[Ascend4nt]

Wow, Valik, thanks for the thorough investigation & explanation. I had no idea it was using such an insane method of running the program.

Incidentally, replacing the Run() command with this will avoid the extra work:

ShellExecute("C:\Program Files\ACD Systems\ACDSee Pro\2.5\ACDSeePro25.exe","","C:\Program Files\ACD Systems\ACDSee Pro\2.5")

Problem is, guess what - no access to the Process ID (though unlikely more than one instance will be active at one time). I really wish you would reconsider adding support for returning Process ID's in ShellExecute(). Its something that can prove very useful for programmers here, and isn't that what should be considered - what would be useful in AutoIT.

(If you knock the idea down again, perhaps we should poll the users on it?)

Thanks again,

Ascend4nt

[Valik]

Wow, Valik, thanks for the thorough investigation & explanation. I had no idea it was using such an insane method of running the program.

Incidentally, replacing the Run() command with this will avoid the extra work:

ShellExecute("C:\Program Files\ACD Systems\ACDSee Pro\2.5\ACDSeePro25.exe","","C:\Program Files\ACD Systems\ACDSee Pro\2.5")

I should have been more clear and said when invoked outside the Shell.

Problem is, guess what - no access to the Process ID (though unlikely more than one instance will be active at one time). I really wish you would reconsider adding support for returning Process ID's in ShellExecute(). Its something that can prove very useful for programmers here, and isn't that what should be considered - what would be useful in AutoIT.

(If you knock the idea down again, perhaps we should poll the users on it?)

Thanks again,

Ascend4nt

AutoIt is a scripting language, not a does everything Ascend4nt wants built-in language. If you don't like how ShellExecute() works then write your own (I think you already have). Otherwise, drop the subject.

[Ascend4nt]

I should have been more clear and said when invoked outside the Shell.

AutoIt is a scripting language, not a does everything Ascend4nt wants built-in language. If you don't like how ShellExecute() works then write your own (I think you already have). Otherwise, drop the subject.

#1: I was not the one who created the request for the feature, I only added my voice to it because you straight out said 'it can't be done', which was completely wrong. So no, its not a 'what Ascedn4nt wants' thing - there's at least two voices in that request thread, and I'm guessing more would be added if we did a poll.

#2: Why waste the extra script code on a function that can very *easily* be modified to add this extra functionality - which is actually something of an inconsistency between Run() and ShellExecute(). Why not try to sync the two so that it makes sense overall.

Sure we can all live in a world where Valik's word is the final word, but to me, I see denying this easily-implemented and very-useful feature request as both an inability to see past your own limited perspective and what looks like pure coding laziness. (which is ironic, seeing as how much effort it would take to figure out what was going on with ACDSee)

Yes, for now I will stick with my code because it is better than the built-in code - but what sense is there for it. It adds some bloat, fixes a problem that Run() alone fails at, and provides a consistent interface (other than allowing redirection of STDI/O).

Now I assume your response will be again to drop the subject. Does this mean I will be kicked off the boards if I ask others to voice their opinions in a separate thread?

-Ascend4nt

[Valik]

The next time I say to drop a subject, ascendant, drop the subject. You've got 24 hours to think about that.

For those who don't read the issue tracker, let me elaborate. The PID is not directly available to be returned. Can we get it? Yes. Why don't we get it? Because it's not always available to get. There are 2 paragraphs on MSDN explaining how ShellExecuteEx() can be successful but no process handle will be returned (the process handle is required to get the PID):

A handle to the newly started application. This member is set on return and is always NULL unless fMask is set to SEE_MASK_NOCLOSEPROCESS. Even if fMask is set to SEE_MASK_NOCLOSEPROCESS, hProcess will be NULL if no process was launched. For example, if a document to be launched is a URL and an instance of Microsoft Internet Explorer is already running, it will display the document. No new process is launched, and hProcess will be NULL.

Note ShellExecuteEx does not always return an hProcess, even if a process is launched as the result of the call. For example, an hProcess does not return when you use SEE_MASK_INVOKEIDLIST to invoke IContextMenu.

When it takes two paragraphs to explain why something doesn't work how people expect it to work, it's really time to stop and consider, is this worth having? My vote is no, it's not. I've dealt with this community for years now and I know that stuff like this is going to lead to confusion. The general masses don't have Windows API knowledge or experience and they are going to wonder - despite the fact that it would be documented - why ShellExecute() doesn't return a PID. If I had a dollar for every question asked here that was covered in the documentation I'd have the financial equivalent to a high-salary income. I see no need to add more confusion for minimal gain. Everything that can be done by ShellExecute() can be done by a custom-written ShellExecute() or a little extra code for Run().

As for banning ascendant, I told him on the issue tracker that it was not going to happen and mentioned that there were numerous conditions under which a process handle/PID would not be available. This after also telling the original ticket creator that it wouldn't happen. Yet ascendant feels the need to insult my intelligence and experience by presuming he knows more about this language and what it should contain than I do. It's ironic for him to accuse me of being unable to see past my own limited perspective when he can't manage to realize my perspective is based on a different set of criteria than his.

Edited June 12, 2009 by Valik

[GEOSoft]

This is a poorly designed application. It is using what equates to a hack in order to store DLLs in non-standard locations.

That application has been crap since it's very first incarnation. I stopped messing with it years ago.

[Ascend4nt]

The next time I say to drop a subject, ascendant, drop the subject. You've got 24 hours to think about that.

Now that I'm unbanned (thanks for the additional 3 days - much appreciated [you told me I should be grateful ]), I'd like to ask something (not on the initial subject of course).

Why not warn people before banning them? Saying 'drop the subject' wouldn't have made me think "he'll ban me", and since you said something totally misleading/untrue in your post, shouldn't I at least be allowed that rebuttal? Sure, much of the post was my opinion on the forbidden subject, and you could have told me to shove it (or warned me of a ban), and I wouldn't have had a problem with it. That would have been much more civil to me.

I was going to correct you on something you said on your last post too, but how surprised was I when I saw I had been banned halfway into your post, and had no way to respond (I did attempt to rectify the point in PM though - which unfortunately gave me more ban-time). Either way, I surely would have avoided the 'subject' had banning (and additional banning!) been mentioned.

I suppose now that I know what happens when remarks from you aren't obeyed, you feel there's been no harm done, and another 'stupid user' (or whatever else you might think of me) has been educated, but really it just looks to me like you're upholding a common negative impression people have of you. Do you really welcome such ill-willed feelings toward you? I can't say that I'd want to continue working in an environment where people dislike (or even fear) me - that negativity just sort of rubs off on you.

Well, I suppose that's all I can say on the matter. I do respect you as a programmer and give thanks to the things you've actually helped me on, but I'd also like to think that we can have a civilized relationship when I come across you on the board, instead of feeling like I'm walking on eggshells, wondering if something I say will get me banned again..

[Valik]

Why not warn people before banning them? Saying 'drop the subject' wouldn't have made me think "he'll ban me"...

You were told to stop doing something. What other recourse would you expect? Me to pinch your bum and bat my eyelashes?

and since you said something totally misleading/untrue in your post, shouldn't I at least be allowed that rebuttal?

Oh? What would that be?

Sure, much of the post was my opinion on the forbidden subject, and you could have told me to shove it (or warned me of a ban), and I wouldn't have had a problem with it. That would have been much more civil to me.

Civility is overrated.

I was going to correct you on something you said on your last post too, but how surprised was I when I saw I had been banned halfway into your post, and had no way to respond (I did attempt to rectify the point in PM though - which unfortunately gave me more ban-time). Either way, I surely would have avoided the 'subject' had banning (and additional banning!) been mentioned.

Much like ignorance of the law is no excuse for breaking the law, ignorance of the rules is no excuse for breaking them. It should be pretty clear from a perusal of the banned thread that PMing me additional crap regarding a ban gets it extended significantly.

Do you really welcome such ill-willed feelings toward you?

Do you really think I care?

I can't say that I'd want to continue working in an environment where people dislike (or even fear) me - that negativity just sort of rubs off on you.

Why should I care what sheep think?

I do respect you as a programmer and give thanks to the things you've actually helped me on...

Yet you aren't giving me the benefit of the doubt that I have something like five more years experience developing a scripting language than you do.

...but I'd also like to think that we can have a civilized relationship when I come across you on the board, instead of feeling like I'm walking on eggshells, wondering if something I say will get me banned again..

Well, that's really all up to you. The biggest way to go away is not to listen. Belaboring a point, especially after I've said the subject was closed, because you don't agree is not only pointless but as you've found out, a very fast way to make an unwelcome exit for a few days.

Now, I'm awaiting your correction of my "totally misleading/untrue" statement.

Edited June 15, 2009 by Valik

[Ascend4nt]

Oh? What would that be?It was in my post. I'm not going to reiterate it when I can't even touch the subject. Just scroll up.

Anyway, I was stating that it would be fair to allow responses to incorrect or misleading statements.

Much like ignorance of the law is no excuse for breaking the law, ignorance of the rules is no excuse for breaking them. It should be pretty clear from a perusal of the banned thread that PMing me additional crap regarding a ban gets it extended significantly.

Is it stated in the forum FAQs/Readme's that when Valik says something, a person should obey or be banned? Is it stated that the Banned thread should be read? I must have missed it. You should probably edit those posts and provide a link to the Banned thread in the forum FAQ's. Also, having just found ->this<- - it would make sense to have that one linked to perhaps instead (and maybe made as a sticky).

Why should I care what sheep think?Sheep. Nice. You sure do think highly of people. And I suppose calling people sheep is not in any way related to actually 'caring' what people think. Because if a person really doesn't care what people think, why would they bother insulting people, defending themselves against them, or even banning said 'sheep'?

Yet you aren't giving me the benefit of the doubt that I have something like five more years experience developing a scripting language than you do.

Seriously, that was an opinion on what would make sense (to me, and at least one other) to incorporate into the language. And you know it's absolutely possible to implement what I was talking about. What I said had nothing to do with how experienced, proficient, or knowledgeable you are with the language. You simply chose not to implement the feature - and gave your reasons why. That's all that it boiled down to - a disagreement over what would make sense to either of us. Looking back, perhaps I went a bit far saying that it was being lazy, so I apologize for that.

Otherwise, I don't think there's much more to say.

[Valik]

It was in my post. I'm not going to reiterate it when I can't even touch the subject. Just scroll up.

You're treating something that required a trivial clarification on my part as far more than it really was.

Sheep. Nice. You sure do think highly of people. And I suppose calling people sheep is not in any way related to actually 'caring' what people think. Because if a person really doesn't care what people think, why would they bother insulting people, defending themselves against them, or even banning said 'sheep'?

Over-analysis is the root of all evil.