Henri Verbeet hverbeet@gmail.com writes:
On Sat, 13 Apr 2019 at 17:29, Alexandre Julliard julliard@winehq.org wrote:
Henri Verbeet hverbeet@gmail.com writes:
On Sat, 13 Apr 2019 at 11:19, Alexandre Julliard julliard@winehq.org wrote:
Rather than converting everything over to u"", I'd prefer that we find ways to use L"".
For instance, I'm currently working on building more modules with MSVCRT, and converting them to use wchar functions instead of unicode.h. Such modules could be built with -fshort-wchar. Ultimately this would hopefully cover a large fraction of the code base.
D3D code doesn't have a lot of UTF-16 string literals, so this is perhaps more curiosity than anything else, but other than legacy compiler support, are there any other advantages of L"" over u""? My impression was that -fshort-wchar was fairly hopeless as soon as you use any external API with wchar_t in it, including e.g. libstdc++.
I don't expect that we'll be using libstdc++ in Wine anytime soon. And there are very few other wchar_t APIs that we would want to use, that's too painful.
As far as porting code with Winelib, existing Windows code would already be using L"" everywhere, so having a solution for that would be better than requiring a massive search/replace.
I was mainly thinking about winelib, yes. I wouldn't expect Wine to use libstdc++ anytime soon if I can help it :D, but a winelib application linking against libstdc++ or e.g. Qt or SDL seems less unlikely. And where a L"" -> u"" replacement seems fairly straightforward, the potential issues arising from -fshort-wchar strike me as more problematic.
In practice, mixing libstdc++ and Winelib doesn't work well, for many other reasons. What most people end up doing is to continue to build against the Windows runtime and ship PE binaries.
But if someone really wants to do a proper port, both -fshort-wchar and u"" would be possible, depending on the situation. Just because we pick one for internal Wine code doesn't mean you have to do the same for every Winelib app.