Is anything enforcing this, or is the assumption that any Windows 10 system is at least this version? What happens if it isn't?

Is anything enforcing this, or is the assumption that any Windows 10 system is at least this version?

The latter. My attempt to enforce it was based on a wrong assumption.

What happens if it isn't?

My guess is that the application won't properly handle any symbols outside its default code page.

Can we maybe check the codepage early at startup (e.g. SetupEnvironment()) and fail if it isn't correct? This seems more thorough than any version check.

Can we maybe check the codepage early at startup (e.g. SetupEnvironment()) and fail if it isn't correct? This seems more thorough than any version check.

Thanks! Done.

In 1e826bf: Can the commit be updated to better explain why this is needed. Looking at mingw-w64, GetACP has returned CP_UTF8 since it was introduced. I'm guessing the same is happening with MSVC (although that's less relevant given it doesn't effect releases)? Given that, and the fact that according to https://github.com/bitcoin/bitcoin/pull/32380/files#r2096044476, we are just going to assume that a user is running a new enough version of Windows, and throw an assertion if the codepage isn't CP_UTF8, what is the app-manifest actually doing? Given the version setting from #32537 also didn't work, it's not clear why any of this is needed.

That's not how it's supposed to be. The default application codepage is something that the user can configure system-wide (there should be a checkbox: https://exploratory.io/note/exploratory/Enabling-UTF-8-on-Windows-hYc3yWL0).

The purpose of the application manifest is to override it so it is always UTF-8 for the application. Exactly what the microsoft documentation says here: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

This hasn't changed with newer windows versions, as far as i know, it's just that there is no usable UTF-8 codepage in earlier ones, so it cannot be set there.

I'm guessing the same is happening with MSVC (although that's less relevant given it doesn't effect releases)?

It's absolutely relevant to MSVC-build versions, even if it doesn't affect the release. If the code assumes the file path locale is UTF-8 and it isn't all kinds of ugly filename breakage will happen.

If GetACP always returns CP_UTF8 then i agree the check is meaningless, and we should find a meaningful check for "path codepage is UTF-8".

In 1e826bf: Can the commit be updated to better explain why this is needed. Looking at mingw-w64, GetACP has returned CP_UTF8 since it was introduced. I'm guessing the same is happening with MSVC (although that's less relevant given it doesn't effect releases)?

GetACP being compiled on Windows returns 1252, which is not the UTF-8 code page. And, basically, it would depend on the OS language settings.

Looking at mingw-w64, GetACP has returned CP_UTF8 since it was introduced.

I see it differently. I've cross-compiled this code:

#include <iostream>
#include <windows.h>

int main()
{
    std::cout << GetACP() << "\n";
}

and it prints 1252 on Windows.

fwiw: GetACP is a windows system function implemented in kernel32.dll, defined in the winnls.h header. There shouldn't be a mingw-specific definition.

CP_UTF8 is also defined in that header and has the following value:

#define CP_UTF8 65001

1252 is codepage windows-1252, a legacy encoding.