<div dir="auto">+1<div dir="auto"><br></div><div dir="auto">I think we already have done most of the work to enable this... minheadless is UNICODE already.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 mai 2020 à 09:23, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Hi<br>
<br>
I think we ought to define UNICODE and _UNICODE.<br>
-t<br>
<br>
> On 08.05.2020, at 09:14, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank" rel="noreferrer">marcel.taeumel@hpi.de</a>> wrote:<br>
> <br>
> ...on second thought: I might be better to first find all non-unicode calls, convert them, make sure everything works, then enable that UNICODE flag, and finally change all explicit unicode calls to "transparent" ones. :-)<br>
>> Am 08.05.2020 09:03:40 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank" rel="noreferrer">marcel.taeumel@hpi.de</a>>:<br>
>> <br>
>> Hi Eliot,<br>
>> <br>
>> I suppose we decided to make explicit use of the unicode functions. See <a href="https://devblogs.microsoft.com/oldnewthing/?p=40643" rel="noreferrer noreferrer" target="_blank">https://devblogs.microsoft.com/oldnewthing/?p=40643</a> -- Maybe this is from a time when our source held both ANSI and UNICODE variants. These days, we could simplify the code by defining -DUNICODE=1 and skip using, e.g., "GetWindowTextW" because then "GetWindowText" will automatically choose the unicode versions.<br>
>> <br>
>> I think that that -DUNICODE has never been part of some makefile.<br>
>> <br>
>> Best,<br>
>> Marcel<br>
>>> Am 07.05.2020 23:09:23 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank" rel="noreferrer">eliot.miranda@gmail.com</a>>:<br>
>>> <br>
>>> Hi All, especially Windows persons, <br>
>>> <br>
>>> I'm debugging the 64-bit VM in the context of Perf on win64. I've <br>
>>> just noticed that we don't appear to be building a UNICODE VM?!?! I rind <br>
>>> no define of UNICODE in the win32 platform files and no define of UNICODE <br>
>>> on the compiler command line in the build.winXXxYY/common makefiles. This <br>
>>> is surely a mistake, isn't it? If this is a regression, when and why did <br>
>>> this occur? I'm going to add -DUNICODE=1 to the Makefile.msvc makefiles. <br>
>>> AFAICT this should also happen with the Cygwin Makefiles. But before I <br>
>>> make changes that could affect lots of people I thought I should ask here. <br>
>>> Anyone know when and why we dropped -DUNICODE from the Cygwin build command <br>
>>> line? <br>
>>> <br>
>>> _,,,^..^,,,_ <br>
>>> best, Eliot <br>
>>> Hi All, especially Windows persons,<br>
>>> <br>
>>>    I'm debugging the 64-bit VM in the context of Perf on win64.  I've just noticed that we don't appear to be building a UNICODE VM?!?!  I rind no define of UNICODE in the win32 platform files and no define of UNICODE on the compiler command line in the build.winXXxYY/common makefiles.  This is surely a mistake, isn't it?  If this is a regression, when and why did this occur?  I'm going to add -DUNICODE=1 to the Makefile.msvc makefiles.  AFAICT this should also happen with the Cygwin Makefiles.  But before I make changes that could affect lots of people I thought I should ask here.  Anyone know when and why we dropped -DUNICODE from the Cygwin build command line?<br>
>>> <br>
>>> _,,,^..^,,,_<br>
>>> best, Eliot<br>
>>> <br>
<br>
<br>
</blockquote></div>