Win32 launcher: embed Perl

[dolmen]

The current launcher runs WPerl.exe with the 'padre' script as an argument. This launcher has the current flaws:

• the Padre process is "wperl.exe" in the task list
• 2 processes are used to

Merging WPerl.exe in Padre.exe would fix those flaws. This is done by embedding Perl.

The launcher source is linked to the perl interpreter, so for maximum compatibility with the perl used on the user platform, the padre.exe would be compiled at install time. The old launcher would be still distributed in binary form as a fallback if build fails.
For ActivePerl?, distribution would be as PPM, so pre-built.

I'm working on this feature.

[dolmen]

Main launcher source, with embeded Perl.

[dolmen]

Build script

[dolmen]

Here is a prototype to get early feedback.

The build.PL is for the moment too simple (but enough for testing) and would have to be called from the main Padre install script.

The other files required (padre-rc.rc, padre-rc.h) are still the ones committed in [8690].

[Sewi]

Committed r8701

[dolmen]

Hum, hum...

As I wrote, it is a "prototype". It is a bit early to commit it. Also I wrote above that the previous launcher should be preserved.

This bug is a place to follow my work on this matter until it is ready.

So it would be better to revert the commit for the moment.

[azawawi]

Any update on this one?

[dolmen]

My main concern at the time was that the Padre.exe was not built at install time.
But this has been fixed since.

The other concern with the current code is that in the Padre environment $^{X will be padre.exe (currently it is wperl.exe). But as I'm faking the perl environment command line ([ "padre.exe", @ARGV ] is transformed into [ "padre.exe", "--", "padre", @ARGV ]), any call to $}X will relaunch the padre script and open the argument instead of running the script.
So we have to fix $^{X to point to perl.exe or wperl.exe.
I think we could find where wperl.exe is by finding where the perlxxx.dll has been loaded from by the system linker.}

[dolmen]

Unfinished launcher (need binding of $X to swWPerlExe)

[dolmen]

Here is an improved version, but still incomplete.

I need help from someone that knows more about embedding Perl: the code lacks the binding of $^{X to szWPerlExe.}

[dolmen]

According to Vincent Pit, here is how to set $^X:

SV *sv = GvSV(gv_fetchpvs("\030", GV_ADD|GV_NOTQUAL, SVt_PV)); sv_setpvs(sv, "wut"); SvSETMAGIC(sv);

[dolmen]

Eureka! The $^{X issue is fixed!}

Here is the final patch:

• New launcher which embed Perl, so the Padre process appears as Padre.exe instead of wperl.exe
• Manifest file is now embeded as a resource in the executable (padre.exe.manifest replaces wperl.exe.manifest), so less impact of other applications using wperl.exe
• The executable is now built using the same flags as Perl.exe using ExtUtils::Embed

[dolmen]

Patch with the great new Padre launcher ($^{X issue fixed, build improved)}

[CSJewell]

Thanks, dolmen!

[dolmen]

Here is an improved version of the patch:

• generates the xs_init() function using ExtUtils::Embed::xsinit (see perlembed)
• updates win32/README to describe the new launcher
• resource file (padre-rc.rc) is now compiled as a COFF file (.res) which is a step towards compatibility with MSVC
• fixed the manifest resource ID to really enable Vista/7 styles (verified on Win7)

Note that the win32/wperl.exe.manifest must be renamed (svn move) to padre.exe.manifest before applying the patch as 'svn diff' doesn't report renames.

[dolmen]

Updated patch : fixed manifest res id, improved build, added README update

[dolmen]

Committed by myself in r11150. Thanks for the commit bit.

[azawawi]

dolmen++ # for the great commit :)

Closing bug after 18 months :)