in reply to confusing result from Win32::GetACP()

The Active Code Page is the encoding used by the "A" functions of the Windows API (as opposed to the "W" functions which use UTF-16le).

The ACP was system-wide until very recently, and it's based on Windows's language. A US English Windows uses 1252.

An application can now choose to use UTF-8 (65001) instead.

Did you perhaps change your perl's code page to UTF-8 using this procedure?

could it be a bug?

No.

Replies are listed 'Best First'.
Re^2: confusing result from Win32::GetACP()
by hexcoder (Curate) on Aug 20, 2025 at 14:32 UTC
    Thanks!
    I did activate that checkbox Beta: Use Unicode UTF-8 for worldwide language support while experimenting last week, but since then I have switched back and rebooted several times. Now it is definitively deactivated. Could this be a caching effect?

    Also I wonder, how would you write the test for Win32::getACP() to actually compare the return value against the value reported by windows. Currently it is like this and rather coarse: 

    use strict;
use Test;
use Win32;

#plan tests => 8;

my $ansicp = Win32::GetACP();
ok($ansicp > 0 && $ansicp <= 65001);

    [download]
[reply]
[d/l]
[select]

      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.

[reply]
[d/l]
[select]
        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.
[reply]

In Section Seekers of Perl Wisdom