Make MSFT code TCHAR-based

[HexadigmSystems]

Me again :)

As mentioned in the first issue, here's another but it's just nice-to-have only (at your discretion though not affecting me personally but it would most others - I already have my own equivalent "type_name" that handles it).

Took a look at your MSFT code. Not sure if you're aware or not (if you don't work on MSFT platforms) but the entire Windows API is based on UTF-16. Almost all code programmers write these days therefore (usually) uses "wchar_t", not "char". Windows itself even converts "char" to "wchar_t" if you call almost any function in the Windows API with a "char" based string (longer story). Your code as it now stands is therefore harder (inconvenient) to use because your "char" based string (view) usually needs to be converted to "wchar_t" in most real-world code. Would therefore be better to just return it that way in the first place.

Upshot is (you can research the details if req'd), your MSFT code would be better off IMHO if you either added an extra template (typename) parameter called "TChar" (or "CharT", whatever), and make it default to TCHAR (and change your "string_view" to rely on it, i.e., "basic_string_view but read on), or alternatively do the following. You'll have to do some of the following anyway even if you go the latter route (and the latter route is arguably preferable but I and many others still do the following for historical reasons - still clean and perfectly sound though);

1. #include <tchar.h> (native Windows header) to pick up #defined constant "TCHAR" and macro "_T" described below
2. Replace "std::string_view" with "std::basic_string_view" or you can also simplify things by creating an alias for "std::basic_string_view" called "tstring_view" (same results in the end though of course). TCHAR resolves to "wchar_t" or "char" based on whether developers #define UNICODE and _UNICODE or not in their compiler settings (and these days they almost universally do).
3. Refer to FUNCSIG in your code as _T(FUNCSIG). The "_T" (ugly as it is) simply adds the "L" prefix to the FUNCSIG string literal when UNICODE and _UNICODE are #defined (and FUNCSIG is a string literal in MSFT's docs so it's safe). It adds nothing otherwise. FUNCSIG therefore becomes "wchar_t" based when targeting Unicode builds (again, normally the case) or remains "char" based otherwise.

Now the code can be easily compiled for either UTF-16 (wchar_t) or ANSI (char) based on whether the preprocessor constants UNICODE and _UNICODE and #defined or not (and they almost always are these days as mentioned so UTF-16 (wchar_t) will kick in).

[HexadigmSystems]

Leading/trailing underscores in FUNCSIG obviously went missing in my last post (removed by GitHub and FUNCSIG also bolded - - likely Markdown bugs in the editor)

[HexadigmSystems]

Uggh, just noticed another markdown bug as well ("std::basic_string_view" was specialized on TCHAR at one point but Github choking on it)