Why are there different TEXT like macros for the same thing in win32?

Question

I want to know the reason why there are macros such as T, TEXT, _TEXT, __TEXT or __T when they all ultimately do the same thing.

i.e.

mapping "string" to L"string" if UNICODE is defined.

Thanks for the answers. On a more practical approach, can somebody explain me the behavior of the code given below?

#include <stdio.h>
#include <conio.h>
#include <tchar.h>   // For _T and _TEXT
#include <windows.h> // For __TEXT 

int __cdecl main ()

{

  printf ("%s", _TEXT(__FILE__ ));  // Works fine

  printf ("%s", _T(__FILE__));      // Works fine

  printf ("%s", __TEXT(__FILE__ )); // error C2065: 'L__FILE__': undeclared identifier

  _getwch();

}

Update: I think my code has something to do with C preprocessor tokenization. I am posting a separate question for that. Thanks.

Answer 1

As it is often the case with "arcane" things, Raymond Chen gives some information (emphasis added):

So what's with all these different ways of saying the same thing? There's actually a method behind the madness.

The plain versions without the underscore affect the character set the Windows header files treat as default. So if you define UNICODE, then GetWindowText will map to GetWindowTextW instead of GetWindowTextA, for example. Similarly, the TEXT macro will map to L"..." instead of "...".

The versions with the underscore affect the character set the C runtime header files treat as default. So if you define _UNICODE, then _tcslen will map to wcslen instead of strlen, for example. Similarly, the _TEXT macro will map to L"..." instead of "...". What about _T? Okay, I don't know about that one. Maybe it was just to save somebody some typing.

Answer 2

For many macros, there is the Win32 one and the one for the C run-time library. That would explain TEXT (Win32) and _TEXT (C run-time library). The double-underscore versions are probably helper macros not intended for general use. The T is probably a convenience for those who think TEXT is too long.