Hi,
I've a portabilized an app that requires registry keys, so I've used registry.nsh.
The launcher writes fine the keys, but miss the drag'n drop.
So I've used "RequestExecutionLevel" to "user" to avoid this, but the keys now are not written in registry.
If I use RequestExecutionLevel admin the keys are written, but at launch show always the windows for privileges attribution.
Is there a way to do this in silent mode?
Thanks.
Application rights
5 posts
Only elevated administrators can write to HKLM and HKCR. If there was a way to silently bypass UAC then it would be pointless and everybody would just bypass it.
You could have two applications, the main application does not elevate but it starts a helper application that requests elevation and writes the keys before starting the main program.
Obviously, if you were making your own application portable then you would just add a portable mode to it where it reads from HKCU or a .ini but I suspect you are writing a crappy wrapper for something you did not write. Applications with portable support built in is always going to be better than something bolted on by a 3rd-party.
You could have two applications, the main application does not elevate but it starts a helper application that requests elevation and writes the keys before starting the main program.
Obviously, if you were making your own application portable then you would just add a portable mode to it where it reads from HKCU or a .ini but I suspect you are writing a crappy wrapper for something you did not write. Applications with portable support built in is always going to be better than something bolted on by a 3rd-party.
Thanks
"Obviously, if you were making your own application portable then you would just add a portable mode to it where it reads from HKCU or a .ini but I suspect you are writing a crappy wrapper for something you did not write. Applications with portable support built in is always going to be better than something bolted on by a 3rd-party".
Yes and no...
There is a thing I don't understand:
If I portabilize an application (anyone) without "RequestExecutionLevel" that application write correctly in the registry but not allow dn'd.
If I use "RequestExecutionLevel user" I can't write in registry but support dn'd.
Is this because an user can't write in the registry in Windows?
Why the programmers don't write NSIS with dn'd support without the declaration "RequestExecutionLevel"???
Yes and no...
There is a thing I don't understand:
If I portabilize an application (anyone) without "RequestExecutionLevel" that application write correctly in the registry but not allow dn'd.
If I use "RequestExecutionLevel user" I can't write in registry but support dn'd.
Is this because an user can't write in the registry in Windows?
Why the programmers don't write NSIS with dn'd support without the declaration "RequestExecutionLevel"???
NSIS does not control Drag&Drop. UAC will block drag from unelevated apps to elevated apps. https://blogs.msdn.microsoft.com/pat...trol-and-uipi/ does say there is a way to unblock those messages but it is not recommended. Only the author of the application can call that API so it does not really help you I'm guessing.
Non-admin/unelevated users can only write to HKCU, not HKLM.
In NSIS 3, no RequestExecutionLevel attribute is the same as Admin, in 2.x it is the same as None which Windows treats as Admin+Compatibility stuff. This compatibility stuff might include registry redirect from HKLM to HKCU, I don't remember.
The best solution is to ask the real author of the application to add portable support.
Non-admin/unelevated users can only write to HKCU, not HKLM.
In NSIS 3, no RequestExecutionLevel attribute is the same as Admin, in 2.x it is the same as None which Windows treats as Admin+Compatibility stuff. This compatibility stuff might include registry redirect from HKLM to HKCU, I don't remember.
The best solution is to ask the real author of the application to add portable support.