🚀 go-pugleaf

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)