Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

many exe files rely on one library

by xiaoyafeng (Chaplain)
on Oct 13, 2012 at 07:36 UTC ( #998823=perlquestion: print w/replies, xml ) Need Help??
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!


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

Replies are listed 'Best First'.
Re: many exe files rely on one library
by marto (Archbishop) 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.

Re: many exe files rely on one library
by Anonymous Monk on Oct 13, 2012 at 09:58 UTC
Re: many exe files rely on one library
by syphilis (Chancellor) 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 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.

Re: many exe files rely on one library
by thomas895 (Chaplain) 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.

    confess( "I offer no guarantees on my code." );

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://998823]
Approved by Athanasius
Front-paged by bulk88
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2018-05-26 22:39 GMT
Find Nodes?
    Voting Booth?