AnsweredAssumed Answered

vrf Print File

Question asked by VRFuser on Aug 12, 2003
> Okay, it works as advertised!

Cool! I'm Glad it's working with a minimum of fuss

> Silly question: Why do all the dll function calls end with A?
> (shell32.ShellExecuteA, winmm.PlaySoundA)

Not silly at all, and answer made public because it contains information
everybody who calls any Windows API may be interested in.

It has to do with globalization, language and strings. Most programmers are
aware that the original ASCII character set contained 127 separate codes.
The first 31 are  control characters that have special meaning to devices,
such as DC1 to DC4, Shift in, Shift out, and so on. The most well known of
these are CR (13) and LF (10). The next 31 are the space char, shifted
numbers, numbers, colon, semi-colon, angle brackets, question mark and
equal. Then @, upper case letters, square brackets, slash, caret and
underscore. Then the gravure, lower case letters, curly braces, pipe, tilde
and one special char. This is great if your language happens to be based on
Latin and you can use the character images as they are.

The IBM character set extended this to 256 and used graphic symbols for the
next 127 chars. Modern fonts have some special symbols and common letters
from different languages in these extended chars. But that's still not good
enough for other languages like Slovak (sp?) or even Norse derivatives.
UNICODE was designed to have enough characters to support all languages.
Instead of using one byte to represent a character, UINCODE uses two bytes
per character. And this is where the A and W come in.

A character in a UNICODE character set is 2 bytes wide and is often called a
wide character (or WCHAR). Each and every Windows NT function that takes or
returns a string actually has two different implementations: one for ASCII
strings, and one for UNICODE or Wide strings. The DOS based versions of
Windows don't support UNICODE, though the W function stubs are in the
libraries (dlls) so a UNICODE program won't actually crash, it will just
never get an W function to work.

So basically that's how you can tell what the function will be called when
you've finally found the function you need in the Windows SDK documentation.
VEE is not a UNICODE application, so it always calls A version functions. If
the function takes or returns a string, there will always be an A appended
to the name.

This isn't to say that you can't call the W versions, it's just that if you
call a W version and expect VEE to know what to do with the string it
returns you'll be disappointed. Network functions for instance are almost
all W only, so if you want to pass a string to one of these functions you
have to convert it to a W string first. This is what the function
MultiByteToWideChar is all about. The reverse operation (converting a W
string to an A string) is done by WideCharToMultiByte. Another place where
you run into this is COM. An OLECHAR is a W char.

One of these days I'll finish the COM series and you'll see this in action.
When you instance an Automation library or ActiveX control in VEE, VEE finds
the appropriate GUID in the registry and retrieves it in A character string
format. But to actually create and use an instance of a library or control
interface, it needs to convert the GUID to a W string first, then to the
byte or raw GUID format, and THEN it's ready to create the instance and get
the interface pointer.

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".