miniCRUSH 1.00

[comp1]

Good evening!

I've spent plenty of time lately attempting to make the smallest, most compact, portable binaries for file compressors without using any EXE packer or modifying the source code.

So today I am sharing with you guys my "minimized" compiled version of one of my favorite compressors, CRUSH 1.00!

Notes:
- The line that shows the final result after compression (old size, new size) was removed due to compiler issues (and I couldn't figure out how to fix it).
- No performance loss.

Let me explain this a different way:

    CRUSH : 110,592 bytes
miniCRUSH :   9,216 bytes
   SOURCE :   7,891 bytes

Just imagine how many more bytes of data can be stored on your 3.5" floppy disk!

Enjoy and please report any errors and suggestions!

EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.

EDIT #2 Since writing this post, this has become a competition. For those who want to join in the competition, please note that your build will be disqualified if the decompression speed is 10% slower. If it is 11-12%, that's fine because all CPUs are different.

[nikkho]

Good evening!

I've spent plenty of time lately attempting to make the smallest, most compact, portable binaries for file compressors without using any EXE packer.

So today I am sharing with you guys my "minimized" compiled version of one of my favorite compressors, CRUSH 1.00!

Notes:
- The line that shows the final result after compression (old size, new size) was removed due to compiler issues (and I couldn't figure out how to fix it).
- No performance loss.

Let me explain this a different way:

    CRUSH : 110,592 bytes
miniCRUSH :   9,216 bytes
   SOURCE :   7,891 bytes

Just imagine how many more bytes of data can be stored on your 3.5" floppy disk!

Enjoy and please report any errors and suggestions!

EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.

Seems a pretty nice reduction.
Maybe it can be further reduced if you post the source code.

[comp1]

Seems a pretty nice reduction.
Maybe it can be further reduced if you post the source code.

Source is unchanged.

[m^2]

It would be nice if you explained your techniques then.

[comp1]

It would be nice if you explained your techniques then.

I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.

[nikkho]

I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.

Do not see the point to be honest.

[comp1]

Do not see the point to be honest.

For those who want to save every last byte. Making these minimized versions is fun, nothing more. If someone finds this (and possibly other) mini builds useful, then that's great.

[nikkho]

For those who want to save every last byte. Making these minimized versions is fun, nothing more. If someone finds this (and possibly other) mini builds useful, then that's great.

Maybe, but the interesting thing is to know how to achieve it.
On one side, you said source code was the same, so I asume you linked against a minimal RTL, or used different compilation switches.
But then you said you removed the line showing the result, so indeed, source was modified.

[comp1]

Maybe, but the interesting thing is to know how to achieve it.
On one side, you said source code was the same, so I asume you linked against a minimal RTL, or used different compilation switches.
But then you said you removed the line showing the result, so indeed, source was modified.

Let me clarify:

1) You are correct that all the minimizing was done at the compilation stage.

2) I removed that particular line because I was not able to compile with it. THat line prints the old file size and the new file size after compression is complete--hardly a performance-demanding/size-demanding line of code, wouldn't you agree?

That line was removed from the source because of my lack of ability to compile--if that line would have been part of the algorithm, that's a different story. This was a simple "printf" line.

Hope that clears things up.

[Skymmer]

Seems a pretty nice reduction.

Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.

It would be nice if you explained your techniques then.

Maybe, but the interesting thing is to know how to achieve it.

I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.

There are no tricks and there are no techniques.
miniCrush dynamically compiled with Visual Studio 6.0 with linking against the MSVCRT.dll.
Somebody will say: "Wait a minute, why dynamically? msvcrt.dll is the part of almost any version of Windows!"
No doubt. But technically msvcrt.dll is the C and C++ runtime so linking to it means taking a lot of code out of the exe body.
Anyway here is the 8481 byte version.

[nikkho]

Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.

Thanks for revealing comp1 trick. I imagined something like that.

[comp1]

Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.




There are no tricks and there are no techniques.
miniCrush dynamically compiled with Visual Studio 6.0 with linking against the MSVCRT.dll.
Somebody will say: "Wait a minute, why dynamically? msvcrt.dll is the part of almost any version of Windows!"
No doubt. But technically msvcrt.dll is the C and C++ runtime so linking to it means taking a lot of code out of the exe body.
Anyway here is the 8481 byte version.

Competition is fun!

Skymmer's compile was too bloated for me! Here is my new build at 7,680 bytes!

If speed were not so critical, we could go MUCH smaller!

