many exe files rely on one library

xiaoyafeng has asked for the wisdom of the Perl Monks concerning the following question:

I package perl script with pp when I need to publish it to windows clients. Life is peace until one day clients complain temp directory was full. 20+ 50M-size exe files created almost 7G files in C drive!

the straightforward way I can think is install perl on client machines and replace exe with scripts. yes, it's a way, but, I prefer exe, which can be view as a protection to prevent user modify it easily.

So my question is: how to make all exe built with pp shared libraries other than contain all modules into one executable file? Just like .NET, install one and all exe file can make use of it.

Thanks in advance!

UPDATE:

Sorry for the long time to reply this. After dig monks' reply below, I realize the better way to deal with this request is packing my own perl distribution, not local lib, not pp. just whole perl distribuiton: perl executable, libraries etc. And use pl2bat, bat2exe to wrap around script, or even make this by hand personally as thomas895 suggest.

Thanks monks, your generous help always makes me less headache. ;)

I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Comment on many exe files rely on one library

Replies are listed 'Best First'.
Re: many exe files rely on one library by marto (Cardinal) on Oct 13, 2012 at 10:24 UTC
Consider packaging with the `-C` option to clean up temporary files on exit, documented in pp. Also, you don't really gain anything from a security perspective when packaging Perl.	[reply] [d/l]
Re: many exe files rely on one library by Anonymous Monk on Oct 13, 2012 at 09:58 UTC
use CavaPackager , see Re: Pack multiple scripts in executables with one shared core dll and look for my other posts :)	[reply]
Re: many exe files rely on one library by syphilis (Archbishop) on Oct 14, 2012 at 01:50 UTC
Is it possible to have pp create an exe file that packs in only the code that's contained in your script ? Such an executable would need to be able to find perl on the local machine - so you would need to install perl on all client machines, then distribute this "minimalist" executable that has packed in only your code and pulls in the perl that has been installed. If pp doesn't already provide this capability, then I think it's a feature that might be worth adding. FAIK, this might not even be do-able. (Or, it might even amount to being the same thing as distributing the script as is :-) Looking at the docs (as I don't actually have PAR::Packer installed) I wonder if `pp -S -o hello.exe hello.pl` does precisely what I'm suggesting ? I'm guessing it doesn't, but it's not hard to check. Just create an executable (from the simplest of perl scripts) using that command, check that the exe runs on your machine, then remove Perl from your path and see if the exe still works. If the exe still works, then obviously it must contain perl within it ... which is not what we're looking for. Cheers, Rob	[reply] [d/l]
Re^2: many exe files rely on one library by Anonymous Monk on Oct 14, 2012 at 05:36 UTC
I wonder if pp -S -o hello.exe hello.pl does precisely what I'm suggesting ? No it doesn't. See PAR::Tutorial#Aggregating multiple programs/perlws/Re^6: pp and multiple perl scripts and just use cavapackager, does this out of the box :)	[reply]
Re: many exe files rely on one library by thomas895 (Deacon) on Oct 14, 2012 at 09:24 UTC
If you absolutely must make it difficult for a user to modify your scripts, you can try to obfuscate it, like they do in Java. How to go about that I don't know, but there's bound to be a package for that somewhere. Otherwise, to make things even more complicated(for yourself as well), you can write parts of it in C(and somehow use XS to pass your entire Perl script as a string to the interpreter. Then, use "make perl" to compile the Perl core and your script into a `perl.exe`. Note that even if you don't tell anyone, it's still quite trivial to get the script by useing your module containing the script and then just placing that script into a new file and editing from there. I don't see what you're trying to do that would require this, though. Assuming you distribute your application so that clients can install it on their own machines, if they screw things up it's their problem and not yours, no? If you truly have secrets you must hide from clients, perhaps Perl is not the right choice. An actual compiled language may be the better choice. ~Thomas~ `confess( "I offer no guarantees on my code." );`	[reply] [d/l] [select]