Michael Feldman wrote:
> <shrug> I've had _some_ book users tell me they found an ANSI.SYS
> in their NT installation. Go figure. Microsoft, blah-blah.
I just checked my C:\WinnNT\System32 directory, and it is in there,
with the same date-time stamp as most of the rest of WinNT. If you run
Command.Com as the shell, the old DOS command processor -- not WinNT's
CMD.EXE, isn't it possible to get Ansi.Sys to work correctly
with 16-bit code? Maybe that is why it is there.
Back when I used software that relied on Ansi.Sys, I thought it was a
particularly bad idea. Besides being slow, it was way to easy to
attempt, for example, to display the contents of a file that contained
an escape character. That would usually lead to severe user
disorientation and scrambling of the screen. If the bad data set the
blink attribute, it was horrendous.
I suppose that when you use Ansi.Sys in teaching, your approach would
be to show how to encapsulate the output functions in a package that
always knew whether it was sending data or escape sequences,
and that the module would be sure to filter the data to preclude the
mistake of trying to display any escape characters.
IOW, I like strong typing, and comingling data and control information
in the same stream is excusable only because the Ansi.Sys API requires
it, but the rest of the program shouldn't know about that.