Hi Folks
Hi Folks,
I came across the following strange magic:
Using XE2, in case that matters, I created an empty console application, ran it in the IDE, no problem.
After I saved the project to "TestUpdate" and ran it again, Delphi suddenly errored out with a "need elevated rights to run".
Saved the project again under "TestXXX" for example and it compiled and ran again without problems.
Obviously the "Update" in the project name triggers the elevation prompt. All the created "*update*.exe" files carry the shield overlay.
But why? And where and how can I turn this off?
If I rename any of these "*update*.exe" files in windows explorer to xxx.exe, they run without elevation prompt. For the fun of it I renamed other exes to update.exe, but they didn't want elevated rights when started.
So there must be some combination of the code generated by delphi and the substring "update" in the exe name which triggers this behaviour. Does anybody know what's going on here?
I came across the following strange magic:
Using XE2, in case that matters, I created an empty console application, ran it in the IDE, no problem.
After I saved the project to "TestUpdate" and ran it again, Delphi suddenly errored out with a "need elevated rights to run".
Saved the project again under "TestXXX" for example and it compiled and ran again without problems.
Obviously the "Update" in the project name triggers the elevation prompt. All the created "*update*.exe" files carry the shield overlay.
But why? And where and how can I turn this off?
If I rename any of these "*update*.exe" files in windows explorer to xxx.exe, they run without elevation prompt. For the fun of it I renamed other exes to update.exe, but they didn't want elevated rights when started.
So there must be some combination of the code generated by delphi and the substring "update" in the exe name which triggers this behaviour. Does anybody know what's going on here?
Not quite - It is the OS that is doing the magic, better known as "Installer Detection Technology" (http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx?ppud=4 - Search for "Installer Detection Technology" on the page).
ReplyDeleteInstaller Detection only applies to:
1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled
Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:
* Filename includes keywords like "install," "setup," "update," etc.
...
It seems your OS was infected by viruses or trojan I guess.
ReplyDeleteIf you call UAC a virus then probably yes Sam Shaw :) , but Nicholas Ring s answer makes perfect sense to me. I'm currently reading up on the subject.
ReplyDeleteYes Ondrej Kelle , but it is obviously only triggered for console applications. So I either have to add a manifest or I have to make sure, my unit test suites are not called "*update*.exe". I'll probably go for the latter.
ReplyDeleteI avoid calling my apps & installers anything that includes "install", "upgrade", "update" or "setup" for that reason. :)
ReplyDeletewell, interesting ! So I have a dumb question: why rename other exes to update.exe, but not ask for evaluation when started?
ReplyDeleteSam Shaw Not a dumb question. Maybe the OS has some smarts about it and knew that they weren't initially an installer? Maybe it would after a restart?
ReplyDeleteBut to answer your question, I do not know.
Nicholas Ring I think, the sections 2&3 in your first reply cover it. A "bare bones" Delphi 32bit console application does not request an ExecutionLevel and LUA is enabled by default on windows.
ReplyDeleteIf I add a manifest that requests a certain execution level, all should be fine.
So any exe that I can rename to "*update*.exe" without triggering UAC probably has a proper manifest.
There are things I will never understand Windows, as its poor design for security..
ReplyDeleteLübbe Onken You are right. I just used PE explorer to see if there is an embedded manifest in console and winform app created by RAD XE.
ReplyDeleteI also used C++ builder 6 to test winform and console too.
It's interesting, seems since RAD XE ( I guess not 2009/2010, may need someone who own these version to tell) winform app is embedded with uac manifest after emmiting executables, while console app isn't..
Could it be the feature in later RAD version? It's common to name files like XXXupdateXXX. ( from the begining I thought only exactly "update" key word will match rule).
Thanks for confirming my observation Sam Shaw
ReplyDeleteThat detection logic is complete bonkers. I had an exe the other day which contained "patch" in its name and it required elevation. When I changed the name around a bit it did not.
ReplyDeleteStill working with D2007, if let alone, all then compiled apps have a default manifest that came in the form of a compile option "Enable Runtime Themes". That default manifest is very silly and does not allow to change it, so I build my owns, make some standar .res files and add the appropiate one for every thing I build later. That way an Installer IS an Installer and an app IS an app without the OS guessing what it is. Of course you need to turn off that compile option, or you're going to have duplicate resources.
ReplyDeleteIt's nothing to do with console apps or GUI apps. All you need to know can be found in Nicholas's first link. There's no real magic here, it's all documented.
ReplyDeleteStefan Glienke MS expect that, 8 years on, you will be specifying requestedExecutionLevel in your app manifest
ReplyDeleteAt least the file can be named like that - I once tried to create a folder named "Con".
ReplyDelete+Gustav all covered here http://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247.aspx#namespaces
ReplyDelete