PureBasic Forums - English

I didn't want to clutter up the Feature Request thread for external packer support, and I don't know what it is, beyond the simple "reduce file size" (I think?) definition..

But on a more broader scope, I am wondering what they are typically used for, in real world situations and such.. What the difference is between various methods (UPX/????) and why they can trigger Antivirus False Positives?

Yeah I could google it and such, but I am not looking for a manual text that assume technical knowledge I may or may not have or lack the ability to grasp.. I'm looking for a simple, friendly explanation about what they are, how they work, and what I might realistically want to use one for. Something along the lines of the other general question threads I have posted.

Thanks..

Zach wrote:difference is between various methods (UPX/????) ...

UPX isn't a packer, it is an executable compressor.

A packer generally allows you to include other files "packed" in your EXE and usually "protects" those other files via encryption or compression. More than "protecting" your required files, a packer will ensure that your required files are there at runtime and have not been deleted (accidentally or intentionally).

Its used for 3 reasons:
smaller file size
faster loading (because of the smaller file size)
anti debugging, anti reverse engeniering

In the case of UPX, the third point isnt part of the concept.

Different compression technics are used for getting different rations of file size versus decompression speed or to make the protection more obscure.

AV's will raise a positive if they cant unpack the executable and scan the real executable. Modern AV's come with a lot of unpackers that are able to unpack UPX and a lot of others to scan the executable.

Whoa! You guys inspired me to finally try out UPX. It compressed my latest project's .exe to less than half the size, and it seems to load just as fast... nice!

Anyone know if an executable UPX'ed under Windows 32-bit will run properly under Windows 64-bit?

Thorium wrote:faster loading (because of the smaller file size)

This is a myth that most EXE compressors will fraudulently claim.

With 32-bit versions of Windows and the PE format, Windows only loads an executable into memory in 4K chunks. When an executable is compressed, the entire compressed executable must be loaded into memory and uncompressed (either into memory or some will write the uncompressed EXE back to the disk) before the first 4K chunk of the uncompressed EXE can be loaded into memory.

Although the decompression of an EXE is negligible speed-wise, loading a 4K chunk of an uncompressed EXE into memory is faster than loading an entire compressed EXE (which will often be much larger than 4K) into memory.

kenmo wrote:Anyone know if an executable UPX'ed under Windows 32-bit will run properly under Windows 64-bit?

It will run fine.

Not a myth, Kuron. A UPX'ed EXE will load faster and start an app faster on slow media than its uncompressed counterpart. For example: from floppy disk, DVD-ROM or network share. Try it and you'll see for yourself.

MachineCode: Does UPX ship with a time machine to go back to the 20th century when computers still had floppy drives and people still tried to run software off of a floppy?

In all seriousness, think about what you said. Floppies are slow. Which is going to be faster? Loading 4K into memory from a floppy or loading the entire EXE into memory from a floppy?

I just knew you'd latch on on to the "floppy" bit and ignore the DVD-ROM and network share parts. So, answer me about the other two, since they're still current and valid in this day and age. I've tested app load and start times with a compressed and uncompressed EXE and the compressed loads and starts basically instantly from both of those. The uncompressed exe just loads... slowly... then starts.

[Edit] Oh, and don't give me any of that garbage about "load times are irrelevant", because they're not.

I would assume still very relevant on mobile / small footprint platforms where they might not have a lot of resources, and what they do have is small, etc.

Netbooks can be pretty sluggish depending on what you are doing..

Anyhow, thanks for the replies.

MachineCode wrote:I just knew you'd latch on on to the "floppy" bit and ignore the DVD-ROM and network share parts. So, answer me about the other two, since they're still current and valid in this day and age.

You can't be serious! Do you think a floppy is faster that a DVD or a network connection? I concentrated on the floppy because it is the slowest of the three. ROFL!!!

No matter what the storage medium is, it takes less time to load something that is 4K than load an entire compressed EXE (which is usually much larger than 4K). It is a matter of size and when it comes to loading something, smaller is better. A compressed EXE is not smaller than an uncompressed EXE when it comes to loading. The compressed EXE is actually larger.

MachineCode wrote:Oh, and don't give me any of that garbage about "load times are irrelevant", because they're not.

Indeed, this is why you should choose the smallest possible thing to load (4K) than do like you are suggesting and choose the largest possible thing to load which actually works against the way the OS is designed to work.

You need to remember why executable compressors were first developed: to save space. That is it. Once drives hit the 850MB range, EXE compressors became highly irrelevant and developers moved to new marketing gimmicks to push EXE compressors on programmers.

In the old days (100MB or less hard drives), space was always at a premium on your EU's system and you could not count on your EU using something like Stacker, DoubleSpace, DriveSpace or DIET to try and "stretch" the room on the storage medium. By developers reducing the size of their EXEs, your EU could fit more software on their system without having to rely on third-party compression software to compress the entire drive.

Kuron wrote: With 32-bit versions of Windows and the PE format, Windows only loads an executable into memory in 4K chunks. When an executable is compressed, the entire compressed executable must be loaded into memory and uncompressed (either into memory or some will write the uncompressed EXE back to the disk) before the first 4K chunk of the uncompressed EXE can be loaded into memory.

Thats not true. It will load the complete code section, which can be more or less than 4K. It also will load initialized and uninitialized data. The only thing it will not load to memory are ressource section, dos stub and headers, they are file mapped.

Kuron wrote:You can't be serious! Do you think a floppy is faster that a DVD or a network connection? I concentrated on the floppy because it is the slowest of the three. ROFL!!!

What the? Don't "ROFL" me! Of course I don't think a floppy is faster! How the heck did you come up with that assumption?

I'm saying that a compressed exe will load faster from those three mediums than the same exe in an uncompressed state.

Compressed exes are slower to load purely because of the extra step of uncompressing them when executing!

Plus compressors are useless today to save a few K and they always trigger anti virus apps, so why bother?

Blood wrote:Compressed exes are slower to load purely because of the extra step of uncompressing them when executing!

Plus compressors are useless today to save a few K and they always trigger anti virus apps, so why bother?

You got it wrong with the loading speed. The decompression step speeds the whole loading up. Thats actualy the whole point of compression of game ressources, faster loading.

Its because the HDD is the bottleneck. The decompression is much faster than loading from HDD, so you put pressure away from the HDD and put it on the CPU. That way you actualy get lower loading times.

However i agree with you that its not very usefull on PC. In most cases you dont feel a difference.