🚀 go-pugleaf

In episode <6357.26602423@puddle.fidonet.org>, 
we heard George.Emery@p42.f369.n105.z1.fidonet.org (George Emery) say:
|
|Well, we know the names for the ANSI emulators which are likely to show up 
|in CONFIG.SYS, so why can't they all be checked?  If ANSI is installed but
|called something really abnormal, then why bother trying to find it?  What's
|the point of using a standard if one departs from it so far that it doesn't
|resemble the original?

(You _wanted_ flames, right?}

The idea, I would think, is to give the user a useful program, not to
berate him for daring to be different.  Your suggestion would break:

1) Where the user is running on a terminal or otherwise has ansi emul
   in rom,
2) Where the user has an ansi emulator which the programmer didn't know
   about, or that wasn't out when the programmer wrote the program,
3) Where the user is using the PC Magazine ANSI.COM TSR emulator,
4) Where the user has renamed his ?ansi.sys file for whatever reason

While number 1 is pretty unlikely, ALL of these are needless restrictions
on the user, given that the programmer is using ansi instead of bios
or direct memory writes anyway.

|the program should give a choice
|of switching to ASCII characters/BIOS calls or allowing the user to proceed
|at her own risk if it can't find the console device it was looking for -- 
|There's no need to abort the whole program.

If you're going to put bios calls into the program there's little reason
to use ansi in the first place (remember, I admitted #1 up there was 
unlikely).  

I still say the most reasonable solution is:  If you want to know if
ansi codes are going to work, test an ansi code.  Print one to the
screen and test whether it worked or not.  If you want to keep the
screen clean, set the colors to black on black first.

(This has nothing to do with Modula-2.  Followups directed to comp.sys.
ibm.pc)

Kenneth Herron