- NSIS Discussion
- WriteUninstaller and BZIP2 - bad combo
Archive: WriteUninstaller and BZIP2 - bad combo
Mad Doggie
5th September 2003 03:28 UTC
WriteUninstaller and BZIP2 - bad combo
I have created a number of NSIS installers in the 15-20MB range, compressed using BZIP2. The "raw" install data is in the 220MB range.
I've found that the WriteUninstaller instruction forces the installer to extract all of the data, which takes a while to do since there's 200MB+ to write. I've used ReserveFile judiciously as early in the installer as I can, and it only seems to want to do this when the WriteUninstaller instruction is executed.
I tried making the Uninstall section the 1st or 2nd section before all of the data, but no difference. Why is this?
Cheers!
Luke
Mad Doggie
5th September 2003 03:32 UTC
One other note - it only started doing this when I ported my installer to the Modern UI.
Luke
Joost Verburg
5th September 2003 07:48 UTC
Did you check the reserve file info in the Modern UI Readme and used these macros?
kichik
5th September 2003 11:16 UTC
It happens because the uninstaller data is written after processing the script. It can't predict ahead how big the uninstaller block will be, so it can't allocate enough space in the installer block before compilation starts.
Why not just put the WriteUninstaller command in the last section?
Mad Doggie
5th September 2003 14:31 UTC
OK, I'll make the section that writes the uninstaller the last one and we'll see what happens. FWIW, I'm using the following MUI reserve file macros:
MUI_RESERVEFILE_SPECIALINI
MUI_RESERVEFILE_INSTALLOPTIONS
MUI_RESERVEFILE_SPECIALBITMAP
I'm not sure if it's the reservefiles because I don't get an issue until the WriteInstaller command....
Cheers!
Luke
kichik
5th September 2003 15:01 UTC
Those only reserve files, if you'd really want to put the WriteUninstaller on top you should have reserved the uninstaller datablock. But you can't know its size ahead, so it can't be done.
Mad Doggie
5th September 2003 15:39 UTC
I tried putting the WriteUninstaller in the last section, but no luck either. I started a build before I left for the office, and the difference was that I didn't use the MUI for the uninstaller pages, just the installer part.
I noticed that when I switched to MUI, the uninstaller block was reported to grow from ~4K to ~50K. I'm not sure why, but I don't really care too much since the UI of the uninstall doesn't concern me. I never had this pre-MUI, so maybe the uninstaller size makes a difference.
Gawd, it's a royal pain compressing 220MB each time. :(
Cheers!
Luke
kichik
5th September 2003 15:45 UTC
Can you attach the script?
Mad Doggie
5th September 2003 16:05 UTC
Originally posted by kichik
Can you attach the script?
Sure, when I get home around 6 ET. It's got the basic sections, with three or four includes of common functions and installer attributes.
Thanks for your prompt reponse!
Luke
Mad Doggie
5th September 2003 22:47 UTC
OK... here's the basic cript
Originally posted by kichik
Can you attach the script?
OK - here it is.
kichik
5th September 2003 23:08 UTC
What do checkComponent, checkFSSound, checkFSUIPC and checkURL do? Do they add any files?
Just to clarify, you're saying that WriteUninstaller re-reads the entire installer data block, re-extracting your 200MB of files even after all of the files were extracted during installation. Is that right?
Mad Doggie
6th September 2003 03:07 UTC
Originally posted by kichik
Just to clarify, you're saying that WriteUninstaller re-reads the entire installer data block, re-extracting your 200MB of files even after all of the files were extracted during installation. Is that right?
The Macros check for a file on disk or a registry entry, and selectively disable/enable some sections. They don't write any files. All they do are ReadRegStr, IfFileExists and GetDLLVersion.
Actually, here's an interesting bit - the installer doesn't actually extract itself on load. It takes a touch longer to load than before, but it doesn't have the "checking installer...." little dialog box when it CRC checks itsself, and doesn't extract itself on load.
I don't understand the innards of MUI, but I can say that the installer behaves differently than it did before MUI was added in areas I didn't expect. (Of course, it could just be that I'm not using b3 anymore, too.)
Thanks again for your help. Do you have anyone else that's cramming 220+ MB into an installer?
Cheers!
Luke
kichik
6th September 2003 09:36 UTC
The checking installer window for the CRC check was broken in a certain CVS veresion. Which version (or from which date) of makensis.exe are you using?
MUI adds some files to the installer. It adds InstallOptions.dll, some bitmaps, some INI files and StartMenu.dll if you're using it. If the script is not ordered right or the reserve macros are not used some of those files may be tacked to the end of the data block forcing the installer to run through the entire data block to get them which takes time. In case of whole compression (used by default with bzip2) it needs to decompress the data as it goes too which makes it even slower.
If you encouter more UI or script delays because of decompression please tell us and we'll see what can be improved.
As for other people with large installers, try some from this thread. That issue hasn't been resolved yet, but I do have the plans ready for the next version.