Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

bart (450)

Journal of bart (450)

Tuesday October 30, 2007
07:19 PM

tinyperl and perlbin (perltobin) (and PAR)

[ #34795 ]

For my job I need to do the same few repetitive actions on about 35 Windows PCs. It's a kind of work that's quite tricky to do using the normal Windows GUI, but that is quite easy to script in Perl. There's still one problem: none of all these PCs has Perl, and I'm not going to install it for a simple, one time task.

So I was thinking of building a binary package from the script. I've always been quite impressed with Graciliano M. P.'s work on TinyPerl. So I decided to try to use it for this task.

I found it works pretty well, though there are a few warts:

  1. The special variable $0 has the value "-e", which makes it impossible for the script to find out its own directory, as I haven't found any other way to find that out
  2. Use of glob makes it crash. I suspect there's an incompatibility between the DLL of File::Glob and tinyperl.exe, because it crashes also when you just use tinyperl.exe instead of plain perl.exe, and not just when running the packed script.
  3. Its perl version is 5.8.0, which is not only quite old, but you know what they say about first releases of programs... that goes for Perl 5.8, too.
  4. It decompresses its lib archive (which is in a separate ZIP file) in the directory the executable is in, which is an activity that's frowned upon ever since Windows XP came out, now 5 years ago... yet all too many programs still try to write to the directory the executable is in.

    At least, PAR decompresses its archive (that is embedded in the executable itself instead of in a separate file) in a directory for temporary files. (Why do these files need to be decompressed to a file anyway? Why can't they be loaded from RAM instead?)

  5. The project appears abandoned, in fact, everything GMPASSOS has put on CPAN hasn't been updated since somewhere in 2005. He hasn't been on Perlmonks in 2 years, either. Where has he gone to? I have no idea...

Well that shatters any hope of getting any bugs fixed, at least, in a timely manner...

But somewhere on this project's homepage was a link to another, related Sourceforge project: PerlBin, from the formerly very active crazyinsomniac AKA PodMaster, who also vanished from the face of this earth...

I find it quite impressive. The project is only a Perl module, with a package of just 16k... and a script, called perltobin. You can allegedly use it for a vast array of platforms, provided you have a C compiler... or you can use the "binary" package for ActivePerl on Windows, either 5.6.x or 5.8.x, which doesn't require a C compiler at all the pre-compiled to-be-linked-in library is included in the distribution.

It has a different set of properties, from the same (limited) point of view (for this project):

  1. glob works, though you need to explicitely invoke File::Glob to include the necessary files that appears to be caused because Module::Dependency doesn't seem to catch it by default.
  2. $0 is set to the path of the executable file, so it can deduce its own file path
  3. Module files are copied into a file tree, not into a ZIP file. At least it doesn't require decompression into temp files, though for distribution it is quite large
  4. Even though the project hasn't been updated since, what? 4 years, it actually still works, combined with the most recent distribution of ActivePerl
  5. You have to manually delete the lib tree when you want to recompile the binary, after an edit.

BTW it appears to be built upon GMPassos' work, but with a different focus, apparently.

And then, there is PAR. I haven't tried it for this project, but even though it has the great advantage of producing just one executable file, it also has the disadvantage of building temp files for the modules when it runs, which makes the behaviour less than professional; just like TinyPerl, but unlike PerlApp/perl2exe (AFAIK). Somehow I always found PAR quite daunting, so this has always been a bit of a showstopper to me.

But I like having the choice between alternatives, and I can dream of a merged project, with a "best of all worlds", and one that doesn't need any tempfiles, as I'm quite sure that it must be possible. I just don't know how, yet.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Would Cava Packager [] suit your needs?

    I'm currently testing it for deploying some wxPerl applications. It is working quite well for me so far.

    Thought it might be worth mentioning.

    • Thanks. I had never heard of Cava Packer before, so I'm glad you brought it to my attention.

      I'm not sure what to think of it, so here's a list of my impressions:

      • I definitely don't like the fact that a program that is written in Perl, requires installation as administrator. WTF?
      • Though the GUI looks nice, it's also too hard to use. The first time I tried to use it, I really needed to follow the walkthrough example from the help file to get my first executable file compiled. I was totally lost without it.
      • From what I have experienced, the developer(s) of Cava are very receptive to feedback. I would pass on your list to them: [mailto]

        I believe the renaming of DLLs and library files is part of the "source code hiding" effort. I could be wrong for the motiviation behind the renaming, though.

        If you browse the list of "Scanned Modules" and double click one, there is a Packaged Location option which you can change to include modules in a "Standard @INC Folder" (and you can save this as a global de

      • Hi, I'm the developer behind Cava Packager.

        Installing as Admin - that's an error on my part with the installer. The application certainly does not need admin privileges. I'll ensure the next upload has this requirement removed.

        I am aware that the GUI has become confusing. I should have realised this when I decided it needed a 'quick start' guide. I'll be fixing that by adding a 'new project' wizard in the short term that takes you through minimum steps necessary to package a script, followed up by a r

  • PerlApp extracts to a temp directory, and I'm fairly certain perl2exe does too (unless either of these programs have changed this in the last couple of versions).

    And, even if they do, I don't quite see what's to get upset about that.

    I'd stick with PAR if I were you.

    And I'm trying to remember which win32 utility we used to use for deploying software to 20+ Windows load generating machines during performance testing, but I really can't seem to squeeze it out of my head... :/

    It was rather good anyway, since it
    • And, even if they do, I don't quite see what's to get upset about that.

      I consider it quite unprofessional. For example, it would be enough to stop me from thinking of building a program for distribution on CD-ROM, that is to be run directly from the CD, with it.

      I'd stick with PAR if I were you.

      I've only briefly tested PAR, and not recently, but just to be fair, I might test it again to compare it with the others.

      And I'm trying to remember which win32 utility we used to use for deploying software to 20+ Windows load generating machines during performance testing, but I really can't seem to squeeze it out of my head... :/

      Of, I would be so grateful if you could think of what it was... I've found a few possible solutions, but fewer options than I would have expected, and none that really pleases me:

      • I can put it in
      • Meh, .ZAP files don't work for installation deployment in Active Directory. It requires that it's an .MSI file.

        I just though I'd add it here so people searching with Google for a solution for the same problem won't get their hopes up too high.