On Mar 21, 2004, at 10:16 AM, Bohdan Peter Rekshynskyj wrote:
On Mar 20, 2004, at 20:33, Chris Devers wrote:
On Sat, 20 Mar 2004, Bohdan Peter Rekshynskyj wrote:<shudder>
Is there such an animal? And is it GNU-ed?
Aside from /usr/bin/perl (or C:\perl\perl.exe)?
There is (was? "is", I suppose...) that could produce Windows .exe files
out of win32 Perl scripts, but it doesn't have a very good reputation as
far as I can tell.
Perl2Exe has a spotty reputation, but since it is a potential solution to your problem I would recommend you look at it and look at the actual criticisms so you understand what the concerns are. Despite the name it is really just a binary packaging tool, and can be used to deploy on various flavors of unix as well as Win32.
http://www.indigostar.com/perl2exe.htm
For every other platform Perl runs on (everything?), /usr/bin/perl is pretty standard, and you're generally better off just distributing programs that way than trying to compile them to some kind of binary.
Well, I want to distribute the programs to my clients - without source...
If they can modify it - there's a concern of security - and never mind
the ownership of code et cetera!
Also, compiled versions run way faster....
If your program is slow, you should work on optimizing it rather than hoping that a compiler will magically make it faster.
(Would love to develop Perl/TK in Aqua using a compiler and distributing!)
Dropscript + a source filter might make you feel better. It still would be trivial to get at your source using various tools, but the casual browser would see line noise and might be deterred.
I would really recommend looking at PAR (the Perl Archive Toolkit). This can generate a packaged standalone executable, and can handle bundling modules as well (a big plus). It has an input filter to obscure your source code. I haven't tried it on OS X, IIRC it depends on DynaLoader, which had some issues on OS X last I checked (10.1, things may be better now), so YMMV.
IMHO, the best reason to create a standalone executable is not to improve performance, or to protect source code, but to provide convenient packaging. But, as mentioned, PAR can use an input filter to obscure your code to make it much more complicated to alter your code. This is not going to stop the bad guys from getting at your code.
See http://par.perl.org/?FAQ
"Can PAR completely hide my source code?"
Keep in mind that no matter what language you use a determined bad guy can decompile it. Randal Schwartz' advice in that FAQ about licensing is well worth consideration for whatever packaging scheme you decide on.
<trimmed>
