> > The pure existence of <include/tchar.h> in the Wine code base > > shows me, Wine is aimed to support TCHARs. So why don't you > > want to properly activate its functionality and take Winefile > > as an example how to use it? > > ... > > I know, I won't be able to convince you. Any one out there to > > support my point of view? ;-) > > the whole existance of the TCHAR type and associated functions is to > allow applications to be portable between ANSI and Unicode and therefore > avoid ugly #ifdefs for distinguishing between ANSI and Unicode. As it is > part of the Platform SDK at least since Windows 95 was released, I'm > sure many Win32 applications (still) rely on the TCHAR type. At least > the MFC library and ATL does and hence all MFC/ATL based applications > rely on that type too. > > So I really think Wine has to support the TCHAR type and all associated > functions/macros to stay as close to the Windows API as possible. > > And since it helps to avoid #ifdefs in application source, I think > that's a strong argument not to eliminate it from Winelib (includes). > Maybe these arguments help to convince you, Alexandre. ;-)
Thanks, Ralf. :-) ...and if something is present in the Winelib API, it should made available completely. Currently it is not possbile to use <tchar.h> in UNICODE mode. My patch changes this, and allows to compile Winefile (and also other applications) in UNICODE mode by using TCHAR as flexible character type. There is still another limitation when using <tchar.h>: You can't use Unix headers at the same time. This is the reason, I had to introduce an external module "unixcalls.c", which is not compiled using the default Makefile rules, but by a special rule without using msvcrt include files. Calling this "ugly" may be justifiable. But it's not the fault of Winefile, but that of the incomplete <tchar.h> support. Regards, Martin
