JudyL_MD is correct but there are a few more details involved. Nearly all of the Windows API comes in MBCS and Unicode flavors. The function
LoadLibrary
is one example. That function actually does not exist. There is
LoadLibraryA
and
LoadLibraryW
for MBCS and Wide character sets. If you do not define UNICODE or _UNICODE then the MBCS API will be used and that defines
LoadLibrary
to be
LoadLibaryA
. Regardless of which variant of the API your app uses by default, you can also be explicit with your usage. For example, you could write
auto hmodule = LoadLibraryW( L"Microsoft.ui.xaml.dll" );
and that will work regardless of whether UNICODE is defined or not. Similarly, you can write
auto hmodule = LoadLibraryA( "Microsoft.ui.xaml.dll" );
and it will also work. As previously mentioned, you can also write
auto hmodule = LoadLibrary( _T( "Microsoft.ui.xaml.dll" ) );
and it will compile both with and without UNICODE being defined.
A brief anecdote: I recently wrote a chess game display program (for .PGN files) and all drawing was done in text mode in a dialog. There are chess pieces in several standard fonts so I used those. The thing is, those are characters in the 0x2600 range. To handle that, I defined the pieces as wide characters and then converted them into MBCS character strings (with
WideCharToMultiByte
) and then displayed them with standard Windows calls in my MBCS application. Incidentally, to make that work one must utilize a manifest file and specify UTF-8 as the active code page. Standard text calls like
SetWindowText
can then display UTF-8 strings in various languages.