Sat Feb 17 12:27:14 2018: Request 124445 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Par-Packer 'falsifies' PerlTk server() and Win32 GetOSName() and
GetOSVersion() output on Windows 10
Broken in: (no value)
Severity: (no value)
Owner: RSCHUPP
Requestors: adr-perlc...@linuxtech.net
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=124445 >
On 2018-02-16 07:50:32, adr-perlc...@linuxtech.net wrote:
> It looks to me like Par-Packer is somehow intercepting and 'falsifying'
> the return values of these Perl functions.
Nope, PAR::Packer doesn't intercept and falsify anything.
I have a theory what's causing this (see below), but first, for the record:
- what version of Module::ScanDeps, PAR and PAR::Packer are you using?
- what version of Perl and what distro (Strawberry, ActiveState etc)?
- and most important: did you build PAR::Packer yourself or got it from
somwhere?
Now for the theory: the bug report
https://rt.cpan.org/Public/Bug/Display.html?id=90807
has some links to Microsoft docs which further link to
https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85).aspx
The key why this may be relevant is that an executable packed by PAR::Packer
contains a custom version of the Perl interpreter, i.e. not the original
perl.exe.
It's this interpreter that runs your script and all the packed modules.
According to the above docs, unless an executable was build with a special entry
in its manifest file, the function GetVersionExA (which is used by the Perl
module Win32)
will always report that you're running Windows 8 while in fact you may be
running
a higher version of Windows. I checked that perl/bin/perl.exe from
strawberry-perl-5.26.1.1-64bit has indeed been built with this magic incantation
in its manifest, but the custom Perl interpreter build by PAR::Packer is
missing it.
It will take me a few days to procure a Windows 10 machine, would you be
willing to
build PAR::Packer yourself with a tentative fix?
Cheers, Roderich
