haigha
20th April 2007 16:38 UTC

Vista and large installer causes long CD spin
I've been using NSIS installer for a number of years. Thanks for all the great work and community support guys :)

Recently, we've run into a problem on Vista. Our installer is huge (~650 MB) because it contains lots of videos. We use compression so that we can fit more videos on a CD than otherwise (LZMA is quite nice in this regard).

The problem is that on Vista when we insert the CD it spins for about three or four minutes before running our installer and then it seems to copy the installer to the hard drive taking several more minutes. This is not a problem we have seen on any other Windows version.

I spent some time on this yesterday, including updating to the latest version of NSIS, and came up with the workaround of creating a separate archive with the video files and calling it with the command:

ExecWait '"$EXEDIR\7z.exe" x Videos.zip "-o$INSTDIR" -r -aos -psecret'

instead of including the videos in the main installer.

While this works, it isn't as elegant as I'd like because it pops up a CMD window and also it requires including 7z.exe and 7z.dll on the CD. Since this functionality is already built into NSIS, I'm wondering if there is a better way to achieve having the videos in a separate archive and if it's possible to show the results in the NSIS installer progress window rather than the external CMD window.

Thanks for any ideas.

haigha
20th April 2007 16:42 UTC

Let me add:

- this problem happens on a variety of machines here and on customer machines so it doesn't seem to be AntiVirus or AntiSpyware related

- I tried an NFR copy of Setup Factory I have for grins and it exhibits the same problem with a large installer; I won't be using SF since NSIS is superior IMO

Comperio
20th April 2007 17:30 UTC

We've been testing Vista at our workplace (not with NSIS, but for our own InstallShield and MSI-based installations.)

I've noticed when we right-click and choose "run as administrator", it takes a long time finally give the "cancel/allow" prompt. But mostly this has been in our own installations.

Since none of our installations are currently signed. My theory is that Vista seems to be checking the entire file for signatures before it displays the prompt. However, I've not had a change to really thoroughly research the problem. (Our installations aren't that big, so the problem has been minimal.)

I just thought I'd pass this along in case it might help you get a solution. (Maybe a test would be to disable UAC on a Vista machine and see if you still get the same results.)

Sheik
20th April 2007 17:34 UTC

Now, I have *no* idea whats causing the problem, but while you wait for one of the big guys to give you suggestions,
this *sounds* like the problem with the Installer needing something embedded in the installer that wasn't "reserved", hence it has to sit there and chug away uncompressing everything before being able to run your installer...

Are all the files you need to run your Installer options "reserved" ?

Specifically, using "ReserveFile" on all your .ini, plugins, etc?

Scott

kichik
20th April 2007 18:22 UTC

As already said, it's probably Vista looking for some kind of signature. It might be the digital authenticode signature and it might be a signature telling it to run in compatibility mode. The first might be solved by signing the installer using a certificate. The second can be solved by adding a manifest with RequestExecutionLevel.

NSIS doesn't support external compressed files, so if you want to use those, keep the 7z.exe line but run it with nsExec so it won't show the command prompt.

haigha
20th April 2007 20:22 UTC

Thanks for the ideas.

I did try digitally signing the installer yesterday and it had no effect on the slow startup. I also tried turning off the crcCheck but it didn't affect the start up time either.

However, I didn't see the RequestExecutionLevel stuff until I had finished separating the videos into an archive and using 7zip yesterday. I just tried that with the videos back inside the installer and I still have the long delay with it signed and RequestExecutionLevel set to admin.

I tried out nsExec::ExecToLog command. One problem with it is that there seems to be a buffer on the output. I set tried setting the timeout to various values 1000 ms and it still takes a number of seconds before there is any output and it seems to come in spurts (1k or 2k?) (this may be a problem with 7z.exe only doing buffered output when it is not connected to CMD's stdout?).

I found that a further limitation of using the external archive is that NSIS no longer knows how big the install size is (the install size now shows incorrectly in Add/Remove programs).

Does anybody have more ideas?

Thanks.

haigha
20th April 2007 20:27 UTC

Additions:

I hadn't heard of the ReserveFile option that Sheik mentions but if that were the problem I would not expect it to only occur on Vista.

I haven't disabled UAC on the Vista machine since this needs to work with it enabled but it may be a good test to help isolate the problem.

Yathosho
21st April 2007 00:34 UTC

you can set the installsize manually.

haigha
21st April 2007 01:20 UTC

I'm not sure I understand your point. From reading the docs, the AddSize only changes the size of a section. If you're referring to the wrong size being displayed in the Add/Remove programs section, it is showing 8.6 GB for some reason there but the install is under 800 MB. I do not use AddSize in my script.

Originally posted by Yathosho
you can set the installsize manually.

kichik
21st April 2007 10:34 UTC

Yathosho was talking about the size that appears in the components page and the directory page as the required installation size. The Add/Remove size is explained by Raymond Chen on his blog.

Try passing -bd to 7z.exe so it'd stop buffering the output. It seems like it should do the trick, but I wasn't able to get it working.

haigha
22nd April 2007 22:45 UTC

Thanks for the info. The -bd flag didn't improve things for the 7z output. For now, I think it will be preferable to use the regular ExecWait command even though it's uglier.