How Well Does Perl2exe Work for Large Applications? 51
bobm writes "One of the issues with not using the 'standard' MS tools (VC, VB, etc) is that you face the possiblity of having to load a lot of DLL's to support an application. I'm in this boat with a Perl app I would like to migrate to a couple of Windows 2000 servers. It's a simple app that runs well on our Unix boxes and if it wasn't for the overhead of having to install perl and all of the required modules, it would be a no brainer. However I just stumbled upon Perl2Exe at Indigostar.
A small app worked great and I'm wondering if anyone else has used it and how large of an app have they released? Any other pointers and info on pertinent issues would be helpful too."
My advice: don't (Score:2, Redundant)
Of course if you're simply trying to distribute a closed-source perl app, more power to you, just be aware that it's not really all that hard to get source code back from the perl executable.
Re:My advice: don't (Score:3, Insightful)
Read what the guy said:
It's a simple app that runs well on our Unix boxes and if it wasn't for the overhead of having to install perl and all of the required modules, it would be a no brainer.
Here's a thought - you tell us (Score:1)
Overhead? (Score:2, Funny)
If you're that worried about overhead, why the hell are you migrating to Windows 2000?
Re:Overhead? (Score:1)
He's not migrating to Win2K. He already has Win2K. He wants to migrate the Perl app from UNIX to Win2K.
Re:Overhead? (Score:2)
On another note: Offtopic?!?!?!?
What is wrong with you moderators? Did you even bother to read the fscking article?
Flamebait, sure, I actually expected a flamebait mod. Troll I could see, maybe. But Offtopic?!? Come on!!!
Works okay, some usage problems. (Score:5, Informative)
Main problem was licensing. Because it was an installation app, the Build/CM team was responsible to maintain it. IIRC, the license was tied to a given username and host. So, developers can't build the installer themselves, the CM team must do it on request, or setup a shared perl2exe user for everyone on a build server somewhere. Developers, if they want to fix it, must go and work on the shared server. Pain in the ass.
The other issue was lack of Perl know-how. When the compiler complained, I'd have ten people at my desk while I tried to explain how to setup @INC corrrectly.
Seems like a _very_ small shop produces it, and is a little kludgey. Overall though, if my team was just me or a few Perl savvy people, I would recommend it.
As an aside, my reasons behind using perl2exe were:
1) perlcc didn't seem to work at all, and I didn't have the time to muck with it. Has anyone gotten this to work for more than just small or test programs?
2) (and most obnoxious, at least with 5.003(?)) Perl is a pain in the ass to deploy. Licensing issues didn't allow us to distribute ActiveState on NT, and Perl really wants to be compiled on the target machine for Solaris. Compiling a distribution on Solaris hard-codes the prefix-dir, so it expects the target machine to have the same dir structure--which is in violation of my requirements. I emailed the mailing list and got a reply from non other than Randall Schwarz, who basically said (heavily paraphrased), "Yeah, that sucks. Someone's going to fix it eventually." The only solution I could come up with in a short amount of time was to write a wrapper script that mucked with @INC and included paths from the environment before execing anything else.
I love the language, but this is why I don't use it. You can't depend on everyone having installed Perl + all your needed PMs themselves, and its not worth trying to automate it for them. IMHO, its the downfall of the language.
We wanted to have Perl installed with our large Java system to help in performing scripting type tasks, but it was way too big of a pain. Oh well...
Re:Works okay, some usage problems. (Score:1)
I have used this some in my company. (Score:1)
My advice: Do (Score:4, Interesting)
For the record, I recommend using Perl2exe and avoid installing the Perl runtimes!
I've used Perl2exe for, admitidally smaller programs, and it works great. Check out the options, you can either compile into one large exe, or use one (yes, one) additional dll and reduce the size of the program considerably.
So basically, you have the best of both worlds. If it's only ever going to be one application, do a full binary and deal with the size. If there could be one or more, then consider using the dll.
Yes, there are 2 downsides, one is the size of the application - but compaired to the size and hassle of installing the whole Perl distribution for every machine, it's a no-brainer.
The other being the ability to edit the code. Well if there are individuals out there who need to edit it, they'll have the perl runtimes and you can just give them the source. But giving normal users carte blanche to edit the code is asking for hundreds of support calls.
If options are needed code them in rather than get them to edit the source.
I'm not a sysadmin, but... (Score:2)
I am not a sysadmin (and I'm not trying to troll here), but how hard is it to install Perl? At my company, my boss and I installed Perl in a few minutes (30 or so). Surely it can't take that long to install Perl and a few modules, especially if you install Activestate's Perl.
-Vic
Re:I'm not a sysadmin, but... (Score:1)
We want to have a clean install that automates much of the work, rather than a huge pre-install guide instructing users how to setup all the required apps.
this is a problem with cd distribution/automation? (Score:1)
Re:this is a problem with cd distribution/automati (Score:1)
Several reasons:
1) That's not a binary, it's source code. My clients can't be required to make Perl on they're own. They'd have to install Cygwin/GCC on windows and GCC + binutils + fileutils, etc. on Solaris.
2) They'd still have to download and install the PMs themselves.
3) Can't use Nullsoft because it only runs on NT.
4) Our install is much too complicated for a pre-built install system. Way to much interdependency on up to a dozen modules, scripted HTTP posts, and all sorts of custom hackery. Tried nearly everything, didn't work.
Re:this is a problem with cd distribution/automati (Score:2, Informative)
That's not a binary, it's source code
Here [cpan.org]is a list of many win32 binary distributions of Perl, some of them with installers. I'm sure you can find one to suit your needs.
Re:I'm not a sysadmin, but... (Score:2)
A couple of years ago I had a tiny 8 line or so text mangling perl script that I would carry around on a floppy with a copy of a perl.exe on it.
Just the script and the perl.exe and it ran fine. It wasn't the active state one either IIRC.
Isn't there a perl source out there that you could build and distribute, or do you need all the Active state bells and whistles?
Re:I'm not a sysadmin, but... (Score:2)
Re:I'm not a sysadmin, but... (Score:1)
Some more information would help us improve the quality of advice. For example, is this a web CGI app, where the overhead of Perl2exe's static linking will be large compared to ISAPI Perl? Is the app run often enough that this overhead would matter?
Re:I'm not a sysadmin, but... (Score:1)
Save time, money, and get something more stable to bood (pun intended)
My experience (Score:4, Interesting)
Thus, I tried Perl2exe. There were two parts that really impressed me. First, it included all of the packages that I was using, including Perl/TK (as I said, Windows users. The looked at my initial console version like it was in Hieroglyphics.) I was also impressed that the program and dictionary could still be compressed to fit on a floppy, which was a huge relief from having to Perl burn CDs for all of the users. In the end, I would say that, if you are porting a simple maintenance script or other non-time critical application to the Win2k servers, by all means go with Perl2exe. However, if this is a critical part of your new Buzzword Server System, then read a post from someone who knows better.
Perl still has a few probs on Win2000 (Score:1)
Re:Perl still has a few probs on Win2000 (Score:2, Informative)
It can be a godsend (Score:4, Interesting)
I had to write and run an application on a bunch of windoze boxen for a client a couple of years ago. I was not permitted to install anything. I got it working in perl, used an eval copy(it wasn't a long-term application) of perl2exe, got the job done, and everybody was happy. Sounds like your app is similar.
One caveat: the big static binaries tend to load kind of slow, but as you know, everything has tradeoffs.
I *adore* Perl2exe (Score:2, Informative)
- use Perl2exe to obfuscate and hide my source code. Generally, I'll give it out to whoever asks for it.
- use Perl2exe to speed up my code. That doesn't work. And if I wanted fast, I'd write in C.
I know Perl isn't *terribly* difficult to install. But it's a helluva lot simpler to drop an exe file and maybe a DLL or two onto someone's system than the (ever growing) Perl distribution and the required modules. Heaven forbid I need to update Perl too. The software I distribute matches the version of Perl I've distributed with it. Always, and without hassle.The disk-space argument against perl2exe isn't holding much water lately either. I can distribute a perl2exe'd Perl program for about 2-3MB. My Perl installation (Activestate, including Tk) is about 40MB. So my tradeoff point on disk space is about 12 programs before I start "wasting" disk space. With 5.8 and 5.10 I'm sure that break-even point will be even higher.
In the long run it makes support and distribution so much easier to people who have *zero* interest in using Perl, just my applications.
I've distributed large (several thousand line) scripts using a lot of modules with lots of prerequisites (think Tk!) without problems. The *only* problem I run into are modules that aren't use'd until runtime need to be included manually before "compilation" into the exe (Tk is especially bad about this). That just means I need to test everything before I distribute it to make sure I've picked up all of the component modules.
My opinion: Do it. (Score:2, Informative)
The script is not small, it performs alot of grunt work (version labeling, coping to archives etc) and I have NEVER had any problem with it. The executables it produces are perhaps a little big as they include everything necessary to run the script, and of course, startup time sufferers, but in terms of convenience, it can't be beat!
My two cents anyway.
Ian
Perl2exe problems (Score:3, Informative)
1. Don't run the executables off a CD-ROM drive. They will run slow as dirt unless they are loaded from some sort fo fast media, faster than CD.
2. You may have to declare ("use" or "require") stuff you wouldn't have to normally. A good example is "Storable" that is used by some modules -- you may have to explicitly declare that in your code to get it to "compile" right. The program will actually tell you what you need, though (usually).
Don't... (Score:1)
Watch your per2exe version... (Score:1)
For example, v5.01 "compiles" scripts using the Socket module, but 5.03 bombs out on an @INC error.
5.03 will properly package up Net::FTP but 5.01 will not unless you also package Sockets.
Very unpredictable.
It's just a pain to have to keep different versions of perl2exe around and know when to use which depending on the code.
Other Perl Compilers? (Score:3, Interesting)
I've used IndigoStar's Perl2Exe for one 600-line CGI program that runs under FreeBSD. It works fine. The program I wrote provides a specialized form with lots of error-checking. Several people have access to the web site, including the customer's employees and all the employees of the web hosting provider. I didn't want someone changing or taking the code, so I wanted to compile the program.
De-Compile? I was told that it is difficult to decompile a Perl2Exe executable. I'm interested in hearing from anyone with experience with this.
Hide Perl Code? The HOT Ice [hotperl.com] "compiler" offers to obfuscate Perl code. Price: $3,995. As you might guess, I have no experience with this. Note that it does NOT compile the code.
You don't always want to give away your source code. How do you hide your Perl source code?
Other Perl Compilers? I'm very interested in hearing about other ways of compiling Perl programs. Perl2Exe is expensive, and tied to only one user. I've tried PerlCC and, as another comment poster said, was not able to get it to work. Apparently Perl2Exe is a cleaned-up version of a free Perl compiler. Is that correct?
Indy Singh is IndigoStar. Apparently the only person in the IndigoStar company is Indy Singh. He is friendly enough, but not always available for technical support. He sometimes hires help, I was told, but that person was not able to give tech support. I was told to wait two weeks until Indy Singh returned from vacation.
Philosophical question: On Slashdot it is politically correct to think that Perl is wonderful. However, it seems to me that every language should have both a compiler and interpreter. (CInt [root.cern.ch] is a C/C++ interpreter.) Several years ago, Perl was a quick and dirty way of doing simple things. Now Perl is a big language with all of the problems of other big languages, but is lacking in some of the tools. (For example, check out Perl IDE [sourceforge.net]. But, it is Windows only.) Perl debugging is primitive, too, it seems to me. I'd be interested in seeing an article that gives an overview of Perl debugging methods.
Wouldn't it have been better to put energy into a C interpreter, giving it the functions that are needed, rather than make a new language? Aren't some of the quick and dirty features of Perl now looking messy and dirty?
Re:Other Perl Compilers? (Score:2)
You don't always want to give away your source code. How do you hide your Perl source code?
As the RIAA have shown to us, copy protection mechanisms wrapped around inherintly open architectures (such as iso9660 or Perl) are usually quite easily broken.
In fact, copy-protected CDs appear quicker on kazaa than standard CDs. A license saying "do not redistribute" is as effective as the most expensive copy protection mechanism.
I have seen a few Perl programs with restrictive licences. Usually the most prominent thing about the licence and install instructions is the following:
chown priveleged_user program.pl
chmod 111 program.pl
I can't resist (Score:3, Funny)
cat
Hiding Perl source in an executable (Score:1)
The C program can then check a licence key, decrypt the embedded blob of Perl in memory, and eval the perl code.
The code to do this isn't that complex (see perlembed)
For this to work on Windows, you may need to replace any XS based Perl librarys you ship with it with pure Perl.
Any constants you use for socket based stuff, and sysread/syswrite you will need to find their Windows equivalents - I'm afraid I can't help you much there.
This may be something like what perl2exe does, although they may use the Bytecode interface or the modern equivalent of undump.
Re:Other Perl Compilers? (Score:2)
Isn't that an identity transformation?
Re:Other Perl Compilers? (Score:2)
Perl does a lot of things that would be hard to shoehorn into C, and handles a lot of things that C programmers have to handle for themselves. Perl is vastly more than an interpreted C.
You can argue that Python or Icon or Rexx or a dozen other languages are better then Perl's nitches but you can't argue that C is better; the people who wrote Perl, the people who first used and promoted Perl, and most the people who use Perl all knew C and like it or at least understand its strengths.
That's interesting. (Score:2)
"Perl does a lot of things that would be hard to shoehorn into C..."
That's interesting. Could you give me some examples?
Try PerlApp (Score:3, Interesting)
I also tried perl2exe, but found my money was better spent on the Activestate kit. With PerlApp I can bind data files and
To whomever thinks I should just go ahead and install Perl/modules/script/associated files - you can come work for me for free, there are only slightly over 500 desktop stations to distribute my application to.
--apsyrtes
Re: Try PerlApp (Score:2)
Unfortunately, Perlapp does not seem to support BSD, and supports only x86 architecture RedHat and Debian Linux. See Perl Dev Kit [activestate.com]
But, it is good to know PerlApp is available.
Large app? (Score:2)
Re:Large app? (Score:2)
You go from a high level language (like Perl) to a low level language (like C/C++) when you need speed, or you need to run it places where all the dependencies of the high level language are a burden. OTOH, high level languages let you do things easily that may be a pain to program on lower level languages (like regexs), and take care of things that you have to manually handle on lower level languages (like memory). You can add on libraries to handle the later, but a GC library won't run on "any platform with a compiler". So long as the user is happy with any limitations of your high level language (speed, possibly interpretation), then changing would be a lengthy rewrite for little win.
Try Tcl. (Score:1)
Tied PerlApp... (Score:2, Informative)
Ideally, I would upgrade all the machines, and have a shared site library for additional modules, but if until then, or for sites where you can't rely on perl being everywhere, PerlApp and perl2exe do a good job...