move Win32's $^X code to where all other OSes' $^X code lives

Back when the code in perllib.c was first added in 1999, in
commit 80252599d4 the large define tree function that today in 2015 is
Perl_set_caret_X was an unremarkable single statement
http://perl5.git.perl.org/perl.git/blob/80252599d4b7fb26eec4e3a0f451b4387c5dcc19:/perl.c#l2658

Over the years Perl_set_caret_X grew and grew with OS specific code. Move
the Win32 $^X code to match how all the other OSes do it. Fix a problem
where full perl's $^X is always absolute because perl5**.dll uses
GetModuleFileNameW in perllib.c, but miniperl's $^X is always a relative
path because it's coming from libc/command prompt/make tool/make_ext.pl.
Win32 miniperl's $^X being relative causes inefficiencies in EUMM as a
relative $^X is wrong the moment chdir executes in any perl process.
EUMM contains code to search PATH and some other places to guess/figure out
the absolute patch to the current perl to write the absolute perl path
into the makefile. By making $^X absolute on all Win32 perl build variants,
this find absolute perl path code won't execute in EUMM. It also harmonizes
behavior with other OSes and between Win32 mini and full perl. See details
in RT ticket for this patch.

1 files changed, 8 insertions, 0 deletions

diff --git a/caretx.c b/caretx.c
index fe884e46ef..67b8418795 100644
--- a/caretx.c
+++ b/caretx.c
@@ -126,6 +126,14 @@ Perl_set_caret_X(pTHX) {
         sv_setpvn(caret_x, buf, len);
         return;
     }
+#  elif defined(WIN32)
+    char *ansi;
+    WCHAR widename[MAX_PATH];
+    GetModuleFileNameW(NULL, widename, sizeof(widename)/sizeof(WCHAR));
+    ansi = win32_ansipath(widename);
+    sv_setpv(caret_x, ansi);
+    win32_free(ansi);
+    return;
 #  endif
     /* Fallback to this:  */
     sv_setpv(caret_x, PL_origargv[0]);