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();