Error with STRCTYPE on windows

Hi,

I'm having an issue when compiling my code on Windows:

....C:\Users\pyknite\Desktop\test_install\SOMEFILE.cpp(287) : error C2664: 'HRESULT IsGenuineEx(STRCTYPE,PGENUINE_OPTIONS)' : cannot convert argument 1 from 'const char [32]' to 'STRCTYPE' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style castC:\Users\pyknite\Desktop\test_install\SOMEFILE.cpp(301) : error C2664: 'HRESULT CheckAndSavePKey(STRCTYPE,uint32_t)' : cannot convert argument 1 from 'const char [35]' to 'STRCTYPE' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

STRCTYPE seems to be a wchar_t *. I looked it up on the internet and they say to use the macro _T(), which I do (since some of my code come from the LimeLM example).

It also seems that I have to compile my files in UTF-16 ? Is that right ? What is the compiler flag to do that ?

Thanks

Found a workaround:

#ifdef _WIN32 wchar_t *key = L"SOME_KEY"; hr = CheckAndSavePKey(key, TA_USER);#else hr = CheckAndSavePKey(_T("SOME_KEY"), TA_USER);#endif

I did the same for TA_GUID

Cheers

>> "It also seems that I have to compile my files in UTF-16 ? Is that right ? What is the compiler flag to do that ?"

On Windows you should compile your app as Unicode. You can set it in the "General" page in the project properties. See "Character Set".

>> "STRCTYPE seems to be a wchar_t *. I looked it up on the internet and they say to use the macro _T(), which I do (since some of my code come from the LimeLM example)."

Yes, the macro _T() is the solution. See the example C app to handle constant strings in a multi-platform way.

That way you can just do this:

TCHAR key = _T("SOME KEY")hr = CheckAndSavePKey(key, TA_USER);

Wyatt wrote:> On Windows you should compile your app as Unicode. You can set it in the "General"> page in the project properties. See "Character Set".

Yes, but I'm not using Visual Studio. It is a cmake project. I wonder if there is a flag to pass to cl.exe so it will interpret everything as unicode.

Anyway, thanks for your answer 😉

Also ran into this, CMake producing a Ninja build rather than MSBuild (which seems to be what takes the typical unicode flag) with Visual Studio 2019. Ninja doesn't appear to support Unicode at the moment so this workaround would have come in handy, except in my case the key is passing through a Python binding to C++ as const char*.

So I came up with this monstrosity.

#ifdef _WIN32
#    include <windows.h>
std::wstring string_to_wstring(const std::string& str) {
    int size_needed = MultiByteToWideChar(CP_UTF8, 0, &str[0], (int)str.size(), NULL, 0);
    std::wstring wstrTo(size_needed, 0);
    MultiByteToWideChar(CP_UTF8, 0, &str[0], (int)str.size(), &wstrTo[0], size_needed);
    return wstrTo;
}
#   undef _T
#   define _T(x) string_to_wstring(x).c_str()
#else
#    define _T(x) x
typedef char TCHAR;
#endif

Lord have mercy. xD

Seems like a better solution is to only use build systems that support the platforms you're working on. No point in converting back and forth between ANSI and Unicode.

Windows has supported Unicode API for more than twenty years. This is not new functionality. Anything that claims to support Windows, and doesn't support Unicode, doesn't actually support Windows.

The build system you're using (Ninja) was created more than 13 years after Unicode was added to Windows. They claim to support Windows. They do not.

, edited
Reply
Discard post