When working on Windows and other systems that predate Unicode we need to be careful when working with text other than simple ASCII (first 127 chars in most ANSI code pages and Unicode).

These systems compile `char` as an 8-bit value so compiling things like `std::string` and `char` in those environments will not produce Unicode. Code pages are used to identify characters in a language, and many are variable byte length (including UTF-8, which is not a code page).

I've used the macro-based `tchar` convention that Windows C/C++ system libraries use to conditionally compile for `char` or `wchar_t`, but in this case `char` is non-Windows Unicode **or** Windows ANSI/MBCS.

If the code was written entirely with `wchar_t` it would be straightforward but unfortunately when Unicode platforms came along `char` was pressed into service as UTF-16, making typical use of char not very portable. As it stands there is a necessary transition from `wchar_t` encoding to char because **libconfig** only compiles to `char`, so I tried to keep this transition clear. Note that this also means that our config on Windows cannot accept anything but ASCII input (UTF-8 won't help).

I've reviewed the projects for character portability issues and given that most text is ASCII lettering for things like hash encoding, it's good. However any localizable text will be a problem, including file system paths. The current code will break on systems that support non-Unicode depending on the input.