austin@bucsf.bu.edu (Austin H. Ziegler, III) (02/27/90)
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. The general method sent was: send <ESC>[2J send <ESC>[6n wait for the string <ESC>[01;01;R Now, if I set the foreground and background to the same color (probably black on black, but...) then if ANSI.SYS is not loaded, there will be no clutter on the screen. However, if at all possible, I would prefer checking low memory so that there is no screen color. Due to the type of program that I'm writing (a command-line utility), it would not be good to clutter the screen with ANSI-test sequences, nor should I clear the screen with <ESC>[2J. 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...) thanks in advance, austin -- +--------------------------+-----------------------+-----------------------+ | Austin Herbert Ziegler | austin@ bucsf.bu.edu | "The Hammer has | | 700 Commonealth Box 2094 | bucsb.bu.edu | fallen." | | Boston, MA 02215 | buengf.bu.edu | -- Dan Forrester | | (617) 375-8272 | engc8vc@buacca.bu.edu | _Lucifer's Hammer_ | +--------------------------+-----------------------+-----------------------+
gbs@stratus.stratus.COM (George B. Smith) (02/28/90)
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
frisk@rhi.hi.is (Fridrik Skulason) (02/28/90)
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 |
ketil@diku.dk (Ketil Perstrup) (03/13/90)
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)