Main Area and Open Discussion > General Software Discussion

Best Executable Compressor Programs

<< < (8/8)

f0dder:
Anyone know of a freeware .NET packer for 32/64-bit .NET applications?  I found, and downloaded, MPress 1.27, but AVG says it's infected with 2 virii.-kyrathaba (October 17, 2010, 12:19 PM)
--- End quote ---
Don't bother. Really, don't bother. The false A/V positives is reason enough (damn those bastards!), and the gains usually aren't worth it. I wonder about the penalties, though... I suspect you already get some "pessimization" wrt. multiple instances not sharing code in .NET because of the JIT'ed nature, but there's other potential pessimization as well, like reflecting over assemblies.

What's your perceived need of executable compression anyway?

Hypocrisy? - While I'm generally pretty much against executable compression, I do employ it on fSekrit. I'm defending it with "people might need to store their password file online as a single file, and grab it over slow links", but I've been considering whether to keep compressing for future releases.

4wd:
What's your perceived need of executable compression anyway?-f0dder (October 22, 2010, 01:30 PM)
--- End quote ---

The only place I use it is to maximise free space on my "tool" flash drive.

kyrathaba:
To be honest, I don't really have a perceived need for compression.  I've actually wondered, with the storage/performance of PCs nowadays, why compression of executables?  They say it speeds up execution, but how much, really?

I guess I've just been looking for a compressor of .NET apps out of curiosity, really.

f0dder:
Hm, speeds up execution...

The application will load from disk a bit faster - in theory. Thing is, Windows does demand-paged execution, meaning it won't load parts of your application from disk until they're used. This is defeated by exe compression, since the entire module will be loaded at once (I'm not sure how much of a .NET assembly is loaded under normal execution... so perhaps this isn't such a big problem).

There's additional CPU usage because of the decompression, but the decompressors are fast - even on older machines, the time to decompress the additional data is a lot lower than reading data from disk (but again, we're ignoring demand-paging here).

HOWEVER, in reality, your executable is likely to load a lot less slower on a lot of end-user systems, regardless. Why? Anti-malware software. When doing on-demand scanning of executables, the anti-malware software has to decompress the executable before it can scan it - and for safety reasons, it can't just execute the executable's own decompressor, it has to have specific support for the exe-packer used, or run (slow!) sandboxed code emulation.

Navigation

[0] Message Index

[*] Previous page