TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Al Christians <[log in to unmask]>
Reply To:
Al Christians <[log in to unmask]>
Date:
Tue, 1 Dec 1998 20:09:39 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
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.

Al

ATOM RSS1 RSS2