I’m giving Enigma Virtual Box a try, a freeware exe-packer. I have build an application with 2023.31 64 bit.
Is there anybody having a working example?
You have to add (ofcourse) the runtime files and the appname libs folder… But whatever I do, the new generated .exe can’t find the necessary runtime files resulting in runtime errors.
At one point it was recommended not to use these, since they don’t expose all of the Windows APIs that Xojo itself uses and can cause unexpected issues.
I gave up using these because they are constantly detected as malware by a thousand different antiviruses. You sit there responding to users’ tickets all day about them using some obscure antivirus, who you then have to reach out to and find out their whitelisting procedure and submit your executable (half the time the single-packed-exe is too large to submit via their web forms). Then 6 weeks later they update their antivirus or you push an update to your software which breaks the whitelist and you do it all over again. Lather, rinse, repeat for 100 different antivirus softwares.
I hate programs that consist of a directory with an .exe and several runtime files, plus a subdirectory with some other files. Why are the files of that subdir not in the program root? It gives me a sloppy impression. Another thing is that all the resources are visible. Some kinda lousy bookkeeping. I don’t want that. I want one single executable which contains everything the program needs. No need for subdirs, files that can get lost or moved or whatever.
I have the exact inverse impression. Subfolders of exact dependencies is a much more organized layout than lots of mixed random contents spread everywhere.
You know, some EXEs depends on some exact versions of some DLLs, and Xojo allows 2 exes in the same root folder and 2 different Lib folders for them for example, resource folders too.
Sure, we’re here to teach, learn, and laugh if possible.
I also love monolithic exes WHEN possible, but the dynamic loading nature of Xojo (plugins everywhere) makes it impossible since a change in its design in the past (no more static linking of many dependencies).
The packer is going to UNPACK all the files to run the program anyway. You are making the app launch slower just to have the files and resources in a different path
Actually, you’re disagreeing with Microsoft. There’s a very good reason for the runtime DLLs to be external. If you don’t have them next to the app, the app uses the system-wide versions that get periodic security updates. That’s what you should be doing according to Microsoft, which means using a real installer so you can be sure that all of your system dependencies are met.
Not necessarily true - some packers, in some modes, do unpack the files to disk, but some do not and are able to unpack DLLs in RAM and load them directly without copying to disk.
malicious actors can use a hacked DLL, since on Windows there is generally little or no checking that a given DLL loaded by your app is actually the correct DLL
security updates are good, but sometimes when DLLs are updated, they introduce new bugs, or fix an old bug that your program relied on.
I think arguments on both sides are valid and it really depends on the specific situation.