winefile: switch to UNICODE mode

[Ralf Reiterer]

> > 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