22 Jun 2005 22:37:34 +0200, Alexandre Julliard <[EMAIL PROTECTED]>:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
>
> > Let me change the question: Why should one use Unicode on those
> > systems at all? They don't support Unicode file systems - so there are
> > no 16 bit file names to display.
>
> No, but using Unicode doesn't hurt, and is easier than going through
> the effort of not using it.
It hurts my sense of avoiding waste to fill each second byte with
zero, just to let another layer (unicows) remove it again. Native
solutions are always better. You don't accept that. OK.
Likewise hurts the current representation of wide character string
constants instead of using -fshort-wchar my sense of prettiness. You
care more about compatibility to some outdated compilers. OK. But
that's another topic.
> > 3.) Wine's TCHAR support is not complete. You didn't answer on this fact
> > yet.
> > This makes the proper implementation of TCHAR usage combined with Unix
> > calls kind of ugly. So you don't like it.
>
> You cannot combine TCHAR with Unix, because Unix doesn't use the same
> size of wide character. There is no way this can be made to work with
> the tchar.h macros.
This is only one side of the medal. It makes impossible using tchar.h
with -DUNICODE together with unix header files in one compilation
module. But my patch shows, it would be possible to use -DUNICODE
together with <tchar.h> by just a few changes. Currently you only get
those missleading error message "You must use msvcrt when building in
Unicode/MBCS mode".
Regards,
Martin
