perlapp -f my_script.pl

now you will have a program called my_script.exe that will work on a computer that doesn't have Perl. there are a lot of other cool options availible with Perlapp see perlapp --help

The PDK PerlApp Docs say that it creates freestanding executables by default. Also, you can create freestanding executables with the evaluation version but they will stop working when the evaluation period ends. Just be sure that you are using the latest version because it fixes some bugs.

If you run perlapp with the --xclude command line option (which I don't recommend), you will need to include perl56.dll with your program in order for it to work.

So you can call your executable like this:


my $command = ".\\destroy.exe"; # change path as needed
my $args = "";
my $process;
Win32::Process::Create($process,
    $command,
    $args,
    0,
    DETACHED_PROCESS,
    '.') || &error(); # fixed typo
[download]

Update: I think the code sample is right. If not, can someone please tell me what is wrong with it?

Perl doesn't need to be "installed" -- you just need to bundle the files perl needs along with your own code. If you aren't using huge modules like LWP or Tk, the number of files you need is actually very small. (You can get by with as few as 2 on Win32.) I posted the techniques I use to bundle applications in How to minimize size of perl install?.

There are two advantages to bundling perl as a small set of individual files:

• People can still read and change your code. They might find bugs for you or add features.
• If you have a collection of scripts, each of those scripts can share the same perl infrastructure. You can easily upgrade and expand perl as you add new applications.

$0 is the full path to the running script. $^X is the full path to the running perl.exe. Under Win32, @INC automatically includes the directory perl.exe is in, so you don't need to worry about that.

Your example above can be written more portably as:

my $destroy = $0;
   $destroy =~ s/\w+(\.pl)?$/destroy.pl/;
my $process;
Win32::Process::Create($process,
                       $^X, qq(perl.exe $destroy),
                       0, DETACHED_PROCESS,
                       '.') || &error();
[download]

That will look for destroy.pl in the same place as the currently running script is stored. It will start the same perl.exe. Of course, you don't need a fancy Win32 module to do that! This will work just as well: open(CHILD, qq(|"$^X" $destroy)) || &error();

My problem is when I generate a stand-alone executable using PerlApp, I cannot run it on a machine which does not have perl installed. Not even on a machine where perl is not installed on c: directory.

I tried to create destroy.exe and have it in the same folder as the main program, but that did not work either.

I don't know what it does under PerlApp. I can recall experimenting with FindBin on a program processed with perl2exe (which is a similar product as PerlApp, from IndigoStar, and it failed to work correctly on W2K. I now no longer have access to that particular machine.

So, what can you do? Can you fork()? There is a proper working fork emulation on 5.6.x perls for Win32.

Another thought is for the program to launch itself again, with a command line switch (in $args) to tell itself to execute that other functionality. I think that is currently your best option for under PerlApp.