The old way with permanent relocation makes the Perl subject to “The Rule of One”. There can be only one Perl on the system if you set it up that way, and if you forget that when you try to upgrade you’re in for a world of pain.
The State Tool exists in part to change that, so that it’s easy to switch Perls on the fly, and do development work against several versions if needed, and wrappers are far more flexible for that than binary file editors. The idea isn’t new. PerlBrew has been doing it similarly for a while, and we’ve gone a few steps further.
The embedded pointers are everything from how config_heavy is set up to strings inside the dlls or sofiles. While it’s possible to manually change all of it if you have the tools, for anyone who isn’t deep into how the Perl core operates the task is far too much to ask.
pp isn’t a compiler. It’s a packer which creates self-extracting archives, and that is a very different thing. Lots of operating systems will shut down packer files because they work on the same principles as several classes of malware, rather than how a true compiled binary behaves. Yes, placement of the dlls is important if your wrapped file needs a Perl dll.
Two notes -
We don’t attempt to be compatible with Par Packer. Given how Par works, my understanding is that the only way to be really sure you can use it is to compile your own Perl from source code locally on the system where you plan to build files with Par, and then compile the Par Packer module on that system from source code as well. Old style ActivePerls were not compatible with PAR, because the Perl building PAR was almost never exactly the same version as the one running it. Strawberry Perls were a bit more likely to have success with PAR, but it kind of has to be built at the same time as Perl even for Strawberry.
Par Packer also doesn’t remove the onus for having a license to run. A packed file containing ActiveState Perl components needs a runtime license, just a much as a non packed script running on ActiveState Perl.