How a bullet turns into a beep
Here's a minor mystery:
echo •
That last character is
U+2022.
Select that line with the mouse,
right-click, and select Copy to copy it to the clipboard.
Now go to a command prompt and paste it and hit Enter.
You'd expect a • to be printed, but instead you get a beep.
What happened?
Here's another clue.
Run this program.
class Mystery {
public static void Main() {
System.Console.WriteLine("\x2022");
}
}
Hm, there's that beep again.
How about this program:
#include <stdio.h>
#include <windows.h>
int __cdecl main(int argc, char **argv)
{
char ch;
if (WideCharToMultiByte(CP_OEMCP, 0, L"\x2022", 1,
&ch, 1, NULL, NULL) == 1) {
printf("%d\n", ch);
}
return 0;
}
Run this program and it prints "7".
By now you should have figured out what's going on.
In the OEM code page,
the bullet character is being converted to a beep.
But why is that?
What you're seeing is
MB_USEGLYPHCHARS in reverse.
Michael Kaplan discussed MB_USEGLYPHCHARS a while ago.
It determines whether certain characters should be treated as
control characters or as printable characters when converting to
Unicode.
For example, it controls whether
the ASCII bell character 0x07 should be converted
to the Unicode bell character U+0007 or to the Unicode bullet U+2022.
You need the MB_USEGLYPHCHARS flag to decide which way to
go when converting to Unicode, but there is no
corresponding ambiguity when converting from Unicode.
When converting
from Unicode, both U+0007 and
U+2022 map to the ASCII bell character.
"But converting a bullet to 0x07 is clearly wrong.
I mean, who expects a printable character to turn into a control character?"
Well, you're assuming that the code who does the conversion is going
to interpret it as a control character.
The code might treat it as a glyph character, like this:
// starting with the scratch program
void
PaintContent(HWND hwnd, PAINTSTRUCT *pps)
{
HFONT hfPrev = SelectFont(pps->hdc, GetStockFont(OEM_FIXED_FONT));
TextOut(pps->hdc, 0, 0, "\x07", 1);
SelectFont(pps->hdc, hfPrev);
}
Run this program and you get a happy bullet in the corner of the
window.
The TextOut function does not interpret control
characters as control characters;
it interprets them as glyphs.
The WideCharToMultiByte function doesn't know what
you're going to do with the string it produces.
It converts the character and leaves you to decide what to do next.
There doesn't appear to be a WC_DONTUSEGLYPHCHARS flag,
so you're going to get glyph characters whether you like it or not.
(Postscript: You can see this happening in reverse from the
command prompt.
Then again, since this problem is itself a reversal, I guess
you could say the behavior is happening in the forward direction now...
Type echo ^A where you actually type Ctrl+A where I
wrote ^A. The result: A smiling face,
☺
U+263A.)
