if makensis could choose compress method
for example
bz2
cab
ace
rar
and so on
I don't know which of them is open source.
but i found the ratio of nsis isn't the best.
but her head blcok seems tiny.
Archive: if makensis could choose compress method
if makensis could choose compress method
for example
bz2
cab
ace
rar
and so on
I don't know which of them is open source.
but i found the ratio of nsis isn't the best.
but her head blcok seems tiny.
that is one of the best features: low over head size. you have to enlarge the size when you add new features.
adding all of those compression formats could add a but much, but i'm not really an expert (justin?)
Well, here's the deal.
zlib is good and balanced and free.
bzip2 can be better, but isn't always, and has other downsides.
rar is great, but is it free?
likewise all the others. If there was some way of using lz32.dll or whatever that didn't have downsides, I'd be up for it.
Anyway, perhaps I will make it easier to swap out codecs, but it will still require a recompile of makensis and exehead.
-Justin
Cab SDK can be downloaded from here: http://msdn.microsoft.com/library/en...s/cab-sdk.exe.
Maybe justin can do something with it... (delete it
afterwards :)
cristi.
Originally posted by justinI hacked up v 1.44 using LZ compression and the microsoft compress.exe. The problem is that unlike with zlib there doesn't seem to be a way to expand data that is simply in memory..
Well, here's the deal.
zlib is good and balanced and free.
bzip2 can be better, but isn't always, and has other downsides.
rar is great, but is it free?
likewise all the others. If there was some way of using lz32.dll or whatever that didn't have downsides, I'd be up for it.
Anyway, perhaps I will make it easier to swap out codecs, but it will still require a recompile of makensis and exehead.
-Justin
I'm all for making multiple compression mechanisms available from an #define in config.h.. Just a quick test of microsoft's lz32 (compress.exe) shows that for me it is not as good as zlib, as far as compression ratio at least (obviously it would require less code than zlib). Perhaps we could integrate bzip2, but then we'd really want to compress the whole datablock together, across file boundaries... Anyway..
-Justin
yep, agreed microsoft's LZ isn't as good as ZLIB.
Using the -zq7 option with compress.exe .. on makensis.exe (a recompiled version, admittedly) 85436 - 89769, 95% saving.
But of course to expand this you need the blockbuster lib in the cab sdk.. just the sample application to expand cab files comes in at 55kb (using the CRT, I couldn't be bothered to rewrite it in raw win32 code, but that may shave 20kb or so off).
--> for all but very small installers, LZ is useless... I vote for zlib.
/me will shut up now giving useless ideas..
I'm figuring that bzip2 (as well as zlib) would do a lot better in terms of compression if it could work across more than one file at a time. I'm going to implement compile-time options for both compression system (zlib, bzip2, or whatever) as well as whether it is in the current easy method (meaning you can seek around in the data a lot, each file compressed separately), or the slower hopefully more efficient space-wize method of compressing them all together. The problem is, the installer may need to move around in the compressed data. The solutions:
Be sure to check out my thread about solid compression.
Originally posted by justinA good solution to the above problems would be a third option:
I'm figuring that bzip2 (as well as zlib) would do a lot better in terms of compression if it could work across more than one file at a time. I'm going to implement compile-time options for both compression system (zlib, bzip2, or whatever) as well as whether it is in the current easy method (meaning you can seek around in the data a lot, each file compressed separately), or the slower hopefully more efficient space-wize method of compressing them all together. The problem is, the installer may need to move around in the compressed data. The solutions:
- write out the uncompressed data as it is uncompressed to a temp file.
- when a seek back is needed, start from the beginning and get seekign.
The benefits of the first one is that if the installer has to jump around a lot, it already has teh data cached and is less CPU intensive. But it can require a bit of disk space, and be more disk intensive. The benefits of the second method are that it requires no extra disk space, and as long as the items in the installer are sequencial (and especially if the datablock optimizer is off), it will be even faster.
Perhaps the installer can pick one of the two modes, based on disk space, as well as how much out-of-order code there is in the installer. I'll be experimenting with this.
So there will basically be in config.h:
#define NSIS_COMPRESS_FILE
or
#define NSIS_COMPRESS_WHOLE