-=> Dan Ceppa wrote to JEAN PARROT <=-

 DC> The color characters are controlled by codes that are not
 DC> directly present in the screen. As such, the cut/paste is
 DC> in black and white.

On the contrary; they are present. You're perhaps thinking of something
like ANSI, where a color-changing string is sent, then text. But the screen
itself doesn't store things that way, and most DOS programs don't even use
that kind of mechanism to write to the screen. Rather, the screen is laid
out in a grid with one byte devoted to a character, and the next (or is it
previous? I forget) byte to its attribute, which is a bitfield representing
foreground color, background color, and a "bright" or
"blinking" attribute,
depending on the screen's mode.

When you cut-and-paste, it doesn't come out "black and white", so much as
"plain text" (even though, as you point out, some of the characters are
outside the range of what we normally consider "text"). The attribute bytes
are just ignored when the characters are copied to the clipboard. It would
be possible to write the capture routine in a different way, such that it
also grabbed the attributes, perhaps converting them to ANSI codes (and in
fact, such capture programs exist, IIRC); but in the vast majority of cases
where cut-and-paste is used, only the text is wanted, and most programs you
might paste to wouldn't understand the embedded color codes anyway.

... He does the work of 3 Men...Moe, Larry & Curly
--- MultiMail/Linux v0.43