Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Foobar2000 and UPX compression, why not? (Read 3687 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Foobar2000 and UPX compression, why not?

I was wandering if there's any reason why not to use the UPX compression on a Foobar2000 portable installation.
Foobar200 it's full of .dll and stuff like this that can be compressed a lot with free software like this.
I tried to compact my portable installation and from what i saw there's no issue, but i've still not tested all the features...

Do you think there could be any problem in using it?

PS: i've shrinked my foobar2000 folder from 36MB to 17 with the compactor.

Foobar2000 and UPX compression, why not?

Reply #1 –
Are you running so low on space that 19MB matter?
It's only audiophile if it's inconvenient.

Foobar2000 and UPX compression, why not?

Reply #2 –
On a usb pen drive every MB matter, that's why the portables are most of the time compacted with softwares like the one i linked 

Foobar2000 and UPX compression, why not?

Reply #3 –
At the speed bigger and bigger storage sizes become available for cheap we already passed the point where it matters all that much in my opinion.

I run around with a 16GB pendrive which is not exactly the most expensive thing nowadays, containing pretty much every program I'd ever need, which takes up maybe one GB tops.

Foobar2000 and UPX compression, why not?

Reply #4 –
I have 4GB of app in my pendrive... if the software wasn't compressed at all with UPX i could have 6 or 7, and this mean...less space for my music
I got your points of view, but the question was "why not"?
Technically, could there be any reason?

Foobar2000 and UPX compression, why not?

Reply #5 –
I don't know how this compression tool works in detail, but most programs probably expect unobstructed access to the file system. There is likely no real problem with it if it works, but you just never know until you try, and that alone is a much bigger hassle than shaving off filesizes in the order of tens or lower hundreds of MB, imho.
It's only audiophile if it's inconvenient.

Foobar2000 and UPX compression, why not?

Reply #7 –
UPX will likely mess with debugging features, crash report handling and the troubleshooter system. You're free to use it but you're on your own you get crashes or alike; crash report submissions probably won't work due to exe signature mismatch and even if I wanted to investigate crash reports from your system it would be much more work for me due to my archived debug symbols not matching your exe/dll signatures anymore.

There is also an automated system that gives "crash caused by XXXXX" replies when submitting crash reports matching known problem patterns; UPXing stuff will probably mess it up even if the reports don't get rejected for mismatching foobar2000.exe signature.

I'd personally format the USB stick in NTFS and use NTFS file compression on your binaries.
Microsoft Windows: We can't script here, this is bat country.

Foobar2000 and UPX compression, why not?

Reply #8 –
Quote from: CoRoNe on
For a reason "why not", I came across this interesting comment.


The fact that uncompressed DLLs can load into memory once and be shared between multiple calling threads (but a compressed self-extracting DLL will be extracted to a new memory space for each thread, so 4 threads wastes 4 times the memory) points towards Peter's solution as the optimum - compress the DLL file in the file system (e.g. NTFS) not with a packager and economise on both memory usage and flash storage, not flash storage at the expense of RAM. That ought to work for all your apps, and optimally, you might even unpackage any packaged apps and compress them on the file system instead.
Dynamic – the artist formerly known as DickD

Foobar2000 and UPX compression, why not?

Reply #9 –
Quote from: Dynamic on
(but a compressed self-extracting DLL will be extracted to a new memory space for each thread, so 4 threads wastes 4 times the memory)


Any proof?
For example, BASS. BASS.DLL and its plugins ARE packed with Ian's own homebrew packer/protector, and are fully thread safe.

Foobar2000 and UPX compression, why not?

Reply #10 –
No proof to offer. I guess we can say if this is a problem there are exceptions based on how its done and where the threads originate? In other words, good design with packing in mind, can avoid any problem, and I have every reason to believe you about BASS.

I guess it depends if the DLL unpacks every time it's called by a new thread. I'd have thought a DLL that was not designed for packing and packed later by the end user is more likely to show the wasteful behaviour and a better solution than packing the DLLs in a self-exectuable way is to compress them on the filesystem. I'd have thought if you lost out at all on compression strength via the FS you might gain back as much by not needing the unpacking code in each application or DLL.

TBH, I've never tried packing third party DLLs to know whether there's a real problem and perhaps I should have said "The assertion" rather than "The fact" in my previous post.

Still think the FS compression approach (usually can be applied to a specific folder only) makes most sense for the OP. For developers, design for packers is fine and dandy.
Dynamic – the artist formerly known as DickD
 

Foobar2000 and UPX compression, why not?

Reply #11 –
And the unpacking code isnt much, varying on the packer. I seen code in a few hundred bytes, and my own personal packer, which uses LZMA, has a stub size of only 4-5kb. Not much RAM at all....then again, most of that size is the actual NASM based LZMA decompressor, unlike UPX, which uses a much more convoluted method of compiling LZMA into a stub.