DONT MERGE - WIN32: Use Unicode for paths #2914
Before this commit, Windows returned path names with local computer encoding, and then ScummVM converted them to
This commit ensures that Windows returns Unicode paths.
When scummvm.ini is opened in GVim, the Hebrew path isn't rendered correctly. However,
Codacy fails, with:
However, I have only changed the codepage. The rest of these lines is similar to before. Do we want to change something in these lines? Or can we safely ignore these warnings?
(BTW, it's weird that Codacy complains about the original lines, before my changes - I have modified
grepping found that there's another instance of
We should be aware that this PR doesn't provide safe migration for users that already have non ascii characters in their game paths, as they are encoded in the local encoding, which ScummVM isn't aware of. However, this PR still improves the situation, because anyway, currently these games simply won't work as ScummVM doesn't understand the old path encoding. So, either with this PR, or without it, we're not backward compatible. This PR at least allows the users to re-add those games.
I can't speak to the existing encoding situation or its problems, but unconditionally defining UNICODE is a problem.
windows-fs.cpp is full of
UNICODE (and _UNICODE) should be consistently defined/undefined across an entire program and not per cpp. Otherwise TCHAR usage in headers (windows-fs.h, SDK headers, etc) could be char or wchar_t depending on which cpp gets compiled first. If you're unconditionally defining UNICODE then you don't need TCHARs at all because that gives the illusion of char/wchar_t compatibility when it doesn't exist, but you don't want to be unconditionally defining UNICODE in source at all because...
Most importantly, this will break the beloved Win98 build. (Okay maybe just @SupSuper loves it.) The Win32 API calls that take strings will now always link to the wide-char versions.
I'm not familiar with any of this code, just saw that the change started with
That's a good point!
Anyway, now there are many compilation errors, as it seems we have a lot of code that depends on UNICODE being not defined.
I assume I can fix them all, but I'd like first to be sure that I'm on the right path, before investing time and energy in this...