AFAIK, GetACP can never return UTF-8, except if the program was compiled with those resources.
In the scenario I am describing, Make was compiled with the resource, so GetACP should return UTF-8 on the one hand. On the other hand though, since Make is running in Windows version < 1903, it shouldn't return UTF-8 because this functionality is not supported in that version. But yes, I will make sure to check this in practice. On Tue, 11 Apr 2023 at 14:46, Eli Zaretskii <e...@gnu.org> wrote: > > From: Costas Argyris <costas.argy...@gmail.com> > > Date: Tue, 11 Apr 2023 14:42:30 +0100 > > Cc: bug-make@gnu.org, Paul Smith <psm...@gnu.org> > > > >> I don't think this is needed: if GetACP returns the UTF-8 codepage, it > >> must be that UTF-8 is supported. I'm not aware of any way of > >> affecting GetACP other than by a manifest such as this one (or perhaps > >> making UTF-8 a system-wide default, which is fine by us). > > > > This is the scenario I am concerned about: > > > > Assume Make was built with UTF-8 support, and downloaded by a > > user running Windows < 1903. I am not sure what GetACP would > > return in this case - If it returns the legacy code page, despite the > > fact that the UTF-8 manifest is embedded in Make, then we are good. > > But if GetACP returns UTF-8, because of the manifest that was > > embedded at build time, this will be confusing because --version will > > say UTF-8 but Make will actually work in the legacy encoding because > > of the < 1903 Windows version. > > AFAIK, GetACP can never return UTF-8, except if the program was > compiled with those resources. > > > I haven't tested this though, so it might not even be a real issue, just > > noting it down to check it later when I have the implementation. > > Yes, verifying this would be good, thanks. >
