Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!nosun!qiclab!m2xenix!puddle!p42.f369.n105.z1.fidonet.org!George.Emery
From: George.Emery@p42.f369.n105.z1.fidonet.org (George Emery)
Newsgroups: comp.lang.modula2
Subject: Re: ANSI.SYS Install Detection
Message-ID: <6357.26602423@puddle.fidonet.org>
Date: 22 May 90 03:33:04 GMT
Sender: ufgate@puddle.fidonet.org (newsout1.26)
Organization: FidoNet node 1:105/369.42 - TECHbooks One, Beaverton OR
Lines: 25


 > Scanning through the assumed config.sys file is only useful ifyou know 
 > what the ANSI driver is actually called.  Just by looking for ANSI.SYS 
 > in a device definition will only tell you if the MS-DOS supplied one is 
 > present.  

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?

 > I assumed that you needed a portable method to detect this, 
 > and having a few characters of garbage on the screen when the program 
 > is about to report abject failure is acceptable to most users.

Oh, come now!  That's lazy programming... 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.


--  
uucp: uunet!m2xenix!puddle!369.42!George.Emery
Internet: George.Emery@p42.f369.n105.z1.fidonet.org