<div dir="ltr"><div>In 2004, somebody has asked a question:</div><div><a href="http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html" target="_blank">http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html</a>
</div><div><br></div><div>The reply from Alexandre was:</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


> Either there should be a overriding "wine/include/msvcrt/tchar.h"<br>> file with different defintions. Or the error message "You must use<br>> msvcrt when building in Unicode/MBCS mode" is simply superfluous.<br>


It's not superfluous, but it probably needs a !defined(__MSVCRT__) in<br>there.</blockquote></div><div><br></div><div>From what I see, today the situation is still the same.</div><div>Is it simply because nobody has dealt with it?</div>


<div><br></div><div>In any case, I've implemented Alexandre's change locally (in tchar.h).</div><div><br></div><div>Now I'll be trying to use winelib's msvcrt with my code. It seems like a "damned if you do,</div>

<div>damned if you don't" kind of thing. One issue I'm having now is wine/msvcrt being in the</div><div>system includes path, thus causing libstdc++ to load winelib's <wchar.h>. Of course,</div><div>

this didn't go too well :-)</div><div><br></div><div>My goal is to have a Linux app that's, generally speaking, a native app. I have the cooperation</div><div>of the codebase developers, so they can follow directions to keep the code reasonably portable.</div>

<div>At the same time, I don't want to burden them with mundane changes, so if Winelib can bridge</div><div>over the two worlds sometimes, it'd be great.</div><div><br></div><div>Perhaps we can have tchar.h operate in two modes:</div>

<div>1) a MSVCRT mode, where all the MSVCRT goodies are available,</div><div>2) a glibc mode, where it tries to map as many functions to glibc as possible?</div></div>