<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 4 Jan 2019 at 19:36, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<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></div></blockquote><div><br></div><div>Just a view from the side-court.  It seems coordination between platforms has been fragmented in the past.</div><div>Understandable since many contributors probably didn't have a testing-farm on hand to test all platforms</div><div>making it was easier and safer to just modify the platform being worked on directly.</div><div>But now we have a good CI infrastructure in place to observe the impact all platforms so help can be requested</div><div>if a developer doesn't have a local installation of a particular platform, officializing those services seems the right way to go.</div><div>That would include promoting them with documentation so its easy for newcomers to know the "right way" to do it.</div><div>Perhaps even code quality tests guarding against the low level functions being introduced (but maybe thats a step too far)</div><div><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><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?</div></div></div></blockquote><div><br></div><div>The consideration would be how often encoding issues will bump developers out of the "flow" of what they really want to focus on.<br>i.e. What is the balance of account to pay-now or pay-later.  I haven't dealt much with encoding issues, so I can't judge. </div><div><br></div><div>cheers -ben</div></div></div>