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.
That's not to say 32-bit wchar_t doesn't cause issues by itself for ports—you're potentially already in trouble if you ever write a wchar_t to disk or the network, of course. And having to convert between UTF-32 wchar_t, UTF-16 WCHAR for Win32 APIs, and UTF-8 for most Linux APIs isn't great either. Still, from experience with the vkmodelviewer port we did a while ago, my impression is that libvkd3d requiring -fshort-wchar would have made our lives a fair bit harder, and that was part of the reason we ended up supporting both 32-bit wchar_t and 16-bit WCHAR in the libvkd3d API.