[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    RE: Wine Source build on native wchar_t 4 bytes
From:       Puetz Kevin A <PuetzKevinA () JohnDeere ! com>
Date:       2022-12-05 15:42:40
Message-ID: DM6PR05MB67771017F985B970E6EEC0F8B5189 () DM6PR05MB6777 ! namprd05 ! prod ! outlook ! com
[Download RAW message or body]

> From: Esme Povirk (any/all) <esme@codeweavers.com> 
> Sent: Monday, November 7, 2022 4:03 PM
> 
> From what I remember, the assumption that WCHAR is 2 bytes is ubiquitous in Wine \
> code, so I don't think this approach can work without a large code cleanup.

Well, the fact that WCHAR is 2 bytes (and is utf-16) is part of Win32 ABI, and can't \
be changed at all. However, you can use winegcc to build your own winelib code (not \
wine itself) with -fno-short-wchar - in which case WCHAR instead not be wchar_t (it \
will be char16_t in c++11, or unsigned short in c). You can only do this when using \
glibc, rather than msvcrt , though, since you msvcrt uses wchar_t in its public API \
and is thus not compatible. Other windows APIs use WCHAR, so it works out. But this \
does make it possible to have a .dll.so (or .exe.so) which primarily uses \
glibc/libstdc++ but happens to have access to windows APIs.

Public


[prev in list] [next in list] [prev in thread] [next in thread]