Forums Feature Suggestions EXE compression (2mb -> 800kb)

Using UPX I was able to get the filesize of mirc.exe down to 800kb from 2mb! However, this compressed binary quits immediately after launching.

I theorize this has something to do with the mIRC feature where it checks it's filename to make sure it has "mirc" in it. The easiest way to do this is using argv[0] (which contains the full path and filename of the launched executable), however one of the caveats with UPX is that argv[0] becomes nonsensical. Perhaps this restriction could be removed in favor of a compressed EXE instead (it would make it more suitable for a portable mirc on my thumbdrive ).

There might be a performance hit that goes with the inital program launch, but I am unable to measure it since it doesn't work in the current build of mIRC >_<.

Not all computers run fully compress executables.

ClickHeRe ran into problems with DCX so he had to lower the compression a bit. More trouble than it's worth considering 2mb is nothing, in my opinion.

Does UPX run as a service? or is it like the DOS HARCEXE that compressed the EXE and attached the decompressor code to the compressed EXE?

PS: why dont u compress the folder its on? (or am i talking out a hole in my head and that is UPX? naaa cant be!)

UPX works kinda like a winzip self extractor. The header of the exe is the UPX stub. It reads the rest of the exe file, and uncompresses it into memory. Then the exe sets the execution pointer to the point in memory where it extracted the infromation.

The only problem with UPX is that many anti virus programs flags UPX compressed EXEs becasue UPX is often used to hide virus's and trojans key signatures.

Also, I suspect that is why it quits out. mIRC dose read the exe back off the disk once its launched to verify it. The CRC wount match, and it quits out.

I think there is another problem with that, exe's are not just one part anymore (from memory), windows ones at least, they can be loaded and unloaded sectionally, so I dont really see how a over the file compression can work (might be fine for mirc.exe etc, but not all exe's) I beleive this is similar to loading dlls but they have been attached to the end of the exe. (i dont personally know the ins and outs of this just that it can be done, was however a while ago i red it)

hixxy: And why not? It's the same x86 instruction set as the program that was compressed... in theory the only things that should really make a difference are the instruction set and OS.

And 2MB -> 800kb is something when you have a small flash drive.

DaveC: About your first post: UPX compresses the EXE so that it will dynamically decompress itself, transparently to the user, when run. And I can't compress the folder for several reasons:

A) Compressed folders are going to be slower due to overhead of decompression, although in practice I admit I haven't noticed significant overhead.
B) Windows only lets you format flash drives in FAT or FAT32, neither of which supports compressed folders like NTFS.
C) If I ZIP or 7Z etc mIRC I can't very well run it off the flash drive, now can I?

basicer: No anti-virus tool I've used has, which is sorta ironic considering I've only used free ones and you're probably talking about $$$ Symantec and McAfee etc solutions.

The false positives I get tend to focus on my mIRC DLLs (specificly, registry and HTML control DLLs. Quite annoying).

About the CRC thing, that would be a better explanation for what's happening than what I came up with.

At any rate, a MessageBox telling me why mIRC won't run would be preferrable to a silent quit without doing anything.

DaveC, about your last post: Are you sure you know what you're talking about? It doesn't seem to me like you do. :tongue: I think you're confused.

As far as I know when an EXE is run the entire binary is loaded into memory for execution. Perhaps a sectional method is possible, but 1) computers have enough memory now that it really doesn't matter if you load the whole thing 2) why load sections, it's likely you're going to call code from all over the binary anyways 3) how would you predict what code you would need? The user might change their mind, they tend to 4) I am not aware of any method of specifying "sections" to a compiler or linker.

I don't know all the details, all I know is that a fully compressed dll worked on some machines but not others.

> And 2MB -> 800kb is something when you have a small flash drive.
Then buy a bigger one, there dirt cheap

> DaveC: About your first post: UPX compresses the EXE so that it will dynamically decompress itself, transparently to the user, when run.
That didnt answer my question, is it a service (it attached tot he OS, intercepts calls to read the file and expands it for) OR is it attached as part of the file that runs and decompresses the file when executed?

> And I can't compress the folder for several reasons:
> A) Compressed folders are going to be slower due to overhead of decompression, although in practice I admit I haven't noticed significant overhead.

You wont the time it takes for most compressed files to be expanded is relaitively short compared to the longer disk overhead to read the larger file from the HDD.

> B) Windows only lets you format flash drives in FAT or FAT32, neither of which supports compressed folders like NTFS.
ill trust u on this I have never noticed.

> C) If I ZIP or 7Z etc mIRC I can't very well run it off the flash drive, now can I?
I never even mentioned zip so i dont know why you did, harcexe's were compressed code expanded by the program itself, by a code stub attached to the front or rear of the file (cant remember which)

> About the CRC thing, that would be a better explanation for what's happening than what I came up with.
That is of course the likely cause, as i beleive you cant hex edit mirc.exe anymore

> DaveC, about your last post: Are you sure you know what you're talking about? It doesn't seem to me like you do. :tongue: I think you're confused.
I doubt it, I suggest you take a look at the PE/COFF Portable Executable (PE) or Common Object File Format (COFF)