Closed mloskot closed 4 years ago
The b2 driver code implicitly assumes use of ANSI version of Win32 API functions, e.g.
b2
char buf[ 1024 ]; DWORD const ret = GetModuleFileName( NULL, buf, sizeof( buf ) );
Obviously, attempts to compile with cl /DUNICODE will fail due to char* to wchar_t* conversions as GetModuleFileName resolves to GetModuleFileNameW.
cl /DUNICODE
char*
wchar_t*
GetModuleFileName
GetModuleFileNameW
There either should be an early exit somewhere
#if defined(UNICODE) || defined(_UNICODE) #error "Building with C run-time support for Unicode is not supported" #endif
or ANSI variants of Win32 API functions should be preferred, change from GetModuleFileName to GetModuleFileNameA, etc.
GetModuleFileNameA
I like being explicit, and hence we should use the ANSI variants. At least until some future when we can make b2 support unicode.
The
b2
driver code implicitly assumes use of ANSI version of Win32 API functions, e.g.Obviously, attempts to compile with
cl /DUNICODE
will fail due tochar*
towchar_t*
conversions asGetModuleFileName
resolves toGetModuleFileNameW
.There either should be an early exit somewhere
or ANSI variants of Win32 API functions should be preferred, change from
GetModuleFileName
toGetModuleFileNameA
, etc.