GetACP returns the value reported by Windows. Windows reports the encoding the application must use, which is 65001 for your perl. Again, this (now) varies by process (just like chcp).

To test if Win32::GetACP and thus Windows's GetACP return the correct value, you'd have to re-implement Windows's GetACP. That's just not feasible. You'd actually be testing your re-implementation, not Win32::GetACP.

The following is the implementation of the Perl sub / XS function:

XS(w32_GetACP)
{
    dXSARGS;
    if (items)
        Perl_croak(aTHX_ "usage: Win32::GetACP()");
    EXTEND(SP,1);
    XSRETURN_IV(GetACP());
}
[download]

As you can see, it simply calls GetACP.

And please stop calling it the ANSI Code Page. These calls (including the Power Shell one) all return the *Active* Code Page, which is going to be *one of* the ANSI Code Pages (as opposed to one of OEM Code Pages), and the ANSI Code Pages *aren't ANSI*.

For example, 1250 and 1252 are "ANSI" Code Pages, but the process only has one Active Code Page which may or may not be 1250 or 1252.

For example, 1252 was based on the what became the ANSI standard for iso-8851-1, but 1252 is different from the ANSI standard / iso-8859-1.

Thanks. I completely agree with your analysis, that's why I am so puzzled with the result.

Before going insane, I thought about "getting a second opinion" and installed another portable version of Strawberry Perl (5.40.2.1 64-bit). When running the one-liner there, I get the expected result (1252).

So, depending on the Perl version i use, I get 1252 or 65001 as a result. Clearly there must be something fishy in the previous Perl installation, but it seems difficult to debug.

And please stop calling it the ANSI Code Page.

Ok, will do. My impression was that this the official wording.

Hello hexcoder,

I always get 1252 with my strawberries plus an error for 5.12

 | Use of inherited AUTOLOAD for non-method Win32::GetACP() is depreca
+ted at
 | -e line 1.
 | Can't locate auto/Win32/GetACP.al in @INC (@INC contains:
 | ./perl5.12-32bit/perl/site/lib
 | ./perl5.12-32bit/perl/vendor/lib
 | ./perl5.12-32bit/perl/lib .) at -e line 1
[OK] .\perl5.12-32bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.20.64bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.22.64bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.24.64bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.26.64bit\perl\bin\perl.exe

 | 1252
[OK] .\perl-5.26.64bit-PDL\perl\bin\perl.exe

 | 1252
[OK] .\perl5.28.32bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.28-64bit\perl\bin\perl.exe

 | 1252
[OK] .\perl5.32\perl\bin\perl.exe

 | 1252
[OK] .\perl5.32.64bit\perl\bin\perl.exe
[download]

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

IMO getting the perl manifest changed to use ACP 65001 is the ideal configuration, anyway. This allows you to write unicode filenames on Windows the same as on Linux (encode to utf-8 first). Otherwise if you want to write a character that isn't in your codepage you need a bunch of special cases like if ($^O eq 'MSWin32') { OpenFileW($name); ... }