Hi Malcolm,
I'm really short on time these days, so I could only skim your
explanation and code. Sorry.
m.nooning schrieb:
Malcolm Nooning wrote:
How can I identify the bundled perl binary from within a pp created
executable? Perl will NOT be installed on the end user's machine.
Specifically, I would like to do something like this:
Win32::Process::Create($ProcessObj,
"full_path_to_the_by now_unwrapped_perl.exe",
"perl.exe bundled_perl_file.pl",
0,
NORMAL_PRIORITY_CLASS,
".")|| die ErrorReport();
I have need for one process to watch another and kill it if there is a
problem. Since I use Tk, which is not thread safe, I cannot use the
Windows fork (Perl 5.8.8 + fork + Tk worked on Windows XP but not on
Windows 2000).
Another solution would be to create a separate pp'd .exe to be
executed as the Win32::Process::Create invoked process. However, the
extra time taken up in the initial unwrapping/unbundling, etcetera,
would seem unpalatable. That is why I am hoping for a scheme wherein
I could use the by-then already unbundled perl.exe.
A quick search reveals that there is no perl.exe anywhere under the
par-malcolm directory. My next question is then ... how could my end
goal be reached?
Possibly. Eric pointed out that strictly speaking, you have no perl.exe.
I would like a mode of parl.exe which just executes some given perl
code, but AFAICT, there is none right now.
Additionally, there are several things that may happen depending how
your perl was built (static/dynamic). I don't fully understand this
whole process so I won't try to present my half-wits now.
I "solved" a similar problem. I wanted to embed one pp'd exe into
another. I made them share the cache dir. Not sure whether it solves
your problem, but I wrote it up in my use.perl journal. Perhaps it
helps: http://use.perl.org/~tsee/journal/32140
I'm sorry I can't help you with this right now. It would be great if we
had a better understanding of how the whole parl thing works. Then, we
could also produce permanently "installed" versions of programs a la:
pp -o foo-installer.exe --installer 'foo.exe' foo.pl
And then on the target system:
foo-installer.exe c:/programs/foo
and, without unpacking-penalty:
c:/programs/foo/foo.exe ==> runs application
This is intimately related to how the unpacking and @INC searching
works. This would touch pretty much every aspect of how PAR/pp work
their magic. For example, it's related to the unpacking issues Chris
Dolan talked about recently.
If I find the time in the coming weeks or months, rather high on my todo
list is to understand how PAR unpacks what under what circumstances. I
hope that once I grok that, Chris or I or somebody else can go ahead and
make the changes Chris and I talked about in his "Extract to CRC-named
file or original-named file" thread. That would then go a long way
towards making this use case (installer and resource sharing) more feasible.
Steffen
