Our legacy code requires our new driver to be opened with the name something like: “\\.\MyDev0”. We used to do this with IoCreateSymbolicLink.
Looking through the documentation it looks like we should use WdfDeviceInitAssignName, is that correct? I would think that this should be done in
XxxEvtDeviceAdd. However, how do I get the device number in XxxEvtDeviceAdd? Thanks
Michael Wade wrote:
Our legacy code requires our new driver to be opened with the name something like: “\\.\MyDev0”. We used to do this with IoCreateSymbolicLink.
Looking through the documentation it looks like we should use WdfDeviceInitAssignName, is that correct?
No. You use WdfDeviceCreateSymbolicLink.
WdfDeviceInitAssignName is the name you used to pass to IoCreateDevice.
I would think that this should be done in XxxEvtDeviceAdd. However, how do I get the device number in XxxEvtDeviceAdd?
Just like you did before. Keep a driver global variable somewhere, and
bump it up each time you create a new device. (You can either use a
real global variable, or store the value in a WDFDRIVER context structure.)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Oh. I thought we were supposed to use IoGetDeviceProperty, specify DevicePropertyAddress, then right shift by 16. Using a global variable is
certainly easier!
On Mon, 17 Jan 2011 14:59:38 -0800, Tim Roberts wrote:
>Michael Wade wrote:
>> Our legacy code requires our new driver to be opened with the name something like: “\\.\MyDev0”. We used to do this with IoCreateSymbolicLink.
>> Looking through the documentation it looks like we should use WdfDeviceInitAssignName, is that correct?
>
>No. You use WdfDeviceCreateSymbolicLink.
>
>WdfDeviceInitAssignName is the name you used to pass to IoCreateDevice.
>
>> I would think that this should be done in XxxEvtDeviceAdd. However, how do I get the device number in XxxEvtDeviceAdd?
>
>Just like you did before. Keep a driver global variable somewhere, and
>bump it up each time you create a new device. (You can either use a
>real global variable, or store the value in a WDFDRIVER context structure.)
How do I handle the case where device X is always supposed to be XXX1: no
matter where it is plugged in? I realize this is impossible if device X has
no unique serial number, so let’s assume it doesn. I want to map X[UUUUU]
where UUUUUU is the unique serial number to be XXX3:, even if XXX1: and
XXX2: have not been found (yet, or ever). This is particularly interesting
for USB devices where I could have multiple instances, but once device
X[UUUU] is found and assigned a visible device number, XXX3:, I always want
it to be XXX3:, no matter when it is enumerated in the future. For example,
my app knows that device XXX3: is the one it wants to talk to, and XXX3: is
connected externally to something interesting (for example, if I say COM3:
is always connected to the robotic interface, I want my robotic app to
always know that it should use COM3. Assume for purposes of this discussion
that my USB serial port has a unique serial [no pun intended] number).
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, January 17, 2011 6:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Device Numbers/Names?
Michael Wade wrote:
Our legacy code requires our new driver to be opened with the name
something like: “\\.\MyDev0”. We used to do this with
IoCreateSymbolicLink.
Looking through the documentation it looks like we should use
WdfDeviceInitAssignName, is that correct?
No. You use WdfDeviceCreateSymbolicLink.
WdfDeviceInitAssignName is the name you used to pass to IoCreateDevice.
I would think that this should be done in XxxEvtDeviceAdd. However, how
do I get the device number in XxxEvtDeviceAdd?
Just like you did before. Keep a driver global variable somewhere, and bump
it up each time you create a new device. (You can either use a real global
variable, or store the value in a WDFDRIVER context structure.)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I’m not sure I understand the question, so I’ll start the discussion: You get the information that serves as the criteria for establishing your device’s “permanent” name, and then you use that information to construct the permanent name. Having done so, you call WdfDeviceCreateSymbolicLink to assign the permanent name to the link that points to your device.
If you need the data (regarding information to device number mapping) to be dynamically determined at first install, and then persist (across unplug/replug, reboot, whatever) you store it in the registry.
I’m sure I’m missing part of the problem, so my apologies in advance,
Peter
OSR
That’s what I thought from how the DDK worked, so I was wondering if WDF did
it differently. I’ve got a customer who now has to use USB serial ports and
he’s trying to figure out how COM3: is always connected to the device he’s
holding in his left hand, no matter when it is plugged in, no matter the
sequence of boots, unplugs, replugs, etc. His current vendor doesn’t
support this, and I’m not sure that for the particular product he has the
issue is solvable. But I thought it was solvable in general. Since I’m
seeing him next week (we’re about to consider the 2.0 version of his app) I
thought I’d do some research, but didn’t see anything offhand that told me
other than the obvious: assign the number on first detection, retain it in
the Registry, rebind it on subsequent detections.
Now here’s a question about doability: could I write a [mini-] filter driver
that could in some reasonable way “override” the assignment of the serial
port names? [In our case, it would be possible to send a particular packet
out the port and look for a particular reply that says “Yes, I am your
device plugged into the serial port”, but that’s pretty awful, and makes no
sense in general, sort of like the infamous
mouse-probes-shutting-down-the-UPS-units hazard of NT4.0. I’d rather do it
by querying the USB serial port device itself, even seeing if it has a
serial number the current driver is not using]. This gets into mysteries
[to me] of how to cause a [mini-]filter driver to load when the driver
loads, and which creates the serial port name. I feel like I’m about to
step into a minefield here, of playing tricks that are only barely viable,
or make no sense at all. So, for example, if the vendor ignores this
problem and just assigns COM1:, COM2:, COM3: etc based on detection order,
I’d like to “redo” those assignments so that every time the device is
plugged in, independent of order, it becomes COM3:, even though the original
driver software doesn’t support this (assume it has a serial number, or some
other unique way to identify itself that we can determine).
Alternatively, if I can load a driver which is a “transparent” filter, we
don’t have to go with COM1, COM2, etc. as the names; they could be XXX1,
XXX2, etc. where we define XXX, which goes to our level of driver. This may
be the safer approach, but he wasn’t sure he wanted to have to explain the
difference between COM1 and XXX1 to his customers. It also opens nasty
problems like if someone opens COM1 and another open is done on XXX1, we
have a mess.
This is for a product for which I did the 1.0 app about five years ago, when
computers actually came with serial ports built in. You could, in the app,
assign it to COM1: and every time the machine booted, it was still COM1.
That no longer seems to happen. He’s perfectly willing to say “I will
support this only for the brand X USB serial port adapter, and we will send
you one free” because the cost of the adapter is lower than the support call
cost. So we don’t need an every-vendor-possible solution. So far, he tells
me he’s not found one that guarantees the serial port assignments remain
constant.
If I were writing the driver from scratch, and knew there was a serial
number in the device, then the solution you propose is exactly how I would
have chosen to do it, but the problem is, can we make this work when the
existing driver wasn’t designed to support it, assuming we can uniquely
identify the unit itself in some way [up to and including saying, “You can
only use one Brand X USB serial port adapter on your machine, and that’s the
one supported to talk to your one-and-only instance of our device” which is
more restrictive than he would like, but would handle perhaps 90% of his
customers who only have one of the [fairly expensive] devices he
manufactures in their shop. [And yes, I asked him why he isn’t considering
USB 2.0/3.0 or TCP/IP interfaces on his 2.0 device, instead of a serial
port, and that issue is still open. But he wants to support his existing
customer base of several thousand units as well, who are moving to new
computers without serial ports]
Any ideas would be welcome. He just hit me with this, so I haven’t had much
time to investigate it (the situation where I have managed to nearly forget
everything I knew about the 1.0 version, and out of the blue, he calls up
and says “Want to do the 2.0 version?”)
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, January 18, 2011 10:31 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Numbers/Names?
I’m not sure I understand the question, so I’ll start the discussion: You
get the information that serves as the criteria for establishing your
device’s “permanent” name, and then you use that information to construct
the permanent name. Having done so, you call WdfDeviceCreateSymbolicLink to
assign the permanent name to the link that points to your device.
If you need the data (regarding information to device number mapping) to be
dynamically determined at first install, and then persist (across
unplug/replug, reboot, whatever) you store it in the registry.
I’m sure I’m missing part of the problem, so my apologies in advance,
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
> Now here’s a question about doability: could I write a [mini-] filter driver
that could in some reasonable way “override” the assignment of the serial
port names?
Yes, this is called “coinstaller” and not “filter driver”.
Also note that “COM1” style of names are obsolete, and it is much better to never rely on them.
Thus the whole PnP device interface stuff. The same piece of hardware with the same embedded serial will get the same PnP device interface name, regardless even of to what port it is plugged into.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Not so much.
If the COM1 style names are obsolete, somebody sure forgot to tell the people who develop the .Net CLR. The SerialPort class is specifically designed for such devices, and is limited to supporting devices with names that start with the letters “COM” – Not a decision that I, personally, would have made… but it shows the incredible persistence of this name formulation.
Having SAID that… if one can get their customers to switch to using the yucky mechanisms necessary to open a device by device interface GUID, that IS a “better” solution… for some value of “better.”
Peter
OSR
I feel the same way.
I can’t think of any GOOD way for you to re-jigger the symbolic link assignments. Let’s say the original driver assigns “COM1” and you want “COM9” – You COULD delete the symbolic link assignment and assign COM9. Problem solved? Well, yes… UNTIL: (a) the original driver attempts to delete the symbolic link he created… ooops, it’s gone, or (b) the original driver attempts to assign “COM9” to one of the device he created, knowing that he hasn’t used this name… ooops, it’s already in use (this latter case is less of a problem with the name COM, but still… you have to wonder if the original driver will handle this).
THAT is, indeed, do-able.
But, as you said… will that be acceptable to the customer? As I previously mentioned, if the customer is writing applications using .Net’s SerialPort class, the answer to that will be “no.”
Peter
OSR
If you are going down the XXX route, might as well use device interfaces since that is functionally equivalent and more friendly to PnP. BTW if your usb device has a valid serial number in it, this issue goes away because the device will have the same identity (and thus the same assigned serial port number) no matter how it is plugged into the machine (3 hubs deep or at the root, etc). the driver has no idea the serial number is there nor does it care. Seems like if the COMx name is that important, it is much cheaper to fix this at the hw level with a few cents per device vs a whole layer of abstraction in software to mask the problem.
d
Thanks, Peter, you’ve confirmed my worst fears. I was pretty certain this
was not going to work, just because it seemed so hokey (gratuitously complex
solutions are so rarely viable).
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, January 19, 2011 11:02 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Numbers/Names?
I feel the same way.
I can’t think of any GOOD way for you to re-jigger the symbolic link
assignments. Let’s say the original driver assigns “COM1” and you want
“COM9” – You COULD delete the symbolic link assignment and assign COM9.
Problem solved? Well, yes… UNTIL: (a) the original driver attempts to
delete the symbolic link he created… ooops, it’s gone, or (b) the original
driver attempts to assign “COM9” to one of the device he created, knowing
that he hasn’t used this name… ooops, it’s already in use (this latter
case is less of a problem with the name COM, but still… you have to wonder
if the original driver will handle this).
[quote]
Alternatively, if I can load a driver which is a “transparent” filter, we
don’t have to go with COM1, COM2, etc. as the names; they could be XXX1,
XXX2, etc. where we define XXX, which goes to our level of driver. This may
be the safer approach [/quote]
THAT is, indeed, do-able.
But, as you said… will that be acceptable to the customer? As I
previously mentioned, if the customer is writing applications using .Net’s
SerialPort class, the answer to that will be “no.”
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.