Conflicting definitions of tchar.h/simulatenous Unicode+MBCS

Mailing list threads:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-user@logging.apache.org&msgNo=171
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-user@logging.apache.org&msgNo=188
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-user@logging.apache.org&msgNo=199
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx-user@logging.apache.org&msgNo=207

log4cxx/tchar.h provides definitions that conflict with those in
Win32's tchar.h for W2A, T2A, TCHAR, etc. Under some circumstances,
TCHAR for log4cxx/tchar.h is wchar_t and Win32's tchar.h defines is as
char.

The log4cxx/tchar.h has a limit on the size of conversion that can be
done with W2A, etc which results in message truncation.

log4cxx supports only one character type at a given instance, where an
application may have multiple DLL's some of which are Ascii dominant
and others Unicode dominant.

FileAppender has no support for encoding specification.

The XML configuration file could use characters not supported in the
current code page which are likely to cause problems in ASCII builds.

My current plan is to rework of log4cxx so that exposes char*, wchar_t*
and possibly unsigned short* (UTF-16) for the logging methods, uses
either wchar_t or unsigned short* for all internal string
representations and avoids conflicting with Win32's tchar.h.