UPX Executable packer doesn't want to compress executables compiled and liked with digitalmars tools, with an error message:
"CantPackException: file is possibly packed/protected (try --force)"

Trying force yuilds following results:
- with stable 1.24 - a 100% broken executables. GPF at start.
- with alpha 1.90 - an execuble *seems* to work. But as the homepage says, it only *seems* so, since it has to be broken at some point. A matter of luck though.

What might be the reason of it? According to the authors, current UPX has following bugs and non-working features in Win32/PE
- writeable shared sections (`--force' *may* work)
- certificates in the image.

-i.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b3bdlm$10ll$1@digitaldaemon.com...
> UPX Executable packer doesn't want to compress executables compiled and
> liked with digitalmars tools, with an error message:
> "CantPackException: file is possibly packed/protected (try --force)"
> Trying force yuilds following results:
> - with stable 1.24 - a 100% broken executables. GPF at start.
> - with alpha 1.90 - an execuble *seems* to work. But as the homepage
> says, it only *seems* so, since it has to be broken at some point. A
> matter of luck though.

Is the source available to UPX? That would likely be the fastest way to see why it is failing. Optlink produces standard PE exe files that work fine from win32s to XP. I have no idea why UPX would fail on them.

> What might be the reason of it? According to the authors, current UPX
> has following bugs and non-working features in Win32/PE
> - writeable shared sections (`--force' *may* work)
> - certificates in the image.

Neither of those are present. You can see what's in it with the DUMPEXE utility.

In article <b3bv3v$1f6q$1@digitaldaemon.com>, Walter says...
>
>
>"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b3bdlm$10ll$1@digitaldaemon.com...
>> UPX Executable packer doesn't want to compress executables compiled and

..

>Neither of those are present. You can see what's in it with the DUMPEXE utility.

I've been using HeavenTools PE Explorer to fish around (graphical dumpexe), but have not found anything amiss yet. PE Explorer has built in support for the UPX plugin, and is failing in the .init section. I tried debug, optimized release, non optimized release, and manual adjustments of the DM EXE PE header to look more like a Microsoft PE header - I also tried various switches passed into UPX, and no progress.

My thinking is that it might be difficult to get a debug release to work with UPX, but cerrtainly a release version should have no problems.. but one thing that seems odd (albeit theoretically benign) is the presence of a .debug section in the release build of a DM exe.

Richard

>I've been using HeavenTools PE Explorer to fish around (graphical dumpexe),

Also, PE Explorer is showing that the .text and .rdata sections (_TEXT and CRT$XIA in a DM exe) as type <OTHER>. With a Microsoft distributed exe, the sections are identified as .text and .rdata.

Not really understanding the difference, I just changed the types - and created an invalid exe.

Finally, delete of the .debug section and recalculate of the section size also creates an invalid exe.

Any one else?

Richard

Sure.

http://upx.sourceforge.net/#download

I have tried a ton of other executable compressors. Some, like the one from Ian Luck work, most others don't, but i'm not sure these do at all. :)
I've collected the data *somewhere* and can't tell more right now... till i find where i have put it.

Anyway, there's no source to the others, not much to analyze...

Walter wrote:
> Is the source available to UPX? That would likely be the fastest way to see
> why it is failing. Optlink produces standard PE exe files that work fine
> from win32s to XP. I have no idea why UPX would fail on them.



PS. Thans a lot for the new D features. (like for everything)
I guess these are the ones that can give D even more advantage over the current popular imp+OO languages. OTOH high flight - long way to fall...

BTW, your compiler is not very huge. I don't see a single reason why a VM has to be larger. It can even only be a simple 300k compiler. :)

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b3j726$1ia$1@digitaldaemon.com...
> BTW, your compiler is not very huge. I don't see a single reason why a VM has to be larger. It can even only be a simple 300k compiler. :)

The hugeness of the VM doesn't come from the compiler, but from the library. With a native executable, you link in just the library code you need. With a VM, you carry it *all* with you, whether it is used or not. The VM also has to support every feature, not just what is used.