[MPlayer-dev-eng] [PATCH]can not open ISO file including multibyte file path. on Windows.

[Tadashi Ando]

 > I think you are actually converting from UTF-8 to the local
 > 8-bit code-page (which usually isn't actually ANSI).

We should call it "Local Windows code page" ?
https://en.wikipedia.org/wiki/Windows_code_page#ANSI_code_page

 > It also means that while it's an improvement, it won't be
 > able to open files where the filename cannot be represented
 > in the local code-page.

I understood the problem.
It is true that, even applying my patch, it can not open "a file that 
can not be represented in the Local Windows code page".

But by my understanding, current MPlayer can not open "all files that 
represented in the multibytes" on Windows.
( More precisely, current MPlayer can open only "a file that match the 
represented in UTF-8, by luck, by chance". )

DVDOpen() finally calls ANSI Version CreateFile() ( = CreateFileA() ).
CreateFileA() expect "Local Windows code page" as file path.
But current MPlayer using UTF-8. It is completely wrong, logically.
( In most multibyte environments, the "Local Windows code page" and 
UTF-8 do not match. )

Is my understanding of this correct ?
( and if so, I think my patch is not best, but better than current. )

 > IMO a "proper" solution would be to make DVDOpen support UTF-8
 > file names,

"Ideally", I also think it is best.
Thank you for your advice.

 > or alternatively add a new DVDOpen variant that support
 > wchar_t input (then the stream_file code should be possible to
 > reuse).

I don't think it is good idea that implement DVDOpen() variant in MPlayer.
Because it is via external libraries. How do you think ?
In the DVDOpen(), actualy, file is opening in win2k_open() of libdvdcss 
external library.

# DVDOpen() is function of libdvdread, external library.
# DVDOpen() is internally calling dvdcss_open().
# dvdcss_open() is function of libdvdcss, another external library.
# dvdcss_open() is internally calling win2k_open() ( in libdvdcss ).
# win2k_open() calls CreateFileA().

 > Another option would be to pick the 8.3 compatibility file name
 > if we cannot represent the real name in the local code page.
 > It is a bit risky, since the 8.3 name will probably got away
 > at some point.

I do not want to think that much :)


Thank you and best regards,

-- 
Tadashi Ando