Archived Forum Post

Index of archived forum posts

Question:

Error when using UPX with ChilKat & Delphi

Oct 17 '16 at 13:02

I don't have an answer for this yet, but I've narrowed down a real issue with including ChilKat DLL into DelphiXE6 projects when you also use UPX executable packer on the exe. I haven't tried any other versions of Delphi to confirm if this applies to all versions.

If you compile the Delphi project exe with Debug Information linked, the packed exe works fine. If you turn off the option for Debug Information then the exe will hang when you run it. I created a small demo application to remove everything else from the project. We've been using UPX for a decade or more, and building our release version of projects without debug info for longer. The only new thing introduced here was ChilKat.

I don't know if anyone has a solution for this, or anything can be done. But I thought I'd share this information to hopefully save others the days I've spent narrowing down on what was happening.

Answer

I ran into a similar problem with Chilkat after using UPX for many years. Unfortunately I never found a solution or workaround. However, after switching to PECompact, I no longer experience the problem and I recommend using PECompact instead.

Answer

I suspected the problem had to do with the way that ChilKat is loaded statically, this was a variation from the other DLL's that we use (3p & internal created). UPX does an uncompress once it's loaded into memory, so I figured that the memory address of the ChilKat dll procs were being trashed.

After reading another forum post (http://www.chilkatforum.com/questions/11058/delphi-dll-version-static-dll-names) I spent an hour or so rewriting the parts of Crypt2.pas that we need, to handle dynamic loading upon first request and then in the finalization it unloads if the DLL has been loaded. Rebuild of demo app without debugging information & doing UPX on the exe no longer causes the application to hang.

I'd recommend that the Delphi units are rewritten to handle dynamic loading of the DLL, as suggested in the other post.