All the Perl that's Practical to Extract and Report

tinyperl and perlbin (perltobin) (and PAR)

bart on 2007-10-31T00:19:08

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.

Cava Packager

tunaboy on 2007-10-31T01:10:56

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.

Re:Cava Packager

bart on 2007-11-05T11:33:09

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. Not good. GUI's are supposed to make things simpler, aren't they?

    The root of my confusion is the requirement of a "project", where it is initially not clear what it is for. It doesn't use a default project (containing only the files for this one script) if you just to want to produce one exectutable for one script.

  • I don't like the file layout of the result: there's a bin directory for the executables, and a lib directory for the libraries (it doesn't combine the libraries into a single archive, which is not necessarily a bad thing). The exe file is burried in the bin directory.

    That may be the custom in Linux Land, but people using Windows expect the executable to be in the root directory of the location of the app. If you plan to be able to run executables without installation, the root is the most sensible location, IMO.

  • The packer renames the DLLs while copying to their new location, which isn't a bad idea in itself: I've had the experience in Win95 (loooong time ago) that it was simply impossible to load 2 different executables (and DLLs, which are executables too) with the same name, at the same time.

    I think that is the reason for the need of for projects, so different executables can reuse the same renamed DLLS.

    What isn't so nice is the opaqueness of the names, and the lack of information of which DLL got renamed to what. Maybe the info is there, but I haven't seen it.

    The ZIP packager packages a ZIP, file, which includes simply everything that's in its build directory. That includes files that may have been generated by the script itself in a test run. And I've got the impression it may contain quite a bit more files than needed.

But, all in all, this doesn't look like a bad packager. Quite the contrary.

Re:Cava Packager

tunaboy on 2007-11-05T14:57:17

From what I have experienced, the developer(s) of Cava are very receptive to feedback. I would pass on your list to them: support@cava.co.uk

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 default for all projects I believe). Modules included in this manner are not renamed, if I remember correctly, and placed in the inc subdirectory of the lib directory.

I am working on my own list of feedback to send, and I am sure yours would be appreciated.

Re:Cava Packager

wallasey on 2007-11-05T18:38:18

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 redesign of the whole thing.

Having read your comments on the file layout - I think you are right. My only requirement was that the executable should not be in the same directory as perl58.dll. As you say, it would make sense to have the executable(s) in the root of the build tree.

The mapping of file names isn't intentionally opaque. It just didn't occur to me that there would be a practical reason to need to know the mappings. I'll output mappings to logs in the next version.

All the files in the build directory are required. (Or at least the scanning process thinks they are required.) The first action on each build is to completely clear out the directories. Scanning does not write any files. If your script requires utf8 or POSIX somewhere in its dependencies, you will get a huge number of files. I guess providing mappings between 'real' file names and packaged names would make this whole aspect less opaque.

With regard to keeping the files separate, and not archiving them into a single file - that was the main reason for starting the project. PAR / pp gives a perfectly good archived/packed solution - I wanted a portable (between machines) tree that could run off a USB without the need for temp files. Working with wxPerl also means relatively huge DLLs - though I could live with the slow first time startup if that were the only drawback for my particular requirement.

You can package in a completely transparent way, without any renaming or attempting to obfuscate the source files on disk. I'd agree that it isn't immediately clear that this is an option.

Going back to your original question, my advice would be to start with PAR::Packer.
if
pp -o your.exe yourscript.pl
works for you, perhaps you could learn to live with the temp dirs?

Thanks for the constructive comments.

Mark

Temp files

jplindstrom on 2007-10-31T12:40:56

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 used some kind of Windows remote mumbo jumbo magic that didn't require any extra stuff on each machine.

Re:Temp files

bart on 2007-11-04T21:03:24

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 a Startup script, assigned to the computer in a Group Policy in Active Directory, so it runs when the computer boots
  • I can pretend that it's a program installer by producing a ZAP file that can be attached to a Group Policy in Active Directory, to be run at logon. Oddly enough (IMO), you can attach installers (MSI files, or ZAP) to group policies, but no ordinary executables. In that case, a ZAP file wrapper looks like the easier solution to me.
Tips for other solutions are most welcome.

Re:Temp files

bart on 2007-11-20T10:53:32

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.