Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Well Does Perl2exe Work for Large Applications?

Posted by Cliff on from the script-is-to-executable-as-dynamic-is-to-static dept.

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."

5 of 51 comments (clear)

  1. My advice: Do by Mr_Silver · · Score: 4, Interesting
    Argh! Sometimes its really obvious that people who write comments like this have never deployed programs, don't think about users or perversly like using a sledgehammer to break a nut.

    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.

    --
    Avantslash - View Slashdot cleanly on your mobile phone.
  2. My experience by Boglin · · Score: 4, Interesting
    A couple of years back, I was writing a small program for language translation and I needed it to run on my classmates' Windows machines. Due to the heavy text processing nature of the project, Perl seemed like the prime choice. However, I knew there wasn't a wicket's chance in a supernova that I was going to get the end users to install Perl.

    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.

  3. It can be a godsend by n9hmg · · Score: 4, Interesting

    Depending on your application, it can be an enormous help. Building the apps fully static lets you work on your application in perl, edit, run, modify, debug, enhance, run, etc. on your development machine, then slap out a binary that can be run on any other windoze machine by simply getting that machine access to the executable. You're not messing with the registry, sticking DLLs all over the place, and taking up disk space with a development system when all you need is to run the program you wrote with your development system. Sure, the individual binary is enormous, for what it does, at least, at small amounts of code (as the app grows, the overhead shrinks into insignificance).
    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.

  4. Other Perl Compilers? by Futurepower(R) · · 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 "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 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. 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?

  5. Try PerlApp by apsyrtes · · Score: 3, Interesting

    I use PerlApp from the Perl Dev Kit by Activestate. I'd highly recommend the whole suite, it's been well worth the money for me (make executables, make windows services, make ActiveX controls, generate .MSI install packages, a kickass debugger, and a couple other goodies)

    I also tried perl2exe, but found my money was better spent on the Activestate kit. With PerlApp I can bind data files and .DLLs in the .EXE to be extracted/used at runtime, not sure if that can be done with perl2exe (correct me if I'm wrong!)

    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