C0361@univscvm.csd.scarolina.edu ( Thomas Jenkins) (11/26/90)
According to the MSDOS Extensions guide I have, the best way to detect if the
MS Mouse driver is present is:
Set AX to zero
call INT 33h
if AX <> 0 then driver loaded BX -> number of mouse buttons
else not present.
tom
THOMAS E. JENKINS, JR. +--------+ FROM SHOE +--------+
|"IS THE COMPUTER STILL GIVING |
PROGRAMMER, | YOU TROUBLE?..." |
UNIVERSITY OF SOUTH CAROLINA |"NO, NOT ANYMORE..." |
C0361 AT UNIVSCVM.BITNET |"WHAT DID YOU DO?..." |
C0361 AT UNIVSCVM.CSD.SCAROLINA.EDU |" I TURNED IT OFF." |
+-------------------------------+dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/29/90)
In article <25098@adm.brl.mil> C0361@univscvm.csd.scarolina.edu ( Thomas Jenkins) writes: >According to the MSDOS Extensions guide I have, the best way to detect if the >MS Mouse driver is present is: > >Set AX to zero >call INT 33h >if AX <> 0 then driver loaded BX -> number of mouse buttons >else not present. I haven't seen it myself, but have been told by Kim Kokkonen of Turbopower Software that certain (old) versions of DOS don't initialize the INT 33 vector. If you call INT 33 on one of these machines, you'll crash right away. The test that Turbopower uses for the presence of an INT 33 ISR is just to look at the vector: if it's not nil, they assume it's valid. You should also be aware that the AX=0 call is destructive: if someone has a TSR mouse menu loaded, and you use this call to detect the mouse, you won't be able to restore the mouse menu when your program exits. Unfortunately, the "Save State" call (AX=16h) isn't implemented in some old versions of the Microsoft driver, and will crash them. (This also from KK; I haven't seen it. However, Turbopower's software won't try to save the state first, because it's just too unreliable.) Microsoft should be ashamed. Duncan Murdoch
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (11/30/90)
In article <1990Nov29.141927.243@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >The test that Turbopower uses for the presence of an INT 33 ISR is just to >look at the vector: if it's not nil, they assume it's valid. > The other possibility is that the INT 33 vector points to a vector in low memory that is nothing but an IRET. Just checking for a nil vector won't guarantee that a mouse driver is/is not present. Something like this will check both: const IRET = $CF; var mouse_vec : pointer absolute $0000:0033; mouse_present : boolean; mousepresent := not((longint(mouse_vec) = 0) or (word(mouse_vec^) = iret)); Bob Beauchaine bobb@vice.ICO.TEK.COM
bb16@prism.gatech.EDU (Scott Bostater) (11/30/90)
In article <6405@vice.ICO.TEK.COM> bobb@vice.ICO.TEK.COM (Bob Beauchaine) writes: >In article <1990Nov29.141927.243@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: > >>The test that Turbopower uses for the presence of an INT 33 ISR is just to >>look at the vector: if it's not nil, they assume it's valid. >> > > The other possibility is that the INT 33 vector points to a vector in > low memory that is nothing but an IRET. Just checking for a nil > vector won't guarantee that a mouse driver is/is not present. > > Something like this will check both: > > const IRET = $CF; > > var mouse_vec : pointer absolute $0000:0033; > mouse_present : boolean; > > mousepresent := not((longint(mouse_vec) = 0) or > (word(mouse_vec^) = iret)); First, the interrupt table at low memory is made up of double word addresses, hence int 0's address occupies $0000:$0000 through $0000:$0003, int 1's address occupies address $0000:$0004 through $0000:$0007, etc. Int $33's address would be $0000:$00CC through $0000:$00CF. Secondly, this is a poor programming technique. Don't rely on absolute memory references unless it absolutly neccessary. In this case its better to let the operating system give you the correct memory address. Turbo pascal even has this built in. .... uses Dos; const IRET = $CF; var Mouse_Vec: ^Byte; MousePresent: Boolean; Begin GetIntVec( $33, Mouse_Vec); MousePresent := Not ( Mouse_Vec = Ptr(0,0)) or (Mouse_Vec^ = IRET)); ... Granted, the chance of the interrupt vector table ever moving is pretty slim (or none), it's still safer to go through the OS. -- Scott Bostater Georgia Tech Research Institute - Radar Systems Analysis "My soul finds rest in God alone; my salvation comes from Him" -Ps 62.1 uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16 Internet: bb16@prism.gatech.edu
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (12/04/90)
In article <17855@hydra.gatech.EDU> bb16@prism.gatech.EDU (Scott Bostater) writes: >In article <6405@vice.ICO.TEK.COM> bobb@vice.ICO.TEK.COM (Bob Beauchaine) writes: > >First, the interrupt table at low memory is made up of double word addresses, >hence int 0's address occupies $0000:$0000 through $0000:$0003, int 1's address >occupies address $0000:$0004 through $0000:$0007, etc. Int $33's address >would be $0000:$00CC through $0000:$00CF. > Yes, I get bit by that one every time and never seem to learn (or at least remember.). Thank you for pointing that out. This is the method I use, BTW, so I know it is effective (with the proper correction). >Secondly, this is a poor programming technique. Don't rely on absolute memory >references unless it absolutly neccessary. In this case its better to let the >operating system give you the correct memory address. Turbo pascal even has >this built in. > On this point, however, I disagree wholeheartedly. If IBM or anyone else moves the interrupt table, how many millions of machines are going to be obsolete? Poor programming practice is largely a matter of taste, and I use direct memory access whenever possible. If screen drawing programs were limited to using the BIOS for screen I/O, video updates would still be in the stone age for speed. While it may be nice that the Operating system provides these resources, limiting yourself to these routines will never tap the full potential of your machine. [Off podium] Bob Beauchaine bobb@vice.ICO.TEK.COM