amoneriot
24th November 2009 19:14 UTC

IE doesn't load after install on Vista
Hello All,
I'm a relative newbie to NSIS but I love it already and have dabbled in it enough to fix all the UAC and signing issues I was having. But now, this one issue is eating up my time and I can't get any direction on what to look out for. The following code snippet works fine on XP and Win7 but doesn't work on Vista. It's supposed to load IE with a website but it doesn't work on Vista only. I went through the forum and it doesn't look like it's been discussed before. I tried using exec instead of execshell as well. What could I be doing wrong here ? Is there anything I can try ? Really appreciate some pointers at this point.

Function .onInstSuccess
Push $0
ReadRegStr $0 HKCR "InternetExplorer.Application\CLSID" ""
ReadRegStr $0 HKCR "CLSID\$0\LocalServer32" ""
ExecShell "open" "$0" "http://www.google.com/" SW_SHOWNORMAL
UAC::Unload
Pop $0
FunctionEnd

Thanks.

Anders
24th November 2009 19:26 UTC

Why is there a call to the UAC plugin there? If you are using that, ExecShell is not the correct ting to use. Also, you probably don't want to use the open verb, try a empty string

amoneriot
24th November 2009 19:54 UTC

The example tutorial on UAC talked about releasing the UAC plugin on successful installation, which is why there's a cleanup call there.
This same code works fine for XP and win7. why wouldn't it work for Vista ? Anyways, I took your suggestion and tried calling ExecShell with an empty string and that didn't make a difference. Previously, I had tried using exec as well but that didn't work as well. If execshell isn't the correct thing to work and exec doesn't work, what else should I be trying ?

Anders
24th November 2009 20:53 UTC

well, for one thing, if you are using the uac plugin, you should call the uac version of execshell. But why would you want to force IE on your users, just specify the url as the command, no need to hunt for the .exe

amoneriot
24th November 2009 22:04 UTC

I'm installing a toolbar for IE, which is why I need to have IE load up. I tried using UAC::exec as well as nsexec::exec but it didn't make any difference. Details in the new sample code below. I hope I got the arguments right. The worst part of all this is that the errorlevel isn't set, which tells me that the function should have worked. Could this be a real bug for which we need a bugfix ? I can't think of trying anything else. Does exec, execshell, etc. work with IE 7.0 on Vista ?

Function .onInstSuccess
Push $0
ReadRegStr $0 HKCR "InternetExplorer.Application\CLSID" ""
ReadRegStr $0 HKCR "CLSID\$0\LocalServer32" ""
;ExecShell "open" "$0" "http://www.msn.com/" SW_SHOWNORMAL
;UAC::Exec '' '"$0 http://www.msn.com/"' '' ''
nsExec::Exec '"$0" http://www.msn.com/'
UAC::Unload
Pop $0
FunctionEnd

demiller9
25th November 2009 01:02 UTC

On my system (Vista Home Premium x64) the reg value for LocalServer32 has "%ProgramFiles%\Internet Explorer\iexplore.exe". You probably need to ExpandEnvStrings before the nsExec::Exec call.

Anders
25th November 2009 07:18 UTC

well, if you want to force IE, you could use the supported COM interface for automating IE

amoneriot
25th November 2009 18:39 UTC

Thanks a lot for your suggestions. I made some progress finally. nsexec::exec seems to work, but with the side effect that when my installer doesn't quit until IE quits. Is there a way to fix that ? Also note the syntax with which nsexec worked. There are no double quotes around the variable.

ExpandEnvStrings $1 "$0"
nsExec::Exec '$1 http://www.oneriot.com/install_failed'

If I do the following, nsexec will not work.

ExpandEnvStrings $1 "$0"
nsExec::Exec '"$1" http://www.oneriot.com/install_failed'

why is that so ? that's what the examples say I should be doing, but that doesn't work. Also, why did nsexec work on Vista, but not exec or uac::exec or execshell which worked just as I wanted on XP and win7 ? I could use some learning here.

demiller9
25th November 2009 19:37 UTC

The Exec command fails with the quotes because the reg value already has quotes around it and you end up with two sets of quotes.

amoneriot
25th November 2009 19:40 UTC

Thanks a lot for your help. I think all this time my real issue was that I didn't understand well how variables were supposed to be used. Not that I understand them fully now, but I'm learning a lot. Sorry for getting you thinking about something completely different than where the problem was. Maybe my execshell will now work as I had planned.

Anders
25th November 2009 20:38 UTC

I just created http://nsis.sourceforge.net/Open_URL...COM_automation , you could try that for a non hacky solution

amoneriot
8th December 2009 20:21 UTC

I tried this on Win7 IE8 and it didn't work. I cut-pasted the code there as it is and then tried to call it using uac::execcodesegment but didn't work.

Anders
9th December 2009 15:09 UTC

var ie = new ActiveXObject("InternetExplorer.Application");
ie.Navigate("http://www.msn.com");
ie.visible = true;

podnuh
10th December 2009 14:39 UTC

Presumably your installer is running with elevated privileges (because you are using the UAC plug-in). That means that when you start IE (using the methods you have been describing) it is also running with elevated privileges (because it inherits the privileges of the process that start it). This is something that you probably don't want to do, and which may be contributing to your problems with Vista.

Since you are using the UAC plug-in, you should use the UAC::Exec function to start IE with the same privileges as the user who originally invoked your installer. In order to satisfy yourself that the UAC::Exec function works, as a start I would suggest calling UAC::Exec with exactly the same syntax described in the instructions and with the path for IE hard coded as follows (Notice the use of both single and double quotes in the command):

UAC::Exec '' '" C:\Program Files\Internet Explorer\iexplore.exe "' '' ''

You are correct to dynamically look up the correct path for IE. But your first step should be to verify that the UAC:Exec function works (and it should). After that, you can add additional layers of complexity to find where the breakdown is occurring.

I hope this helps.