Hi,
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. ;-)
Regards Ralf
"Ralf Reiterer" ralfreit@gmx.at writes:
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.
Wine obviously supports TCHAR, that doesn't mean you want to use it in new code. We have 16-bit support too but nobody advocates writing new 16-bit applications.
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. ;-)
It doesn't help avoiding #ifdefs, on the contrary it requires a lot more #ifdefs, and makes the code a lot more fragile. It's a nasty hack that should be left to die a (hopefully painful) death.
22 Jun 2005 10:56:18 +0200, Alexandre Julliard julliard@winehq.org:
"Ralf Reiterer" ralfreit@gmx.at writes:
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.
Wine obviously supports TCHAR, that doesn't mean you want to use it in new code. We have 16-bit support too but nobody advocates writing new 16-bit applications.
Winefile is not really "new code", it started back in the year 2000. And as I pointed out yesterday, Wine's support for TCHAR is currently incomplete.
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. ;-)
It doesn't help avoiding #ifdefs, on the contrary it requires a lot more #ifdefs, and makes the code a lot more fragile.
More #ifdefs compared to an application without UNICODE/ANSI support or using unicows. Yes. But unicows is also only a bad option.
It's a nasty hack that should be left to die a (hopefully painful) death.
It will not die before MS will drop backward compatibility. And this may take centuries, if ever.
Regards,
Martin
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.
Wine obviously supports TCHAR, that doesn't mean you want to use it in new code. We have 16-bit support too but nobody advocates writing new 16-bit applications.
I of course know that Wine supports the TCHAR. However your response to Martin's mail sounded like you want to get rid of TCHAR and tchar.h as fast as possible. So my reply has to be read in that context and should have been written as "...Wine has to continue the support of the TCHAR type and all associated functions/macros...".
My point is that many existing apps (and all MFC/ATL based apps) rely on that type and the _tcs* functions. In case of MFC/ATL the library itself relies on them and won't no longer be compilable with Winelib when tchar.h is missing. So it's much like the 16-bit support you mentioned, with the difference that it is necessary at runtime while TCHAR is necessary at compile time of course.
It doesn't help avoiding #ifdefs, on the contrary it requires a lot more #ifdefs, and makes the code a lot more fragile. It's a nasty hack that should be left to die a (hopefully painful) death.
In my opinion it's not ugly as it avoids you to write #ifdefs, as long as you use the Win32 API and _tcs* functions of course. Unfortunately Posix AFAIK defines only ANSI functions (more precisely functions taking (const) char*), in which case you obviously have to convert your unicode string back to ANSI. MFC and ATL define set of conversion macros to overcome this problem:
LPCTSTR pszStringArg = ...; int some_posix_function(const char *string);
Instead of #ifdef UNICODE if (some_posix_function(convert_wchar_to_char(pszStringArg)) < 0) #else if (some_posix_function(pszStringArg) < 0) #endif
you can write if (some_posix_function(T2CA(pszStringArg)) < 0)
The T2CA(x) macro just converts a LPCTSTR to a LPCSTR which means that in ANSI mode it does nothing and in Unicode mode it calls WideCharToMultiByte() via a helper function.
OK, the definition of such a macro is of course a bit ugly. However as with tchar.h you can define them in a public header file and on the other hand write straight forward application code as you no longer have to use #ifdefs. In my opinion these macros complete the TCHAR pattern since #ifdefs in application code are no longer necessary and that's what that pattern is for.
Of course for new apps a better alternative might be to make them support Unicode only and use unicows if Win9x has to be still targetted. But that's another thing...
Regards Ralf
-
Alexandre Julliard -
Martin Fuchs -
Ralf Reiterer