I think that's the other way around. _UNICODE is meant to be used with tchar.h. I found 41 instances in a recent SDK. UNICODE is the more generic term to chose between ANSI or WIDE API calls (if you don't force them directly). I found 4123 instances in the same SDK.
So IMO the proper way is to use UNICODE, especially if you never use tchar.h. > On May 30, 2020 12:57 PM Jeffrey Walton <noloa...@gmail.com> wrote: > > > On Sat, May 30, 2020 at 5:16 AM Bruno Haible <br...@clisp.org> wrote: > > > > I wrote: > > > some types depend on > > > whether UNICODE is defined or not [1]. > > > > Some functions also depend whether UNICODE is defined or not. > > > > Since UWP applications are meant to defined the macro UNICODE, but we want > > Gnulib to produce the same code, regardless whether UNICODE is defined or > > not, > > we need to either explicitly use the functions with 'A' suffix (which is > > ugly) > > or use #defines for redirection. > > > > Fortunately, packages that use gnulib don't need to do this stuff; nor do we > > need to do it in the tests/ directory. Only the gnulib/lib/ directory may > > reasonably be used with -DUNICODE, therefore only the gnulib/lib/ directory > > needs this workaround. > > In case it matters, I believe Microsoft keys on _UNICODE, not UNICODE. > > Microsoft source files often have something like this (or is it vice-versa): > > #ifdef UNICODE > # ifndef _UNICODE > # define _UNICODE > # endif > #endif > > Also see > https://docs.microsoft.com/en-us/cpp/text/generic-text-mappings-in-tchar-h. > > Jeff
