🚀 go-pugleaf

In article <AUSTIN.90Feb26194024@bucsf.bu.edu>, austin@bucsf.bu.edu (Austin H. Ziegler, III) writes:
> 	Does anyone know a way to quickly check low memory to see if
> ANSI.SYS or a variant is loaded?  (As usual, C or Pascal of any flavor
> preferred, but BASIC will do...)

Take a look at the March 13, 1990 of PC Magazine, page 376, User-to-User
column for a discussion on this topic.  There is full source to a MASM
program to test for presence of ANSI.SYS as well as a DEBUG script version.

George B. Smith
Stratus Computer, Inc
gbs@swdc.stratus.com
{amdahl,oliveb,uunet}!stratus!gbs

In article <AUSTIN.90Feb26194024@bucsf.bu.edu> austin@bucsf.bu.edu (Austin H. Ziegler, III) 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 :-)



-- 
Fridrik Skulason   University of Iceland     |     
Technical Editor Virus Bulletin (UK).        |
E-Mail: frisk@rhi.hi.is   Fax: 354-1-28801   |   

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)