Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!sunic!dkuug!freja.diku.dk!ketil From: ketil@diku.dk (Ketil Perstrup) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: Checking for ANSI.SYS... Message-ID: <1990Mar13.131548.24638@diku.dk> Date: 13 Mar 90 13:15:48 GMT References: <1547@krafla.rhi.hi.is> Organization: Department Of Computer Science, University Of Copenhagen Lines: 41 frisk@rhi.hi.is (Fridrik Skulason) writes: >> A couple of days ago, I posted requests for methods to check for >>ANSI.SYS. I have received many useful tips on how to send ANSI control >>sequences to check to see if ANSI.SYS or a variant was installed. >: >>However, if at all possible, I would >>prefer checking low memory so that there is no screen color. > Step 1: Get the address of the first installed device driver > INT 21, function 52H. ES:[BX+22H] (in DOS 3.x) is the > start of the NUL driver, which is always first. > Step 2: Get the pointer to the next driver. If it is one of the > original drivers (located at 70:x) quit - no ANSI found > Step 3: Check the name of the driver - if it is "CON" then you have > found ANSI.SYS or another replacement "CON" driver. If not > just go to step 2 :-) Actually, this isn't enough: The CON-driver you find might as well be DISPLAY.SYS! (in DOS 3.30 and up) The correct procedure is to search through the device drivers and examine every driver which has the name CON. The device information bits of the driver will be 8013h for ANSI.SYS (and the build-in driver). DISPLAY.SYS has bit 6 and bit 14 set, too. These methods for determining ANSI.SYS might not always work: Some clones has ANSI.SYS build into the standard CON driver. This might cause the algorithm to report no ANSI.SYS present even though you *can* use ANSI-sequences. (I don't know this for certain, though). Beware: If you search through the device list, you might have trouble finding when you have reached the end. The documentation I have implies that the last driver in the list has both the segment and offset part of the pointer to the next driver set to 0ffffh. This is not true: PC-DOS 3.30 sets only the offset (and not the segment) to 0ffffh. Ketil Perstrup (ketil@diku.dk)