bug#75207: Fwd: bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8

["Michał Lach via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Forgot to CC the bug report mail.

> Begin forwarded message:
> 
> From: <michal@0lock.xyz>
> Subject: RE: bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8
> Date: 3 January 2025 at 02:48:53 CET
> To: "'Eli Zaretskii'" <eliz@gnu.org>
> Reply-To: <michal@0lock.xyz>
> 
> M-: (getenv "ENU") -> nil
> M-: current-locale-environment -> "ENG"
> M-: w32-ansi-code-page -> 65001
> M-: (default-value 'buffer-file-coding-system) -> iso-latin-1-dos
> 
>> That said, presenting a clear recipe could help us gradually improve 
>> support for
>> this, as Windows improves its part in parallel.
> 
> Here is the repro.
> 1. Put a path to your "PATH" environmental variable with some diacritic 
> character (ł in my case, maybe it won't work for some)
> 2. M-: exec-path returns gibberish
> 
> Here, "Michał" becomes "MichaÅ‚", you can get a similar result if you do 
> MultiByteToWideChar using Windows-1252 codepage on a UTF-8 path.
> 
> I've digged around and it looks like codepage_for_filenames (src/w32.c) at 
> somepoint returns the Windows-1252 codepage.
> This is then passed to MultiByteToWideChar() and the scenario that I 
> described above happens.
> I've checked this hypothesis with API Monitor and this is what actually 
> happens, I can attach a trace if you will find it useful.