[PATCH] gdi32: Reformat some strings to improve readability

[Henri Verbeet]

On Sat, 13 Apr 2019 at 17:29, Alexandre Julliard <julliard at winehq.org> wrote:
> Henri Verbeet <hverbeet at gmail.com> writes:
> > On Sat, 13 Apr 2019 at 11:19, Alexandre Julliard <julliard at 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.