kkrunchy: pretty good executable compression.

kkrunchy is a small exe packer primarily meant for 64k intros. It's relatively useless for anything else actually, because the depacker was relatively slow in older releases (about 1-2MB per second on my machine) and is dog slow in the newest version (about 90-120k per second for typical data on my P4 2.4GHz). kkrunchy also doesn't try to pack DLLs and can't handle exports or TLS (thread local storage) - as said, it's meant for 64ks.

What it does have is very good compression (on 64ks, notably better than anything else I've tried). So it might be helpful if you need a few extra bytes. Or a few extra kilobytes - say, 10 or so :) (yes, that's actually happened on some intros).

Using kkrunchy

Well, there are two versions to pick from, kkrunchy 0.23alpha and 0.23alpha2 - I'll just call them a and a2 from here on. kkrunchy has commandline help that should be pretty self-explanatory, except it isn't particularly up to date (--new does nothing, and neither do --good or --best in a2). The "reference size" (specified with --refsize) is just there in case you're aiming for, say, 64k: you'd specify "--refsize 64" and kkrunchy tells you how many bytes you are away from that goal (to byte precision; far better than looking at file sizes, which are usually aligned to 512 byte boundaries).

Important: kkrunchy performs a (reversible) transform on input code to make it compress better. This is far more sophisticated and effective than the relative-to-absolute jump address transform most executable packers do, but it also means that having stuff inside a code section that's not actually x86 code can hurt compression severely. Always make sure that's not the case or you can easily lose a few kilobytes! Care must be taken especially with NASMs “incbin” directive and most bin2obj-style tools.

Advanced features

Version a also has a pretty nifty feature: the kkrunchy pack ratio analysis. basically, kkrunchy can use .map or .pdb files (the latter only if you have the debug information access SDK or DIA SDK installed) to give you a rough estimate of how well certain functions, arrays etc compress. The .map file has to be in the same directory as the executable to be compressed and has to have the same name (except the extension ofcourse), so e.g. for an "intro.exe" kkrunchy would look for "intro.map" (.pdb files' positions are mentioned in the debug information, so no special rules there).

What you get is a ".kkm" file (kkrunchy mapfile) that lists all functions, classes etc. with their unpacked size and their packed size, and sorted by the packed size (so you can get an idea of where you should optimize). This isn't perfect: the packed size is only an estimate, especially for code (kkrunchy doesn't compress individual bytes, and for code, it doesn't even compress the actual code in your executable, but rather a transformed version). Furthermore, some things may get assigned wrong sizes as debug information isn't perfect - this goes for both .map and .pdb files, though .pdbs are usually a lot better.

Also, kkrunchy packs a memory image of the executable, which means that uninitialized data sections are filled with zero by kkrunchy and then packed together with the rest - so if you have large unitialized arrays, those will show up with very high unpacked sizes and very low packed sizes in the .kkm file; don't get confused by that :)

Version a2 doesn't have any pack ratio analysis yet because it requires a slightly different packing procedure and I haven't gotten around to writing it yet.

Compatibility with Win9x

Yes, kkrunchy-packed executables can run under Win9x and ME (not that it's much of an issue nowadays). You have to be careful though, kkrunchy moves the base address of the executable down, and Win9x doesn't like programs with a base address smaller than 0x400000 (4MB). Unfortunately, that is the default image base address when using the MS linker; just specify the image base address explicitly (0x800000 usually works fine) to work around that problem. kkrunchy will output a warning if the problem occurs, so you should notice it (and if you don't want to support Win9x, just ignore it).

Is it really good?

Well, we (Farbrausch) certainly use it, and so do a lot of other people who make 64k intros - including Conspiracy, Equinox, Fairlight and RGBA - so I guess it's good enough. :)

I have a problem / It doesn't work on my intro / I've found a bug

Well, drop me a mail and I'll see what I can do - but don't hold your breath, I'm pretty busy and usually only fix bugs if they're endangering an intro release :)

Contact

You can reach me via mail at ryg(a)theprodukkt(dot)com, should the need arise.

Why no source code?

It's rather messy and in a pretty sorry state right now. I've released the most important part, disfilter, as open source here.

Ok, where can i download it?

Here: