<div dir="ltr"><div dir="ltr"><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le ven. 4 janv. 2019 à 12:35, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>So I have made good progress in making Win32/64 VM -DUNICODE compatible.</div><div><div>minheadless VM already uses -DUNICODE, so all should go well... but...</div><div><br></div>But now I have some conflicts with minheadless VM.</div>- minheadless defines warnPrintf as printf (thus taking a char *)<div><div>- regular platforms/win32/vm defines it as taking a TCHAR*</div><div><br></div><div>it did before me, I did not change it, I just made sure that every sender would provide a TCHAR* thru TEXT() macro. By fixing platforms/win32/plugins for -DUNICODE compatibility, I thus broke win32 minheadless</div><div><br></div><div>The problem is not completely blocking: we can just ignore compiler warnings for the moment. Then if the plugin are verbose, the output will be truncated or garbled...<br></div><div><br></div><div>But if we are serious, then we need to unify.<br></div><div>The question is what are the expectations concerning error/warning outputs?</div><div>The windows console do handle UTF16 (WCHAR).</div><div>But maybe we don't want to output to console?</div><div><div><br></div><div>Another consideration:</div><div>- if warnPrintf is used in paltforms/Cross then its signature MUST NOT change from one architecture to another. Before minheadless, it was not used in Cross.</div><div>- if warnPrintf is used in several platforms/specific_arch it may take different signatures... but it should rather not, because this is dangerous for us programmers: the risk of making a mistake grows high, the ability to easily review code changes drops down. That's unfortunately the case.</div><div> </div><div><br></div><div>For the case of different signatures, I would be inclined to have different names.</div><br></div><div>We also have printLastError in windows... which is like perror on Unix, but takes a TCHAR*</div><div>DPRINTF for debug purposes which may take many different forms, including warnPrintf.</div><div>DBGPRINTF same.</div><div>And plenty of direct usage of printf perror...<br></div><div><br></div><div>There are basically two points of view:</div><div>- all these functions are services provided by the VM. A plugin should not decide to bypass the VM and directly call underlying OS low level functions. We should then try to officialize those services</div><div>- we stick to standard IO stdin stdout stderr paradigm (which might naturally be the point of view of a minheadless VM), but then what about OS conventions like encoding?<br></div><div><br></div><div>Thoughts?<br></div><div><br></div></div></div></blockquote><div><br></div><div>These small steps will guide me for the immediate problem:</div><div>- 1) have all warnPrintf defined as taking a char * so as to be uniform across platforms and compatible with minheadless<br></div><div>- 2) provide a warnPrintfW (and warnPrintfT macro for UNICODE agnostic code) for the rare cases that may require Wide char</div><div>- 3) define warnPrintfW/T in minheadless too, somewhere in the windows specific headers (it can be simply defined as wprintf)<br></div><br></div></div>