>> I am using Borland C++ and programming under DOS.
>
> Why?
>

I have Borland C++ and wish to write a program in DOS. Are you suggesting
this isn't ideal?

>> cout << char(7);
>>
>> Obviously this is assigned to the BELL signal and therefore sounds the
>> beep
>> and doesn't display the bullet point I require.
>
> The ASCII standard does not define a "bullet point" character, so you
> are out of luck.
>
> Unicode would support it, but DOS doesn't support unicode.

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?

It seems a possible solution to this problem may be to 'turn off'
interpretation of the characters that are output. I believe this may be
possible by changing the output stream to binary mode, but I'm not sure how
to do this. Any further ideas appreciated.

Andy

Andy Leese wrote:
>>> I am using Borland C++ and programming under DOS.
>
>>> cout << char(7);
>>>
>>> Obviously this is assigned to the BELL signal and therefore sounds the
>>> beep
>>> and doesn't display the bullet point I require.
>> The ASCII standard does not define a "bullet point" character, so you
>> are out of luck.
>>
>> Unicode would support it, but DOS doesn't support unicode.
>
> 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?
>
> It seems a possible solution to this problem may be to 'turn off'
> interpretation of the characters that are output. I believe this may be
> possible by changing the output stream to binary mode, but I'm not sure how
> to do this. Any further ideas appreciated.
>

At this point, you are out of the realm of the C++ language, and into
compiler and OS specifics. May I suggest you ask further in a newsgroup
with either "borland" or "msdos" in its name?

See FAQ 5.9
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9 for some
suggested groups.

Andy Leese wrote:
>>> I am using Borland C++ and programming under DOS.
>> Why?
>>
>
> I have Borland C++ and wish to write a program in DOS. Are you suggesting
> this isn't ideal?

I was subtly suggesting that in the long run it might be a better idea
to use a non-obsolete OS to make such programs, especially if you are
dealing with things like character sets (which DOS as horrible and
completely outdated support for). But whatever floats your boat.

On Mon, 15 Oct 2007 20:05:03 +0100, Andy Leese wrote:
> 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/

--
Joel Yliluoma - http://bisqwit.iki.fi/
: comprehension = 1 / (2 ^ precision)