Hi,
Is there any way to steal the control over the hardware ports, like COM1 or
LPT, from already existing driver? For example, if I have my own serial port
driver, say ‘myserial’, how can ‘myserial’ can steal the control from
‘serial.sys’ which is the existing driver in the NT?
Regards,
Chakradhar
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Hi,
Is there any way to steal the control over the hardware ports, like COM1
or
LPT, from already existing driver? For example, if I have my own serial
port
driver, say ‘myserial’, how can ‘myserial’ can steal the control from
‘serial.sys’ which is the existing driver in the NT?
Why not disable it by PnP SetupDi API?
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
If myserial.sys is a filter driver on top of the device that serial.sys
handles, myserial.sys will see the IRPs first and can do with them what
it will.
–
James Antognini
IBM Watson Research
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I have something that blocks the regular driver from taking control, though
it is not a driver itself. I did it to enable an old NT 4 driver for
which I didn’t have the code.
I looked for a way to select a particular device (e.g., COM1, but not COM2)
using the inf file alone, but couldn’t find a way to do it–in fact, the
spec makes it sound as if it can’t be done. So I wrote a class coinstaller
to do the dirty work.
The code I wrote was just enough to serve my purposes. But, if you’re
curious, and if the GPL is acceptable to you, I can send you a copy.
P.S. I read some reports saying that disabling a port on an ACPI system
would power the port off, and render it unusable. However, I’ve had no
problems like that.
At 10:09 AM 5/31/01 +0530, you wrote:
Hi,
Is there any way to steal the control over the hardware ports, like COM1 or
LPT, from already existing driver? For example, if I have my own serial port
driver, say ‘myserial’, how can ‘myserial’ can steal the control from
‘serial.sys’ which is the existing driver in the NT?Regards,
Chakradhar
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You can write what is known as “Class Drivers” in NT
that sits on top of the actual driver (h/w driver or NIC
etc). You have to do all i/o on behalf of your apps
meant for that device. For more details Give this phrase
search “Class Drivers” on msdn. They will lead you to kb
articles. If u can’t get one, let me know I can help u.
–
Girish H.
Hi,
Is there any way to steal the control over the hardware ports, like COM1 or
LPT, from already existing driver? For example, if I have my own serial port
driver, say ‘myserial’, how can ‘myserial’ can steal the control from
‘serial.sys’ which is the existing driver in the NT?Regards,
Chakradhar
You are currently subscribed to ntdev as: xxxxx@att.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com