Opened 4 years ago
Closed 3 years ago
#12409 closed defect (fixed)
WIN32: Cannot add games from non Ascii path
Reported by: | ZvikaZ | Owned by: | sluicebox |
---|---|---|---|
Priority: | normal | Component: | Port: Win32 |
Version: | Keywords: | i18n | |
Cc: | Game: |
Description
When adding a game that has a Hebrew letters (and probably, any other non standard ascii encoding) in its path, the game seems to be detected, an 'edit game' dialog is opened - but it has wrong path in Paths\Game Path:
.
If the dialog is approved, the game is added to the games list, but grayed out.
When starting the game, it says: Error running game: Path not a directory
.
In Linux (CentOS 7) it works (it has some font problem, so the Hebrew part of the path is shown as blanks under 'Game Path' menu, but that's minor, unrelated, issue).
Note: this is a regression, as it worked at release 2.2.0
Debugging this, I see that at
backends\dialogs\win32\win32-dialogs.cpp , line 93
HRESULT hr = item->GetDisplayName(SIGDN_FILESYSPATH, &name);
name
(which is a LPWSTR
) is encoded with UTF-16, and at lines 95-96:
char *str = Win32::unicodeToAnsi(name); path = Common::String(str);
it's transformed to a Common::String
, encoded with Windows-1255 (my local computer encoding).
I think that at this point, it should have been transformed to UTF-8 instead.
Furthermore, there are few functions that translate from LPWSTR
(Windows UTF-16) to local's computer ansi, and back - and I think they should all translate to UTF-8, and back, instead.
https://github.com/scummvm/scummvm/pull/2929 tries to solve this.
Change History (2)
comment:1 by , 4 years ago
Type: | patch → defect |
---|
comment:2 by , 3 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed with UNICODE support in Windows builds, which is now enabled by default: https://github.com/scummvm/scummvm/commit/2bca5da803cff5168cc72c9a21aae70b37f979d5