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