Hi All,
I have a unique situation where I need to do an IOCTL call to my serial
driver, yet I cannot open the port to get a handle to do the call. The port
is currently opened by another application in the middle that I have no
control over.
I am considering sending an IRP to the driver but is there a way to do this
from an application program?
I own the source code to both the application and the driver so I am free to
modify either.
Any other suggestions?
Thanks for the help, David
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
The serial device object is exclusive by design. You could have your driver
create a separate ‘control’ device object that is not a serial device, that
only your application knows about, and that your application uses to
communicate whatever foul and depraved secrets it shares with your driver.
If you are managing more than one serial device then you will have to invent
some protocol for identifying which serial device your application is
mucking with. I’d probably opt for the 1-1 relationship between control
device objects created by my driver and real serial device objects.
-----Original Message-----
From: David Worthen [mailto:xxxxx@connecttech.com]
Sent: Tuesday, January 22, 2002 8:12 AM
To: NT Developers Interest List
Subject: [ntdev] Calling a Driver from an Application
Hi All,
I have a unique situation where I need to do an IOCTL call to
my serial driver, yet I cannot open the port to get a handle
to do the call. The port is currently opened by another
application in the middle that I have no control over.
I am considering sending an IRP to the driver but is there a
way to do this from an application program? I own the source
code to both the application and the driver so I am free to
modify either. Any other suggestions?
Thanks for the help, David
You are currently subscribed to ntdev as:
xxxxx@stratus.com 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
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
>
> The serial device object is exclusive by design.
>
So, since you control both driver and app, you could just make your Serial
device object non-exclusive – thus allowing multiple opens on the device.
You’ll probably want to restrict what opens after the first can DO. But if
you wanna stuff an IOCTL to your driver, while some other app has read/write
operations in progress, I don’t see any reason why you can’t just do that…
Peter
OSR
—
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
Thanks Peter,
Sometimes the solution is just too obvious and it needs un-necessary
complication.
We’ll give it a try.
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: January 22, 2002 4:17 PM
Subject: [ntdev] Re: Calling a Driver from an Application
> “Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> >
> > The serial device object is exclusive by design.
> >
>
> So, since you control both driver and app, you could just make your Serial
> device object non-exclusive – thus allowing multiple opens on the device.
>
> You’ll probably want to restrict what opens after the first can DO. But
if
> you wanna stuff an IOCTL to your driver, while some other app has
read/write
> operations in progress, I don’t see any reason why you can’t just do
that…
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@connecttech.com
> 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
Well except that if this is intended to be a standard serial port, then
I think it is exclusive by design and violating that design might have
unintended consequences.
The w2k-ddk serial driver does the following:
if (InterlockedIncrement(&extension->OpenCount) != 1) {
ExReleaseFastMutex(&extension->OpenMutex);
InterlockedDecrement(&extension->OpenCount);
Irp->IoStatus.Status = STATUS_ACCESS_DENIED;
SerialCompleteRequest(extension, Irp, IO_NO_INCREMENT);
return STATUS_ACCESS_DENIED;
}
This looks rather intentional to me. Are you sure that it is correct to
create a general purpose serial device that allows multiple opens to the
same device? How, for example, will an application that believes that it
has exclusive access to a serial port, simply by successfully opening
it, continue to behave correctly once this assumption is violated?
=====================
Mark Roddy
Windows XP/2000/NT Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
xxxxx@hollistech.com
For Windows Device Driver Training: see www.azius.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Worthen
Sent: Tuesday, January 22, 2002 4:43 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Calling a Driver from an Application
Thanks Peter,
Sometimes the solution is just too obvious and it needs un-necessary
complication.
We’ll give it a try.
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: January 22, 2002 4:17 PM
Subject: [ntdev] Re: Calling a Driver from an Application
> “Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> >
> > The serial device object is exclusive by design.
> >
>
> So, since you control both driver and app, you could just make your
Serial
> device object non-exclusive – thus allowing multiple opens on the
device.
>
> You’ll probably want to restrict what opens after the first can DO.
But
if
> you wanna stuff an IOCTL to your driver, while some other app has
read/write
> operations in progress, I don’t see any reason why you can’t just do
that…
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@connecttech.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@hollistech.com
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
“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> This looks rather intentional to me. Are you sure that it is correct to
> create a general purpose serial device that allows multiple opens to the
> same device?
>
Except this doesn’t sound like “general purpose” use to me… The guy’s got
control to both the driver and the app. That means that app will make or
not make any assumption he codes into it, right?
And he’s customizing the driver.
The are a million possible ways to do this, even in a “general purpose”
system. Consider only allowing subsequent opens by a specific, nominated,
application – know to the driver – and then allow that app to only perform
certain functions. Or… whatever.
In any case, I guess I’m hopin’ Mr. Worthen isn’t thinking of REPLACING the
serial port driver provided by Microsoft in a GENERAL PURPOSE system. If he
is, then, there’s that whole Windows File Protection thing to worry about,
not to mention upgrade chaos, and… The least of his problems will be the
apps the won’t work.
Peter
OSR
—
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
Not by my reading:
Hi All,
I have a unique situation where I need to do an IOCTL call to
my serial driver, yet I cannot open the port to get a handle
to do the call. The port is currently opened by another
application in the middle that I have no control over.
The ‘middle application’ is some j-random-app that has opened a serial
port.
Anyhow, if it is a serial port that can be enumerated as a serial port
(i.e. comN) then allowing non-exclusive opens will break applications
that expect the open to ONLY succeed when exclusive access is granted.
These apps are unlikely to be written such that a subsequent
read/write/ioctl failure is going to be tolerated.
Yes sure your way could be made to work, but if the goal is side channel
communication, why not just provide a side channel over which to
communicate?
=====================
Mark Roddy
Windows XP/2000/NT Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
xxxxx@hollistech.com
For Windows Device Driver Training: see www.azius.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
Sent: Tuesday, January 22, 2002 11:43 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Calling a Driver from an Application
“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> This looks rather intentional to me. Are you sure that it is correct
to
> create a general purpose serial device that allows multiple opens to
the
> same device?
>
Except this doesn’t sound like “general purpose” use to me… The guy’s
got
control to both the driver and the app. That means that app will make
or
not make any assumption he codes into it, right?
And he’s customizing the driver.
The are a million possible ways to do this, even in a “general purpose”
system. Consider only allowing subsequent opens by a specific,
nominated,
application – know to the driver – and then allow that app to only
perform
certain functions. Or… whatever.
In any case, I guess I’m hopin’ Mr. Worthen isn’t thinking of REPLACING
the
serial port driver provided by Microsoft in a GENERAL PURPOSE system.
If he
is, then, there’s that whole Windows File Protection thing to worry
about,
not to mention upgrade chaos, and… The least of his problems will be
the
apps the won’t work.
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@hollistech.com
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