The question of whether Visual Basic is ANSI or Unicode is a trick question. The only answer someone could ever possibly give is yes and no, or more accurately, the answer depends on the meaning of the question. Perhaps delving a little more deeply into the history would help give the question enough meaning that the answer of “It depends” will at least feel a little less unsatisfying.
ANSI = ~Unicode = MBCS
One important definition has already been discussed: when I refer to Unicode here I am using the Microsoft notion of UCS-2/UTF-16. Another that I have not discussed is that of the non-Unicode strings. Although these are usually referred to as multibyte (which will cover all the other codepages, including the DBCS codepages that will use two bytes and UTF-8 that will use 1-5 bytes, and so on), many people also refer to them as being “ANSI.” This is largely for historical reasons, but there is a modern basis for this misused term: All the multibyte Windows APIs have an “A” suffix on them, the “A” standing for ANSI. An example would be the FindWindow API, which takes strings for a window class, a window caption, or both. The FindWindowA API exists on all Win32 operating systems and accepts strings that can be represented by the default system codepage. The FindWindowW API exists only on Windows NT and Windows 2000 and accepts Unicode strings.
My personal preference would have been to call the “A” APIs the ~Unicode APIs (meaning the “not Unicode” APIs), but the tilde character is not one that would be valid in identifiers. This would be confusing, to say the least!
The issue of using and calling Unicode versus non-Unicode APIs is one that I will be discussing a little later in this chapter and extensively in Chapters 7, “Understanding the Codepage Barrier,” and 8, “Handling VB Forms and Formats.”