Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (04/30/90)
Hello:
Is there a way to detect if ANSI.SYS is installed.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgGeorge.Emery@p42.f369.n105.z1.fidonet.org (George Emery) (05/02/90)
> Is there a way to detect if ANSI.SYS is installed.
How about reading the CONFIG.SYS file? Not good for floppy systems, but
the alternative that I know of puts garbage on the screen if ANSI.SYS isn't
installed.
--
uucp: uunet!m2xenix!puddle!369.42!George.Emery
Internet: George.Emery@p42.f369.n105.z1.fidonet.orgGeorge.Emery@p42.f369.n105.z1.fidonet.org (George Emery) (05/22/90)
> 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
Jon.Guthrie@p2.f70.n226.z1.fidonet.org (Jon Guthrie) (05/23/90)
> The only reliable way is to print an ansi command to the screen and > observe its affect, eg. send a cursor-move command and see where the > cursor ends up. If you don't want the text to be visible, fiddle > with the screen colors first. Well, there IS a better way than fiddling with the colors. Trap the int 11h interrupts and do send ANSI a cursor position report. If your ISR is not executed, ANSI.SYS (or one of the mutants) is loaded. After you're done with the test, remove your int 11 ISR. ...You trust them with your fortunes, you let them guard your lives -- uucp: uunet!m2xenix!puddle!226!70.2!Jon.Guthrie Internet: Jon.Guthrie@p2.f70.n226.z1.fidonet.org
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (05/23/90)
Hello Ola:
Thanks.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgOla.Garstad@f15.n502.z2.fidonet.org (Ola Garstad) (05/28/90)
KB> ANSI.SYS is installed in the device driver chain. No. Not if the user is using ANSI.COM. E.g. when running under DesqView. -- uucp: uunet!m2xenix!puddle!2!502!15!Ola.Garstad Internet: Ola.Garstad@f15.n502.z2.fidonet.org
kherron@ms.uky.edu (Kenneth Herron) (05/31/90)
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
Jon.Guthrie@p2.f70.n226.z1.fidonet.org (Jon Guthrie) (06/02/90)
> 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 don't seem to understand. Even a strangely named ANSI driver (you could call it ZZZZZZZZ.ZZZ, and it would still load properly) DOES resemble the original. At least it does in every important way. What is really important is independent of the name with which the driver is loaded. In any case, you would also have to worry about what happens if the ANSI driver was actually a TSR (like ANSI.COM) which would be put in AUTOEXEC.BAT rather than CONFIG.SYS. I am convinced that the best way of checking for ANSI is Bob Stout's method: Take over the BIOS video interrupt. Send a "report cursor position" command to the screen. If the interrupt is tripped, then "ANSI.SYS" is not installed. Return the interrupt to it's regularly scheduled vector. Simple, huh? And no garbage, either. ...You trust them with your fortunes, let them guard your lives -- uucp: uunet!m2xenix!puddle!226!70.2!Jon.Guthrie Internet: Jon.Guthrie@p2.f70.n226.z1.fidonet.org
Jon.Guthrie@p2.f70.n226.z1.fidonet.org (Jon Guthrie) (06/10/90)
>>> 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? >> Your suggestion would break: >> 4) Where the user has renamed his ?ansi.sys file for whatever reason > Not true. The name of the device driver is not necessarily the same as > the name in the header of the code, which is what one would be looking for. Well, that's true, but the name in the header of the ANSI.SYS code is "CON:" because it's the console driver. The question then becomes, how do you tell an ANSI-compatable CON driver from a non-ANSI CON driver. (Well, I'll admit that non-ANSI con drivers aren't that common, but they ARE possible.) ...You trust them with your fortunes, let them guard your lives -- uucp: uunet!m2xenix!puddle!226!70.2!Jon.Guthrie Internet: Jon.Guthrie@p2.f70.n226.z1.fidonet.org