Alexandre, while I'm not pushing using TCHAR.h here, can't agree with some your arguments.
--- Alexandre Julliard julliard@winehq.com wrote:
Andriy Palamarchuk apa3a@yahoo.com writes:
Here I don't agree with you. Programming with
TCHAR is
*exactly* the same as programming with WCHAR, but
with
different names. You think once - in WCHAR terms
and
get as a bonus ANSII version!
You don't think in WCHAR terms. There isn't a single real Unicode character in your test, it's all purely ASCII.
If you look even more carefully you'll find that my test does not have a single real ASCII character :-P Indeed, I do not test text processing there at all. I use text strings there for: a) identifying registry keys b) testing system settings broadcast behaviour (comparison against empty string) c) tests description
In *my* test application W and A versions of functions have exactly the same behaviour and I'm very glad I don't need to write the same code twice.
That's the main problem with TCHAR, you have to stick to the lower common denominator, which means no Unicode chars, no multi-byte support, etc.
a) in places where you need unicode characters or Unicode-specific checks you can use them with #ifdef _UNICODE. Test strings generator even will help to eliminate some of such conditionals.
b) multibyte, not one-byte characters are the common lowest denominator. Converting the test to TCHAR.h I had to remember that I'm using multi-byte characters. E.g. in some places I needed to replace sizeof(buf) to sizeof(buf)/sizeof(_TCHAR).
In fact, code became cleaner after I removed "if (has_unicode()) " blocks, A<->W conversions,
letters
"A", "W" from API names. I feel that in this case
I
don't need to "think twice" - once in terms of
ANSII,
the second time - in terms of Unicode.
But we want people to think twice, and write a test adapted to the function they are testing; you don't test ASCII and Unicode the same way, except superficially.
It would be silly for me to separate W and A checks everywhere if they are different only in a few cases.
This TCHAR crap is just a marketing tool to let Microsoft pretend that converting to Unicode is easy; but it's not usable in real life
Nope. Purpose of TCHAR.h is support of compilation of the same code for both - Unicode and ASCII platforms. You still have to make the same decisions as with moving to pure Unicode API.
how many apps do you know that ship both an A and a
W
exe?)
I came across a few OS projects which use TCHAR: * Tcl - e.g. see http://tcl.apache.org/sources/tcl/win/tclWinFCmd.c.html * XEmacs - this article will be interesting for you: http://www.xemacs.org/Architecting-XEmacs/windows-I18N.html
You will agree with me - it is difficult to find this sort of statistics. But many application have separate binaries for Windows NT and for Windows 95. One of differences between these binaries can be usage of Unicode.
We don't use it in Wine, and we must not use it in Wine tests either.
We don't use TCHAR in Wine because it does not give us any advantages. W and A Wine functions can't exist in parallel universes, they must interact, probably factor out common behaviour.
But I can see which advantages we'll have with using TCHAR with wine tests.
Andriy Palamarchuk
__________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/