What I don't understand is I have a program written in Pascal (running in
pure DOS or DOS Console) that displays these characters perfectly. I also
find that using my Hex Editor (in pure DOS and a DOS Console in Windows)
that I can enter the hex value and the bullet character (and all the others)
displays fine. So surely DOS can display these characters?
As others have pointed out, your question is off-the-topic in this
newsgroup.
However, I can imagine it being difficult getting a definite answer
to your question, so I'll explain it for you.
In Borland Pascal, if you use the CRT unit, it will use a "direct video"
feature which means that when you print characters, it will poke the
character values corresponding to those characters directly into the
video memory. In the PC hardware, the video memory is not a teletype
device, so it actually defines graphical glyphs for each 256 different
bytes that can be poked into the text mode video memory.
That set of glyphs is defined by the computer manufacturer or the
operating system provider; in most cases on the IBM PC, it was
the Extended ASCII set, also called CP437. [1]
By poking the video memory, you can even display the glyph #13, which
normally is interpreted as carriage return, and the glyph #10, which
normally is interpreted as a newline.
However, in actual ASCII [2], the first 32 bytes of the character set
are reserved for control codes. In the Extended ASCII set that
region contains symbols only because of the reason explained above.
The C++ language is not designed for PC hardware in particular, or
any hardware in particular at all. Most commonly though, when you
output to stdout or std::cout in C++, it will write into what is
being simulated as a teletype device, where those control codes
in 0..31 range actually are handled as control codes.
However, std::cout may also correspond to a file, or to another
program's input, or something else. It depends on the operating
system.
There is no "C++" way to do anything device or hardware specific.
Outputting control codes by poking them directly into the video memory
would really be a hardware and environment specific thing; Borland C++
for MS-DOS may provide such a feature, but I wouldn't count on it.
Still, the question remains, why do you use such an obsolete compiler
environment?
If you actually _need_ to be writing to a DOS environment (for example,
some legacy machine that is operated in a booth somewhere), then by
all means you can study the hardware features and utilize them, but
keep in mind that they are compiler specific, and hardware specific;
such tricks do not work on different compilers (generally speaking),
and not in different environments. For example, if your program pokes
into the video memory, and later, you decide to compile it as a WIN32
application (even if a console program), it will not work.
Any assumptions you make on the running environment will hinder your
chances of porting the application to a different environment.
Sticking with the C++ standard (knowing what it guarantees and what
it does not guarantee (i.e. what it makes no mention of)) is the best
way to ensure your program works on whatever platform it is compiled on.
Last, I would have quoted a relevant section in the newsgroup's FAQ [3],
but I couldn't find anything particularly fitting here.
[1]:
http://en.wikipedia.org/wiki/CP437
[2]:
http://en.wikipedia.org/wiki/ASCII
[3]:
http://www.parashift.com/c++-faq-lite/