Terry,
can you achieve what you want using Threads or do you have a specific need
to create a Win32 process?
Threads and PAR work fine on Win32 to create multi-threaded applications.
Regards,
andy
----- Original Message -----
From: "Schupp Roderich (extern) Com MD PD SWP 2 CM MCH"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[email protected]>
Sent: Monday, July 04, 2005 10:34 AM
Subject: RE: Need to 'bring along' perl.exe, I guess . . . .
> But then, I copied this .exe to another system (one without
Perl) and ran it. It died, with:
E:\>foo.exe
: Win32::Process::Create() at IPC/Run.pm line 2097
: Win32::Process::Create() at IPC/Run.pm line 2216
: Win32::Process::Create() at IPC/Run.pm line 2216 A Perl
The problem here is that - on Win32 only - IPC::Run sometimes
wants to spawn another perl.exe (cf. _spawn_pumper on
IPC/Run/Win32IO.pm). The name of the perl executable running
a script should be found in $^X. But for a pp'ed script
this is just "perl". PAR really doesn't have a choice here,
because there is no perl.exe in the final executable created by pp,
so I guess you're out of luck here. Perhaps the FAQ should
mention this clearly ("any pp'ed program that uses $^X will fail
when run on a machine without Perl installed").
However, someone might hack PAR to make $^X work, because
you "almost" have a perl executable at hand: if you look into
the par-$USER temp directory for your pp'ed executable foo.exe
you'll see that it also contains a (different) foo.exe.
This is actually a custom perl executable, designed to run
in the par-$USER environment (wrt to DLLs and Perl modules).
It differs from a "real" perl only in the startup C code.
Perhaps it could be hacked to behave like a "real" perl
when invoked with special parameters? I always wanted a
similar hack, so that I can switch on Perl's debug mode
for a pp'ed executable.
Cheers, Roderich
