GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname

[Troy Rollo]

On Tue, 22 Nov 2005 06:54, Alexandre Julliard wrote:
> 2) is the right behavior. The A functions always return strings in the
> Ansi codepage, not in the Unix one. There is no Windows locale that
> uses UTF-8 as Ansi codepage, so if a UTF-8 string is returned to the
> application that's a bug.

This is of course correct for the GetOpenFileNameA and GetSaveFileNameA.

For the UNIX path entry points in the UNIX paths branch 
(WineOSFSGetOpenFileNameA and WineOSFSGetSaveFileNameA), the correct 
behaviour is to return the string in the UNIX locale character set.

The difficulty for the UnixFS code is that it sometimes has to convert using 
the UNIX locale character set (CP_UNIX), and sometimes with the Win32 one 
(CP_ACP), depending on the context. It may be that in some cases the wrong 
one is being used.