Enjoy!

[Skymmer]

Here comes 6944 bytes

[comp1]

Here comes 6944 bytes

6,656 bytes

[Skymmer]

5920

[comp1]

5920

I think it's fair to crown you as the winner.

The only way I can get smaller is by losing noticeable speed.

Good job, congrats!

[nikkho]

Glad you were the winner Skymmer!

Could you explain the compilation changes to go from 9216 to 5920?

[algorithm]

For Linux users
64 bit 6176 bytes
32 bit 5160 bytes

removing the last line like above can make the 32 bit version under 5000 bytes

[comp1]

5920

I guess I crowned a winner too soon! Let's keep it going folks!

5,632 bytes

Also about 6.5% faster for decompression than Skymmer's version in my tests on my i7 3770k.

[comp1]

5,120 bytes

ENWIK9

DECOMP  VERSION
=====================
10.077  ILYA
10.420  SKYMMER_5920
10.498  COMP1

[fhanau]

Whoa! But how?

[algorithm]

An other one for Linux
32 bit 4788
64 bit 5720

[Skymmer]

Ok. Here comes the 4031 bytes version.
And another experimental one with size of 1688 bytes.

[comp1]

Ok. Here comes the 4031 bytes version.
And another experimental one with size of 1688 bytes.

The 1688 byte version does not work.

But wow...4031 bytes..WOW!

One clear difference between your builds and mine are that the filesizes are not rounded to the nearest .5KB like mine are.

From what I've learned so far either you are stripping away code from the final executable file or you are not using MSVC link program

Either way--great job sir!!!

EDIT: Your latest version does not meet the requirements...HUGE performance loss:

DECOMP  VERSION
=====================
22.744  SKYMMER_4031 
10.358  COMP1_5120

[Skymmer]

Man, I don't really care about your "runtime-generated" rules. This competition is about the exe size.

[comp1]

Man, I don't really care about your "runtime-generated" rules. This competition is about the exe size.

That's ok "man", I don't really care about your attitude issues. I happily crowned you the winner earlier and you get upset when someone points out that your build has some performance loss. CRUSH at that speed makes it lose its magic.

As I mentioned earlier in this thread, exe size is as important as maintaining performance:

EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.

But hey, congratulations on making a 4031 byte version that decompresses 54.5% slower.

I PM'd you for tips/hints but now it's clear that the only thing you do differently is somehow remove the extra padding that rounds the exe filesize up to the nearest .5KB.

[Skymmer]

OK. Please provide the precise rules of this competition. How much of performance drop is accepted and so on. As for

but now it's clear that the only thing you do differently is somehow remove the extra padding that rounds the exe filesize up to the nearest .5KB.

then you're wrong. Even if not - cmon, do the same.

[comp1]

OK. Please provide the precise rules of this competition. How much of performance drop is accepted and so on. As for

then you're wrong. Even if not - cmon, do the same.

Sure, let's say no more than 10% speed loss. If someone's build is 11% slower, that's fine--but 15%+ is too much. I'll update the first post for new arrivals who want to compete.

Also, here is my 4096 bytes version which I've been able to achieve for some time but the performance loss is roughly 10%.

Again, my exe is rounded up to 4KB. Looking at the sections in my fileexe though, the .data is 3072 bytes and the .rdata is 496 bytes...Meaning that is should be 3568 bytes but I don't know to how to remove that extra information in the file that rounds it up.

[Skymmer]

3977 for usual version and 1810 for experimental one.
Usual version has no performance drop comparing to yours. Experimental should work ok for any system. By the way what does your "The 1688 byte version does not work" statement means? Any failed attempt to run some executable is logged in Windows event system. Please provide a detailed info about this issue.
Also. You have additionally modified the sources of Crush by replacing some functions with WinAPI equals but you didn't mentioned it. Why?

[comp1]

3977 for usual version and 1810 for experimental one.Usual version has no performance drop comparing to yours. Experimental should work ok for any system. By the way what does your "The 1688 byte version does not work" statement means? Any failed attempt to run some executable is logged in Windows event system. Please provide a detailed info about this issue.Also. You have additionally modified the sources of Crush by replacing some functions with WinAPI equals but you didn't mentioned it. Why?

When I said it did not work I meant that it would not decompress a file. It would stall for a few seconds and produce no file. Also, I did not modify the source. If modifications occured, the compiler did it. I don't know what WinAPI is. My kmowledge of programming is non-existent.