Why do win32 have different TEXT macros for the same thing?

Question

I want to know why macros like T, TEXT, _TEXT, __TEXT or __T exist when they all end up doing the same thing.

i.e.

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

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

#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 this. Thanks.

Answer 1

As is often the case with “mysterious” things, Raymond Chen gives some information (emphasized by me):

So what is the same thing to say with all these different ways? Actually there is a method of madness.

Simple versions without underlining affect the character set. Windows header files are by default . Therefore, if you define UNICODE, then GetWindowText will appear in GetWindowTextW instead of GetWindowTextA, for example. Similarly, the TEXT macro will be displayed in L "..." instead of "...".

Underlined versions affect the character set. C runtime header files are processed by default . Therefore, if you define _UNICODE, then _tcslen will display, for example, wcslen instead of strlen. Similarly, the _TEXT macro will be displayed in L "..." instead of "...". What about _T? Okay, I don’t know about that. Maybe it was just saving someone typing.

Answer 2

For many macros, there is one Win32 and one for the C runtime library. This explains TEXT (Win32) and _TEXT (C runtime library). Double-underlined options are probably helper macros that are not intended for general use. T is probably a convenience for those who think the TEXT is too long.

Answer 3

The UNICODE character affects declarations in the Windows API headers (mainly <windows.h> ), and the _UNICODE and _MBCS affect declarations in the C library.

Example Windows API: with UNICODE defined by MessageBox cards, in Windows terminology the Unicode version, and with UNICODE undefined MessageBox displayed in MessageBoxA , ANSI version.

The C library example is more involved.

Despite the two characters _UNICODE and _MBCS , only three cases stand out:

• None of these are defined and, for example, _tcslen displayed in strlen , a narrow character version.

• _MBCS and _UNICODE not defined; _tcsclen displayed in _mbslen , a multibyte version of the character.

• _UNICODE and _MBCS not defined, and for example, _tcslen displayed in wcslen , a wide-character version.

It is worth noting that all this was in support of Windows 9x, which did not have a widescreen API.

However, in 2001, Microsoft introduced Layer for Unicode , which essentially provided a broad-class API for Windows 9x. And at the same time, the whole scheme above was outdated, with the exception of one case: the use of MFC as a DLL in Windows 9x and the inability or inability to rebuild it. Well, besides the fact that the one who supports the creation of Visual Studio code, from 11 years ago, did not understand this fact ten years ago, and that this, in turn, misleads the hordes of newcomers who, while professionals are seriously unwilling to stop using this is a waste of time.

Cheers and hth.,

Answer 4

Ensure (backward) compatibility and interoperability with code written for other platforms