Takhir
22nd January 2007 16:35 UTC

admin limitations on Vista?
  I have small application (sorry, download is fast inside Russia only, but package is 120 kB, thanks NSIS :) ). The problem is following: on Vista when application starts first time from installer' finish page with admins privilegies from installer as child process (installer running with RequestExecutionLevel or not - both cases Vista displays UAC and elevates level to admin, installers auto-recognition feature), it not gets drag-n-drop messages and some other communication messages as well. The same happen if I start it with 'run as administrator' option later. But if I simply launch it from desktop or start menu icon (execution level 'user', admin not required) all works correct. This behavior not depends on current (start) folder. Brief google search not gave me any good links..

kichik
22nd January 2007 20:55 UTC

It's called User Interface Privilege Isolation. More information about this is available in MSDN.

Takhir
23rd January 2007 06:41 UTC

Thanks, kichik! Nice feature... I added manifest with asInvoker, but this not helped. The only way I see now is to remove 'Run' checkbox from finish page and ask user to start program manually :( But user still can run application as admin.

kichik
23rd January 2007 09:43 UTC

There's some code to handle this in another forum thread:

http://forums.winamp.com/showthread....ighlight=vista

Andres also wrote a plug-in, I think.

Takhir
23rd January 2007 10:09 UTC

Thanks again, sometimes forum search is better then google :)

Anders
23rd January 2007 17:48 UTC

You can try the SAFER plugin.

Use MUI_FINISHPAGE_RUN_FUNCTION and call the safer plugin with SAFER_LEVELID_NORMALUSER level.

SAFER::Exec NORMAL "$instdir\\myapp.exe" 

Takhir
23rd January 2007 19:16 UTC

Thanks, Anders! I not tested it yet, but looks interesting. And I have feature request for 0.2 version :) Now I should write 3 or more lines of code:

if(supportsSafer)

 SAFER::Exec NORMAL "$instdir\myapp.exe"

>else

 Exec "$instdir\myapp.exe" 

Anders
23rd January 2007 20:15 UTC

thats what macros are for, something like:

!macro ExecSAFER _level _cmdline

SAFER::SupportsSAFER

StrCmp$0 0 +3

SAFER::Exec ${_level} '${_cmdline}'

>Goto +2

Exec '${_cmdline}'

>!macroend



>!insertmacro ExecSAFER NORMAL 'calc.exe' 

Takhir
24th January 2007 08:15 UTC

Tested. With SAFER token program fails to open file for write in $INSTDIR. I'll think later if I can use appdata folder for this file, but if I stop program and start it again - all works correct (can write file).

!insertmacro ExecSAFER NORMAL "$INSTDIR\${APP_EXE}"

onad
24th January 2007 11:34 UTC

IDEA:
1) Copy a manifest document were level is asInvoker (asInvoker is the new term on Vista versoin >=Beta2) to the application directory where the application resides you want to start.
2) Start the application
3) Delete the manifest document

NOTE:
(XML data is called a "XML document", not "XML file")

Takhir
24th January 2007 11:44 UTC

2 onad:
I wrote about this in my second post :)
Not works :(
Looks like child thread inheritation priority is high then manifests (while I not tested embedded manifest, but file priority is higher).

kichik
24th January 2007 11:47 UTC

There's an article on MSDN that suggests bootstrapping the installer with another application that'd run as the user and will later also execute the installed application. I really hate this method, but it does work.

Anders
24th January 2007 15:03 UTC

Originally posted by Takhir
Tested. With SAFER token program fails to open file for write in $INSTDIR. I'll think later if I can use appdata folder for this file, but if I stop program and start it again - all works correct (can write file).

!insertmacro ExecSAFER NORMAL "$INSTDIR\${APP_EXE}"

Takhir
24th January 2007 15:39 UTC

I tested program with app data folder. Launched from installer it could not write to application data/company/prog_name as well. The only place where it could was GetTempPath(). I can use tmp folder for this file, but program saves other (user's configuration) file to app_data, so this is a problem. File is too big for registry (access to registry works correct)..

onad
24th January 2007 16:12 UTC

Anders, you can write there because of Vista Virtualisation, this is a kind of backwards compatibility layer on Vista to solve problems with "old" software.

IDEA1)
Do a run dll of an INF file there you can add an RUN entry, since the INF format description as not fully made public by MS this can be difficulult

IDEA2)
As menationed before a bootstrap application which starts the installer with admin privileges and if finished starts another app with regular priviliges

IDEA3)
Downgrade the options of the running process, hmmm

IDEA4)
Set app compatibility flag to W98, test if works?

IDEA5 ??)
Tell it to us please, be creative in thoughts....

kichik
24th January 2007 16:27 UTC

What about CreateLowProcess from MSDN. It looks promising, as long as you can find out the SID for the medium integrity access level. There's code a page below CreateLowProcess that retrieves the current integrity access level. It can probably be used from a normal process to get that SID.

Looks like SAFER is a wrapper for this as the terms are pretty similar, but who knows... I have to get myself Vista access again :(

Anders
24th January 2007 16:33 UTC

You can inspect the process token SAFER creates with process explorer, its probably not the exact same thing as running the program manually

There is another way to start a program non elevated on vista, documented @ http://www.tweak-uac.com/programming/vista-tools/ (RunAsStdUser) I dont have Vista so I can not test or implement it