WinCon: define all of PDC_WIDE, UNICODE, _UNICODE if one of those are defined

[GitMensch]

Per MSDN one should always define both macros, as they are used in different contexts, but must match. The definition of UNICODE can also be provided by the build environment, especially with MSVC, in which case PDC_WIDE must be defined as well.

In general - shouldn't we move that to another (common internal) header, wrapping it in #ifdef _WIN32?

Apart from wincon we have that also in wingui, vt and (not sure it is needed/useful there) fb:

PDCursesMod/wingui/pdcwin.h

Lines 13 to 20 in d2f479a

	#ifdef PDC_WIDE
	#if !defined( UNICODE)
	# define UNICODE
	#endif
	#if !defined( _UNICODE)
	# define _UNICODE
	#endif
	#endif

PDCursesMod/vt/pdcvt.h

Lines 9 to 16 in d2f479a

	#ifdef PDC_WIDE
	#if !defined( UNICODE)
	# define UNICODE
	#endif
	#if !defined( _UNICODE)
	# define _UNICODE
	#endif
	#endif

PDCursesMod/fb/pdcfb.h

Lines 1 to 8 in d2f479a

	#ifdef PDC_WIDE
	#if !defined( UNICODE)
	# define UNICODE
	#endif
	#if !defined( _UNICODE)
	# define _UNICODE
	#endif
	#endif

[Bill-Gray]

Agreed, it'd make sense for this to be handled consistently, probably within curspriv.h.

The use of both UNICODE and _UNICODE has always been a little mysterious to me, but based on this 20-year-old blog post, I think you're right in thinking that if one is defined, the other one ought to be as well.

One problem I do see is that you've got PDC_WIDE being defined if either UNICODE or _UNICODE is defined. It's entirely possible for people to use the eight-bit, non-wide version of PDCurses* even if Unicode is in use elsewhere.

We also don't have any tests for what happens in non-Unicode PDC_WIDE situations. I am not entirely clear on how that's supposed to work, really... I'm only working with 8-bit characters or with Unicode. We really ought to have a test program that exercises that configuration. (Either that, or drop non-Unicode wide support. I'd be a little surprised if it worked in either PDCurses or PDCursesMod at this point. For Microsoft, one is supposed to #define _MBCS for a non-Unicode wide-character program, and neither PDCurses or PDCursesMod does so.)

[GitMensch]

One problem I do see is that you've got PDC_WIDE being defined if either UNICODE or _UNICODE is defined. It's entirely possible for people to use the eight-bit, non-wide version of PDCurses* even if Unicode is in use elsewhere.

But if we put this in curspriv, then there's no issue with that, is there?

I'd drop that (and similar) code from all ports, then add to curspriv within _WIN32, then force-push that change to this PR.
Do you agree on that plan?

[GitMensch]

friendly ping (as outlined above likely should be done different)