Live data from Hacker News

UPX – Ultimate Packer for Executables

upx.github.io

21–30 of 82 posts

Re: UPX – Ultimate Packer for Executables

#21
post #18
post #15

UPX still works great when used with Go executables. We use it heavily to compress some of our Docker image executables [1]. [1] https://github.com/znly/docker-protobuf/blob/master/Dockerfi...

It should work on almost every binary. The exception are NSIS installers, self-extracting archives (exe rar files), files with IDL interfaces. When NSIS starts they will try to open it's own exe file and find the section in which it's packed data is stored. But UPX will remove those sections and create .UPX section with compressed data.

You can actually set NSIS to UPX-pack its stub, if you're so inclined, but the stub is pretty small already.

Re: UPX – Ultimate Packer for Executables

#22
post #18

Earlier quoted context omitted.

It should work on almost every binary. The exception are NSIS installers, self-extracting archives (exe rar files), files with IDL interfaces. When NSIS starts they will try to open it's own exe file and find the section in which it's packed data is stored. But UPX will remove those sections and create .UPX section with compressed data.

You can actually set NSIS to UPX-pack its stub, if you're so inclined, but the stub is pretty small already.

This isn't what I meant. If you try to run UPX on someones NSIS installer the resulting file will fail to launch.

Re: UPX – Ultimate Packer for Executables

#23
post #20

Earlier quoted context omitted.

I dunno know. But this method worked for years!

See my update. You could only stop kids, who tried to use UPX unpackers.

Nice to know!

Well, It was another protection layer for, like you sad, to keep bad kids away.

This was 10 years ago already.

Re: UPX – Ultimate Packer for Executables

#24
post #20

Earlier quoted context omitted.

See my update. You could only stop kids, who tried to use UPX unpackers.

Nice to know! Well, It was another protection layer for, like you sad, to keep bad kids away. This was 10 years ago already.

Armadillo from Silicon Works is what anyone used if they were serious. You haven't met my friends Olly and Ada ;-)

Re: UPX – Ultimate Packer for Executables

#25
post #22

Earlier quoted context omitted.

You can actually set NSIS to UPX-pack its stub, if you're so inclined, but the stub is pretty small already.

This isn't what I meant. If you try to run UPX on someones NSIS installer the resulting file will fail to launch.

When I first found upx I did this a couple of times only to fail pretty badly and then I stopped doing it. This was like 7-8 years ago when I first tried the portable version. Never found the cause till today.

Re: UPX – Ultimate Packer for Executables

#27

I used to use this a lot, back in the bad old days, when drive space was at a premium. These days I struggle to fill my hard drives no matter how wasteful I am with downloading videos and not bothering to clean up afterwards... and the amount of hard drive space you can buy per dollar keeps growing faster than I can fill my disks. Much trickier issues to tackle are speed (unless you go with SSD's, but then you run in…

I think upx is more useful for static binaries like that of Haskell applications which is kinda huge. (GHC produces huge binaries - eg. pandoc or ghc-mod). A 100 something mb binary is not what you usually have. UPX can work its magic stuff like that. More manageable not necessarily essential but when you need it you need it badly.

Re: UPX – Ultimate Packer for Executables

#29

I used to use this a lot, back in the bad old days, when drive space was at a premium. These days I struggle to fill my hard drives no matter how wasteful I am with downloading videos and not bothering to clean up afterwards... and the amount of hard drive space you can buy per dollar keeps growing faster than I can fill my disks. Much trickier issues to tackle are speed (unless you go with SSD's, but then you run in…

I think upx is more useful for static binaries like that of Haskell applications which is kinda huge. (GHC produces huge binaries - eg. pandoc or ghc-mod). A 100 something mb binary is not what you usually have. UPX can work its magic stuff like that. More manageable not necessarily essential but when you need it you need it badly.

Is there a reason the Haskell compiler can't trim-out code it knows won't be used? Or is there another reason for the large size?
Post reply on HN