Andriy Palamarchuk apa3a@yahoo.com writes:
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
But none of them needs Unicode at all, you would test exactly the same thing by doing an ASCII only version (ok except maybe the empty string stuff). And how do you test for instance SystemParametersInfoA sending a message to a Unicode window proc? You can't do that with TCHAR.
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).
That's not multi-byte charset support. Multibyte is where you can have two ASCII bytes represent one character in MBCS codepages. This is another example where ASCII and Unicode behave differently; so if you put a multi-byte char in one of the _T("") strings the test will break for any API that returns a character count.
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.
Yes of course there are a few advantages. There are also large inconvenients, which more than offset the small gain IMHO. If your tests for A and W are identical it's not big deal to write both; and if they are different at least you can write them without having to resort to ugly #ifdefs and other hacks.