What is Unicode and ANSI names in the attached screenshot.Image It is mentioned at the end of the page in this link MSDN Page
1 Answers
Old windows (pre-NT) used ANSI codepages (1 byte per character, different in every region of the world). From NT onward Unicode was introduced. Pre-NT all the API where ANSI (so for example LoadLibraryA(LPCSTR)
accepted an ANSI name for the name of the library. From NT onward a new version of all the API where introduced, using Unicode (LoadLibraryW(LPCWSTR)
). So in Windows >= NT there are two API for loading libraries, ANSI and Unicode.
Then there is a third version, LoadLibrary
, that is only a #define
. The value of this #define (that can be LoadLibraryA
or LoadLibraryW
, depends if the #define UNICODE
is set or not) (the same for ShellExecute
that can be ShellExecuteA
or ShellExecuteW
). So in your source code you can use directly the LoadLibraryA
, the LoadLibraryW
and a third version, LoadLibrary
, that depending on a preprocessor macro will use one of the other two. If you want to use the "agnostic" LoadLibrary
versions of the API you should use TCHAR
, LPTSTR
, LPCTSTR
, _T("foo")
that, through the preprocessor, will be changed to char
, char*
, const char*
, "foo"
or to wchar_t
, wchar_t*
, const wchar_t*
, L"foo"
.
But note that in 2017 (and in general from when Windows ME was dead) it is wrong to use ANSI api. You should always target UNICODE (or target the agnostic version and #define UNICODE
)

- 109,618
- 12
- 197
- 280
-
The main reason why using ANSI API is wrong is because ANSI is not a real codepage, but whatever 8-bit encoding happens to be used in the localized version of Windows. So if you write a nice ANSI program using Greek Windows (and greek letters) it will *silently* garble all your Greek texts in non-greek versions of Windows! – rodrigo Mar 28 '17 at 06:33
-
@rodrigo I consider much more important the fact that with ANSI methods you can't even see the whole file-system in a correct way. – xanatos Mar 28 '17 at 06:34