Hi, I am sure we can shrink the installer more with better compression settings. Unfortunately I am not able to try these theory now because I have problem with Windows based build system. So any participation related to this topic is welcome The current situation: We are using double compression for creating LibreOffice install kit for Windows: 1) Compressed CAB file contains the installable files 2) The installation system is packed into the NSIS based preinstaller. According to solenv/bin/modules/installer/globals.pm solenv/bin/modules/installer/windows/msiglobal.pm setup_native/source/win32/nsis/downloadtemplate.nsi For cab file compression we are using: globals.pm cabfilecompressionlevel = 7 and msiglobal.pm .Set CompressionType=LZX .Set Compress=ON .Set CompressionLevel=cabfilecompressionlevel=7 options. For NSIS based presintaller we are using: SetCompressor lzma option. So currently we use a high compression for cab file generation which produces small file but takes more time. Then recompress it with lzma that may not able to compress so much but takes long time. However we use NSIS in SetCompress auto mode that might causes compression test and if it is not enough good it drops the compressed file and use the original cab file. My idea is to use only one tight compressor and the other archiver should used in store or zip mode. So there is to way to rethink the compression practice: 1) Maximize the compression of CAB files and minimalize NSIS compression: This produces a smaller cab file but if the installer request files in non other sequence as compressed may we pay penalty in uncompression time. For this we can use CAB compression settings: .Set CompressionType=LZX .Set Compress=ON .Set CompressionMemory= 21 (We can eliminate .Set CompressionLevel=cabfilecompressionlevel=7 maybe it is useful for MSZIP compression (or not)) For NSIS we use simple store or small compression: a) SetCompress Off SetDatablockOptimize On b) SetCompress Force SetCompressor zlib SetDatablockOptimize On OR 2) CAB file only store the installer's files and NSIS compression set to high: This may produces the smallest installer so I would try this for first. The compression of NSIS takes time but decompression speed is and also the installation is fast. The preinstallation may takes dictionary equivalent memory usage so we should not set Dictionary size larger than 32-64 MB. The only negative effect, the preinstalled (unpacked) installer uses same diskspace as the fully installed package (For installation we need at least twice space of full installation). For this we can use CAB store setting: .Set Compress=OFF For NSIS we use simple store or small compression: SetCompress Auto SetCompressor /SOLID lzma SetCompressorDictSize 64 SetDatablockOptimize On References: http://msdn.microsoft.com/en-us/library/bb417343.aspx http://www.symantec.com/connect/articles/advanced-nsis-scripting-part-1 "The SetCompressorDictSize accepts one setting, which is the number of megabytes to use for the dictionary size. The greater this number, the more memory is required to execute the installation. The memory requirement to run the installer will be the dictionary size plus about 4 megabytes or so. The default dictionary size is 8 megabytes. You can get a slightly better compression ratio by changing this to 16, 32, or 64. You can set this up to 128 or possibly higher, but you won't notice much difference when you use a dictionary size greater than 64. With that in mind, I suggest that you use "SetCompressorDictSize 64", but you can experiment with this value to see what works best for your particular installer." http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.3 What is your opinion? Can somebody test it on a real Windows build system? -- Best regards, Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com My favorite projects: OxygenOffice Professional <http://ooop.sf.net/> - office suite - for everybody | Magyarul <http://hun.sf.net/> - In Hungarian Blog <http://bit.ly/10ucTR> | Support <http://bit.ly/eYZO6> Follow me <http://bit.ly/gJuJZ>, if you can <http://bit.ly/kDocB>
Attachment:
signature.asc
Description: OpenPGP digital signature