Enigma Protector

Did any one try to add external package for packed x64 build exe?
From my testing, it doesn't work.

For 32bit, external package works from my testing. But consumed peak memory is high if external package is big.
Mostly my external package contains huge size files that can be selected to load during runtime.

If those two issues can be solved, this tool will be great.

Hi DennisHu,

The first problem should be fixed with the recently released Enigma Virtual Box 5.40.

Regarding second problem - will try to check it out. Will update this thread with results.
But can you please let me know how much files your large packages contains?

just Test 5.4.

With using Virtualization method as "Never write to Disk", external package works with 64 bit application.

But other options "Always Write To Disk"/"Write to Disk if not Exist" will give wrong result.
My binary file contents has been changed. I guess there is some bug issue with "Write to Disk".

In my application, we need 10 or more packages, every package is about 1GB.
That means total external package size can be 10GB or 20GB.

If "Never write to Disk" is chosen for external package building, does the packed exe need 10 GB or 20 GB to run?

Thanks.

DennisHu wrote:My binary file contents has been changed. I guess there is some bug issue with "Write to Disk".

Yes, it is a bug, thanks you for the information regarding this. It is already solved in the latest version 5.50 that is just released.

DennisHu wrote:If "Never write to Disk" is chosen for external package building, does the packed exe need 10 GB or 20 GB to run?

No, of course it should not require so much memory to run. All virtual files are stored in the file overlay, they are not mapping to memory until program requires the file. If the program requires the file, it is being mapped and of course, it takes some memory. Just to note, there is mapping a virtual file, not an entire file of package.

Can you please tell me, how many files are stored in the external packages? I'm interesting in a number of files.

Also, try if the files packed with new versions cause such memory leaks. You may also try to disable all options on the Options panel and check the file behavior again, this may help to reduce the amount of used memory.

As i tried with 5.5, those options work for 64 bits application.

In my project, about 700 files are stored in the external packages without compression. Total size is about 17GB.
Maybe compression can reduce the file size. Will it slow the application initialization if everything is compressed?
As i test, I can't mix compressed application/packages with uncompressed packages.

I'm not sure why we need option "Write to Disk". Does this option reduce memory consumption?

From my simple unit test, if an external package is about 722Mb, the memory peak for this exe goes to 1468Mb during loading. Is this reasonable?

Some minor issues:
.Compression progress is incorrect when large size external package is compressed.
For one file, it will show progress multiple times. (no progress is complete...)
. Is there any command tool to build external package with output filename?
so we can easily manage building multiple external packages.

DennisHu,

DennisHu wrote:As i test, I can't mix compressed application/packages with uncompressed packages.

Yes, of course and this is correct. Compression options are set in the settings of main exe file, packages are using these settings too. So if the main exe is packed with compression, then all packages will be also compressed, and vice versa.

DennisHu wrote:From my simple unit test, if an external package is about 722Mb, the memory peak for this exe goes to 1468Mb during loading. Is this reasonable?

This depends on an application behavior. For example, if this package contains a dll files that are being loaded while application start, then yes, all files will be loaded to memory and application will require much memory.
If the package contains, for example, images, then these files will be restored in memory only in the moment when application requires them.

In your case, I recommend you to disable all checkboxed on the Options tab and try pack the file and try. This will help to reduce the amount of memory that application uses.

DennisHu wrote:.Compression progress is incorrect when large size external package is compressed.
For one file, it will show progress multiple times. (no progress is complete...)

Progress is being shown by the compression algorithm. It's specific and could be not much accurate. Hope this does not annoy too much.

DennisHu wrote:. Is there any command tool to build external package with output filename?
so we can easily manage building multiple external packages.

No yet, but I will add this issue in todo list and it will be made in some future version.