Device interfaces and symbolic links

NTDEV
1

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

2

  1. Guids avoid name conflicts.

  2. For device interfaces where there can be multiple instances,
    the hideous setupdi api provides a consistent and reliable enumeration
    mechanism.

  3. For devices that can arrive and depart while the system is
    running the scheme is essential. RegisterDeviceNotification is essential
    and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a
guid as a constructor argument.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

As Mark poitned out, there ARE advantages to device interfaces. You associate devices with provision of a service (what WDM calls an interface class) irrespective of the name of the device. Longs strings of hex digits are effectively self-internationalized (they’re as annoying in ISO Latin-1 as they are in Arabic or Cyrillic). And, again as Mark pointed out, that device notification feature can be incredibly useful.

Still, I agree that Microsoft’s attempt to force users to write two pages of SetupDi code instead of calling CreateFile(…) is just plain silly – and not something I’m likely to advocate anytime soon.

I suggest that you do what we typically do here at OSR (and what most of the drivers for standard Windows components do): Create both a device interface and an easy, user-accessible, device name.

This gives you all (but one) of the advantages and capabilities of device interfaces, with the ability for your users to readily access the device. The only feature you DON’T get by creating a device name is avoidance of name conflicts. But, in the real world, when was the last time you had this particular problem. A little forethought can pretty easily avoid name-conflict issues.

Peter
OSR

4

OK. I can see the advantage for something common like a CDROM drive. For
a proprietary device, it makes much less sense.

I can avoid name conflicts by giving it the same name as my driver with
an enumeration appended to it to identify a particular instance (if it
was easier to get the device instance number - you know the 4 -digit
decimal number that is the key under the class GUID for the device - I
could use that). The possiblity of a name conflict is about as high as
the possiblity of someone having a driver with the same name so I don’t
see it as a problem.

For multiple instances, that is taken care of with the instance ID
appended to my device name as mentioned above.

I had RegisterDeviceNotification working with a symbolically linked
named device, so it doesn’t seem to require device interfaces. My device
does not fit any of the standard setup classes, so it has its own class,
so I guess that’s why it worked?.

So for my purposes there still don’t seem to be any real advantages to
device interfaces over symbolic links. So what about my concern that the
DDI IoCreateSymbolicLink could go away because of the push towards
device interfaces? Is that a valid concern? Can I continue to use it in
order to make life easier for the users of my device? (Bear in mind that
some of these users are accustomed to a linux-style interface and need
to make their code work with both Linux and Windows ( and they pretty
much vomit when they see the SetupDI stuff). Oh and they don’t want me
to supply an API, they want to use standard OS interfaces, so wrapping
the setupDI stuff in a library call or class is out of the question for
what I am currently working on.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

  1. Guids avoid name conflicts.

  2. For device interfaces where there can be multiple instances,
    the hideous setupdi api provides a consistent and reliable enumeration
    mechanism.

  3. For devices that can arrive and depart while the system is
    running the scheme is essential. RegisterDeviceNotification is essential
    and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a
guid as a constructor argument.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

I don’t think you have anything to worry about, in terms of symbolic links (or IoCreateSymbolicLink) going away. This is an original DDI, dating back to the initial release of NT. Also, keep in mind that the world is not restricted to WDM (there are TONS of NT-style drivers out there still). Symbolic links are even USED by device interfaces. I’ve never heard anybody mention this DDI going away. And, from my experience, Microsoft is loathe to break existing drivers by wholesale removal of a DDI (can you think of a DDI that’s been totally removed?)

Of course, nobody’s going to write a guarantee. But, like I said, we routinely use both device interfaces and device names here at OSR in our projects and we have no plans to stop using named devices anytime soon.

Peter
OSR

6

Remember, there are 2 types of calls to RegisterDeviceNotification. The first type is to tell you about the arrival and departure of instances of a device interface, a symbolic link will not work for this type of notification. The second type is a notification on the file handle itself. This notification works on any pnp handle, it doesn’t care how the handle was opened (device interface or symbolic link). This is why you can register for pnp notifications on your open handle. Unless you poll, there is not way for you to know about the device dynamically appearing.

By using symbolic links you still have to follow the device interface rules. You need to remove the sym link in the surprise remove path, otherwise if the same instance is reenumerated you will not be able to recreate the same sym link name. This brings up another issue that dev interfaces solves. You don’t have to manage filling in the gaps in the device instance names, the device interface does it for you. For instance if you have \Device\Foo0-3 and Foo2 goes away, are you going to track the hole in the namespace and fill it on the next device create?

As for your initial concern about not creating a named device, that is a valid concern. When a device is opened, the security settings and other attributes (like exclusive) are checked on the device itself, not at the top of the pnp stack or for each device in the stack. A PDO is required to have a name, so you are guaranteed to have a named devobj in the stack. The device interface creates a symlink to that named device. Now imagine if your FDO also had a name. Now there are 2 ways to open your device, the FDO and PDO. Each of them can have then own security settings and attributes. You can resolve this conflict by specifying these settings in your INF and they will be applied to all devices in the stack by the pnp manager, but most people don’t use this facility. You could say that “well, since I don’t use a device interface, the PDO having a name is not relevant.” Not true, I can find the PDO name in user mode and then create my own sym link to it (via DefineDosDevice()). The solution here is to create an unnamed FDO and in your driver query for the the PDO name and create your symlink against the PDO’s name.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For a proprietary device, it makes much less sense.
?
I can avoid name conflicts by giving it the same name as my driver with an enumeration appended to it to identify a particular instance (if it was easier to get the device instance number? - you know the 4 -digit decimal number that is the key under the class GUID for the device - I could use that). The possiblity of a name conflict is about as high as the possiblity of someone having a driver with the same name so I don’t see it as a? problem.
?
For multiple instances, that is taken care of with the instance ID appended to my device name as mentioned above.
?
I had RegisterDeviceNotification working with a symbolically linked named device, so it doesn’t seem to require device interfaces. My device does not fit any of the standard setup classes, so it has its own class, so I guess that’s why it worked?.
?
So for my purposes there still don’t seem to be any real advantages to device interfaces over symbolic links. So what about my concern that the DDI IoCreateSymbolicLink could go away because of the push towards device interfaces? Is that a valid concern? Can I continue to use it in order to make life easier for the users of my device? (Bear in mind that some of these users are accustomed to a linux-style interface and need to make their code work with both Linux and Windows (?and they pretty much vomit when they see the SetupDI stuff). Oh and they don’t want me to supply an API, they want to use standard OS interfaces, so wrapping the setupDI stuff in a library call or class is out of the question for what I am currently working on.
?
Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links
1)??? Guids avoid name conflicts.
2)??? For device interfaces where there can be multiple instances, the hideous setupdi api provides a consistent and reliable enumeration mechanism.
3)??? For devices that can arrive and depart while the system is running the scheme is essential. RegisterDeviceNotification is essential and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a guid as a constructor argument.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly I do not see any advantages to using device interfaces. They are cumbersome for the user because it forces them to use that awful SetupDI API. It doesn’t save on documentation because I still have to document the GUID to use for the device interface. It seems a whole lot more user-friendly to use IoCreateSymboliLink instead and just document the symbolic link name. It’s much more readable and easier for the user to understand (and no SetupDI usage required). Opening a device with a published symbolic lionk name is much more user-friendly.
?
I don’t want to make life more difficult for the users of my driver because I chose to implement it “the right way”. My users don’t see it as the right way at all. They see it as overly cumbersome. But I am concerned that the IoCreateSymbolicLink DDI will go away because the docs state that WDM drivers do not create named devices. (Huh? Why not?)?However I don’t see the downside of using it and don’t see the advantages of device interfaces. Are there any that maybe I’m just not aware of?
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Storage used to use symbolic links for everything. I tried to get rid
of as many as I could in Win2k because they’re horrible to manage, just
in the same way that unique device names are to manage.

It seems easy when you have one device with one link. Think about
having N devices which can come and go at will. How do you disambiguate
them? You could tack a number at the end, but then do you fill holes
when you’re making new links or do you just keep counting up? If you
leave holes, how does your user know when to stop walking through all
the symlinks? When they get an error (which errors)? At some large
number (how large)? How do you manage races between device arrival and
removal (don’t assume they won’t ever exist).

Many of the problems with symlinks apply to device object names as well.
WDM devices are not supposed to create their own device names because
it’s simply impossible to avoid collisions. Bus drivers should put a
randomly generated name (the I/O manager does this for you) on its PDOs
& let the PNP system manage the links (exceptions in storage where
object name controls which VPB is used).

SymLinks are still used for legacy devices, but new devices classes
should just get over it and use interfaces.

The SetupDI API isn’t great, but it’s not completely unusable, and it’s
exposed to developers writing apps & tools not to end-users.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 5:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

Symbolic Links only work when there’s one of a device and it’s in the
machine all the time. They break down once you go outside that
scenario.

Other things that don’t work well:

1 - Device Interfaces let you get notification when the interface comes
and goes

2 - Device Interfaces are the same from boot to boot (assuming your
device instances IDs remain constant) regardless of the order the device
initialization. For symlinks you never know that Link0 points to the
same device from one boot to the next.

3 - You can’t convert a symbolic link into a SP_DEVINFO item that you
can use with SetupDI to manage the device. Once you dip into SetupDI to
find the device everything else is trivial.

Every time I’ve seen someone make decisions based on the assumption that
only one of their device will be installed all the time, I’ve seen them
regret it shortly afterwards once someone starts actually using the
device. They disable it and re-enable it and suddenly everything else
falls apart.

The device interface link remains the same from boot to boot. Once your
customers discover what it is, they can use it again and again (or make
their own symlink to that) if they’re really flummoxed by SetupDI.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For
a proprietary device, it makes much less sense.

I can avoid name conflicts by giving it the same name as my driver with
an enumeration appended to it to identify a particular instance (if it
was easier to get the device instance number - you know the 4 -digit
decimal number that is the key under the class GUID for the device - I
could use that). The possiblity of a name conflict is about as high as
the possiblity of someone having a driver with the same name so I don’t
see it as a problem.

For multiple instances, that is taken care of with the instance ID
appended to my device name as mentioned above.

I had RegisterDeviceNotification working with a symbolically linked
named device, so it doesn’t seem to require device interfaces. My device
does not fit any of the standard setup classes, so it has its own class,
so I guess that’s why it worked?.

So for my purposes there still don’t seem to be any real advantages to
device interfaces over symbolic links. So what about my concern that the
DDI IoCreateSymbolicLink could go away because of the push towards
device interfaces? Is that a valid concern? Can I continue to use it in
order to make life easier for the users of my device? (Bear in mind that
some of these users are accustomed to a linux-style interface and need
to make their code work with both Linux and Windows ( and they pretty
much vomit when they see the SetupDI stuff). Oh and they don’t want me
to supply an API, they want to use standard OS interfaces, so wrapping
the setupDI stuff in a library call or class is out of the question for
what I am currently working on.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

  1. Guids avoid name conflicts.

  2. For device interfaces where there can be multiple instances,
    the hideous setupdi api provides a consistent and reliable enumeration
    mechanism.

  3. For devices that can arrive and depart while the system is
    running the scheme is essential. RegisterDeviceNotification is essential
    and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a
guid as a constructor argument.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

OK so there are advantages to device interfaces for standard hardware,
multiple instances of the hardware in one system, and devices that come
and go while the system is running.

For identifying a device for normal operation like reading writing and
sending IOCTLs, the SP_DEVINFO is not needed. It is only needed for
device management which is typically done by a setup program rather than
an application used for normal operation. Two different things. It’s OK
to have a setup aplication use the SetupDI stuff. That’s what it was
written for. Forcing an application to use it when all they want to do
is access the device is overkill.

Thanks for the input.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, May 18, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

Symbolic Links only work when there’s one of a device and it’s in the
machine all the time. They break down once you go outside that
scenario.

Other things that don’t work well:

1 - Device Interfaces let you get notification when the interface comes
and goes

2 - Device Interfaces are the same from boot to boot (assuming your
device instances IDs remain constant) regardless of the order the device
initialization. For symlinks you never know that Link0 points to the
same device from one boot to the next.

3 - You can’t convert a symbolic link into a SP_DEVINFO item that you
can use with SetupDI to manage the device. Once you dip into SetupDI to
find the device everything else is trivial.

Every time I’ve seen someone make decisions based on the assumption that
only one of their device will be installed all the time, I’ve seen them
regret it shortly afterwards once someone starts actually using the
device. They disable it and re-enable it and suddenly everything else
falls apart.

The device interface link remains the same from boot to boot. Once your
customers discover what it is, they can use it again and again (or make
their own symlink to that) if they’re really flummoxed by SetupDI.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For
a proprietary device, it makes much less sense.

I can avoid name conflicts by giving it the same name as my driver with
an enumeration appended to it to identify a particular instance (if it
was easier to get the device instance number - you know the 4 -digit
decimal number that is the key under the class GUID for the device - I
could use that). The possiblity of a name conflict is about as high as
the possiblity of someone having a driver with the same name so I don’t
see it as a problem.

For multiple instances, that is taken care of with the instance ID
appended to my device name as mentioned above.

I had RegisterDeviceNotification working with a symbolically linked
named device, so it doesn’t seem to require device interfaces. My device
does not fit any of the standard setup classes, so it has its own class,
so I guess that’s why it worked?.

So for my purposes there still don’t seem to be any real advantages to
device interfaces over symbolic links. So what about my concern that the
DDI IoCreateSymbolicLink could go away because of the push towards
device interfaces? Is that a valid concern? Can I continue to use it in
order to make life easier for the users of my device? (Bear in mind that
some of these users are accustomed to a linux-style interface and need
to make their code work with both Linux and Windows ( and they pretty
much vomit when they see the SetupDI stuff). Oh and they don’t want me
to supply an API, they want to use standard OS interfaces, so wrapping
the setupDI stuff in a library call or class is out of the question for
what I am currently working on.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

  1. Guids avoid name conflicts.

  2. For device interfaces where there can be multiple instances,
    the hideous setupdi api provides a consistent and reliable enumeration
    mechanism.

  3. For devices that can arrive and depart while the system is
    running the scheme is essential. RegisterDeviceNotification is essential
    and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a
guid as a constructor argument.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

What is “normal” operation? Does that assume the device will always be present? If so, that is a pretty big assumption to make. I have seen too many developers assume that since their PCI device would never dynamically appear or disappear only to see that it was manufactured as a PCCARD or USB device later. Name discovery is an important part of normal operation. Device interfaces make name discover more maintainable over time vs a hardcoded name. yes, setupapi is a little ugly, but that is a slippery slope. The next thing you know, the number of parameters and flags to CreateFile() will be onerous ;).

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 11:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK so there are advantages to device interfaces for standard hardware, multiple instances of the hardware in one system, and devices that come and go while the system is running.
?
For?identifying a device for normal operation like reading writing and sending IOCTLs, the SP_DEVINFO is not needed. It is only needed for device management which is typically done by a setup program rather than an application used for normal operation. Two different things. It’s OK to have a setup aplication use the SetupDI stuff. That’s what it was written for. Forcing an application to use it when all they want to do is access the device is overkill.
?
Thanks for the input.
?
Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, May 18, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links
Symbolic Links only work when there’s one of a device and it’s in the machine all the time.? They break down once you go outside that scenario.

Other things that don’t work well:

1 - Device Interfaces let you get notification when the interface comes and goes

2 - Device Interfaces are the same from boot to boot (assuming your device instances IDs remain constant) regardless of the order the device initialization.? For symlinks you never know that Link0 points to the same device from one boot to the next.

3 - You can’t convert a symbolic link into a SP_DEVINFO item that you can use with SetupDI to manage the device.? Once you dip into SetupDI to find the device everything else is trivial.

Every time I’ve seen someone make decisions based on the assumption that only one of their device will be installed all the time, I’ve seen them regret it shortly afterwards once someone starts actually using the device.? They disable it and re-enable it and suddenly everything else falls apart.

The device interface link remains the same from boot to boot.? Once your customers discover what it is, they can use it again and again (or make their own symlink to that) if they’re really flummoxed by SetupDI.

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For a proprietary device, it makes much less sense.
?
I can avoid name conflicts by giving it the same name as my driver with an enumeration appended to it to identify a particular instance (if it was easier to get the device instance number? - you know the 4 -digit decimal number that is the key under the class GUID for the device - I could use that). The possiblity of a name conflict is about as high as the possiblity of someone having a driver with the same name so I don’t see it as a? problem.
?
For multiple instances, that is taken care of with the instance ID appended to my device name as mentioned above.
?
I had RegisterDeviceNotification working with a symbolically linked named device, so it doesn’t seem to require device interfaces. My device does not fit any of the standard setup classes, so it has its own class, so I guess that’s why it worked?.
?
So for my purposes there still don’t seem to be any real advantages to device interfaces over symbolic links. So what about my concern that the DDI IoCreateSymbolicLink could go away because of the push towards device interfaces? Is that a valid concern? Can I continue to use it in order to make life easier for the users of my device? (Bear in mind that some of these users are accustomed to a linux-style interface and need to make their code work with both Linux and Windows (?and they pretty much vomit when they see the SetupDI stuff). Oh and they don’t want me to supply an API, they want to use standard OS interfaces, so wrapping the setupDI stuff in a library call or class is out of the question for what I am currently working on.
?
Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links
1)??? Guids avoid name conflicts.
2)??? For device interfaces where there can be multiple instances, the hideous setupdi api provides a consistent and reliable enumeration mechanism.
3)??? For devices that can arrive and depart while the system is running the scheme is essential. RegisterDeviceNotification is essential and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a guid as a constructor argument.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly I do not see any advantages to using device interfaces. They are cumbersome for the user because it forces them to use that awful SetupDI API. It doesn’t save on documentation because I still have to document the GUID to use for the device interface. It seems a whole lot more user-friendly to use IoCreateSymboliLink instead and just document the symbolic link name. It’s much more readable and easier for the user to understand (and no SetupDI usage required). Opening a device with a published symbolic lionk name is much more user-friendly.
?
I don’t want to make life more difficult for the users of my driver because I chose to implement it “the right way”. My users don’t see it as the right way at all. They see it as overly cumbersome. But I am concerned that the IoCreateSymbolicLink DDI will go away because the docs state that WDM drivers do not create named devices. (Huh? Why not?)?However I don’t see the downside of using it and don’t see the advantages of device interfaces. Are there any that maybe I’m just not aware of?
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

If you remember to format all your output data structures before you
make calls, SetupDI isn’t really that hard. Create a device data set,
get classes with the right device interface, walk through the device
set, get the interface details and use the device path.

Since the device interface strings are static (assuming your device
instance ID stays stable) , your customer could just hard code those
into their app or make a cute symlink to the ugly DI one and use that.
This lets you build your driver the “right” way and lets your customer
use CRT functions to access the device.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 11:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK so there are advantages to device interfaces for standard hardware,
multiple instances of the hardware in one system, and devices that come
and go while the system is running.

For identifying a device for normal operation like reading writing and
sending IOCTLs, the SP_DEVINFO is not needed. It is only needed for
device management which is typically done by a setup program rather than
an application used for normal operation. Two different things. It’s OK
to have a setup aplication use the SetupDI stuff. That’s what it was
written for. Forcing an application to use it when all they want to do
is access the device is overkill.

Thanks for the input.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, May 18, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

Symbolic Links only work when there’s one of a device and it’s in the
machine all the time. They break down once you go outside that
scenario.

Other things that don’t work well:

1 - Device Interfaces let you get notification when the interface comes
and goes

2 - Device Interfaces are the same from boot to boot (assuming your
device instances IDs remain constant) regardless of the order the device
initialization. For symlinks you never know that Link0 points to the
same device from one boot to the next.

3 - You can’t convert a symbolic link into a SP_DEVINFO item that you
can use with SetupDI to manage the device. Once you dip into SetupDI to
find the device everything else is trivial.

Every time I’ve seen someone make decisions based on the assumption that
only one of their device will be installed all the time, I’ve seen them
regret it shortly afterwards once someone starts actually using the
device. They disable it and re-enable it and suddenly everything else
falls apart.

The device interface link remains the same from boot to boot. Once your
customers discover what it is, they can use it again and again (or make
their own symlink to that) if they’re really flummoxed by SetupDI.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For
a proprietary device, it makes much less sense.

I can avoid name conflicts by giving it the same name as my driver with
an enumeration appended to it to identify a particular instance (if it
was easier to get the device instance number - you know the 4 -digit
decimal number that is the key under the class GUID for the device - I
could use that). The possiblity of a name conflict is about as high as
the possiblity of someone having a driver with the same name so I don’t
see it as a problem.

For multiple instances, that is taken care of with the instance ID
appended to my device name as mentioned above.

I had RegisterDeviceNotification working with a symbolically linked
named device, so it doesn’t seem to require device interfaces. My device
does not fit any of the standard setup classes, so it has its own class,
so I guess that’s why it worked?.

So for my purposes there still don’t seem to be any real advantages to
device interfaces over symbolic links. So what about my concern that the
DDI IoCreateSymbolicLink could go away because of the push towards
device interfaces? Is that a valid concern? Can I continue to use it in
order to make life easier for the users of my device? (Bear in mind that
some of these users are accustomed to a linux-style interface and need
to make their code work with both Linux and Windows ( and they pretty
much vomit when they see the SetupDI stuff). Oh and they don’t want me
to supply an API, they want to use standard OS interfaces, so wrapping
the setupDI stuff in a library call or class is out of the question for
what I am currently working on.

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

  1. Guids avoid name conflicts.

  2. For device interfaces where there can be multiple instances,
    the hideous setupdi api provides a consistent and reliable enumeration
    mechanism.

  3. For devices that can arrive and depart while the system is
    running the scheme is essential. RegisterDeviceNotification is essential
    and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a
guid as a constructor argument.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly
I do not see any advantages to using device interfaces. They are
cumbersome for the user because it forces them to use that awful SetupDI
API. It doesn’t save on documentation because I still have to document
the GUID to use for the device interface. It seems a whole lot more
user-friendly to use IoCreateSymboliLink instead and just document the
symbolic link name. It’s much more readable and easier for the user to
understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

I don’t want to make life more difficult for the users of my driver
because I chose to implement it “the right way”. My users don’t see it
as the right way at all. They see it as overly cumbersome. But I am
concerned that the IoCreateSymbolicLink DDI will go away because the
docs state that WDM drivers do not create named devices. (Huh? Why not?)
However I don’t see the downside of using it and don’t see the
advantages of device interfaces. Are there any that maybe I’m just not
aware of?

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

Peter Wieland wrote:

If you remember to format all your output data structures before you
make calls, SetupDI isn’t really that hard.

I mildly disagree. It is one of those not-so-uncommon sets of APIs that
is entirely unusable without a sample. I doubt that anyone outside of
the Microsoft device groups could create a working SetupDi application
from the docs alone.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

>understand (and no SetupDI usage required). Opening a device with a

published symbolic lionk name is much more user-friendly.

Device interfaces are for a special case: if there is a set of possible kmode
drivers bearing the same functionality (like, say, modems, or mice) and there
is a user-mode (or win32k-level) facility which can work with any of them
polymorphically, without known their true nature, and only knowing their
human-readable names.

Usually, the app using device interfaces not only requires SetupDi, it also
requires to have a GUI to provide the user with a choice of what device to
use among the one present (and exposing the necessary functionality). Or,
otherwise, the app can use all of them - like win32k uses keyboards and mice.
Or the app can use the random very first of them.

Beyound this, the device interfaces are useless.

BTW - they are a subkind of symlinks :slight_smile: just a special GUID-formatted symlinks
with the proper GUID in place, and with the registry support to enumerate all
of them.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

That’s pretty much the opinion I have formed about them.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 18, 2006 3:16 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Device interfaces and symbolic links

understand (and no SetupDI usage required). Opening a device with a
published symbolic lionk name is much more user-friendly.

Device interfaces are for a special case: if there is a set of possible
kmode drivers bearing the same functionality (like, say, modems, or
mice) and there is a user-mode (or win32k-level) facility which can work
with any of them polymorphically, without known their true nature, and
only knowing their human-readable names.

Usually, the app using device interfaces not only requires SetupDi, it
also requires to have a GUI to provide the user with a choice of what
device to use among the one present (and exposing the necessary
functionality). Or, otherwise, the app can use all of them - like
win32k uses keyboards and mice.
Or the app can use the random very first of them.

Beyound this, the device interfaces are useless.

BTW - they are a subkind of symlinks :slight_smile: just a special GUID-formatted
symlinks with the proper GUID in place, and with the registry support to
enumerate all of them.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, May 18, 2006 9:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Device interfaces and symbolic links

I mildly disagree. It is one of those not-so-uncommon sets of APIs that
is entirely unusable without a sample. I doubt that anyone outside of
the Microsoft device groups could create a working SetupDi application
from the docs alone.

I did it few years before it but it was unnecessarily laborious task. What I really missed then was the relation between individual APIs. There should be a graph in the docs; similar as for C++ class hierarchy for example. If it is possible to draw it and if there is anybody able to do it. Beverly is right, Setup API causes vomiting.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

16

For this instance, I KNOW that it is not a big assumption that the device will always be present. This is a very special-purpose device and will NEVER be made into a PCCARD or USB device. I am quite certain of that.

Names of devices shouldn’t always have to be discovered. In some circumstances it makes sense (as Maxim pointed out in his earlier email). But there are exceptions where the name of a device should simply be known without a need to discover it.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, May 18, 2006 2:34 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

What is “normal” operation? Does that assume the device will always be present? If so, that is a pretty big assumption to make. I have seen too many developers assume that since their PCI device would never dynamically appear or disappear only to see that it was manufactured as a PCCARD or USB device later. Name discovery is an important part of normal operation. Device interfaces make name discover more maintainable over time vs a hardcoded name. yes, setupapi is a little ugly, but that is a slippery slope. The next thing you know, the number of parameters and flags to CreateFile() will be onerous ;).

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 11:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK so there are advantages to device interfaces for standard hardware, multiple instances of the hardware in one system, and devices that come and go while the system is running.
?
For?identifying a device for normal operation like reading writing and sending IOCTLs, the SP_DEVINFO is not needed. It is only needed for device management which is typically done by a setup program rather than an application used for normal operation. Two different things. It’s OK to have a setup aplication use the SetupDI stuff. That’s what it was written for. Forcing an application to use it when all they want to do is access the device is overkill.
?
Thanks for the input.
?
Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, May 18, 2006 1:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links Symbolic Links only work when there’s one of a device and it’s in the machine all the time.? They break down once you go outside that scenario.

Other things that don’t work well:

1 - Device Interfaces let you get notification when the interface comes and goes

2 - Device Interfaces are the same from boot to boot (assuming your device instances IDs remain constant) regardless of the order the device initialization.? For symlinks you never know that Link0 points to the same device from one boot to the next.

3 - You can’t convert a symbolic link into a SP_DEVINFO item that you can use with SetupDI to manage the device.? Once you dip into SetupDI to find the device everything else is trivial.

Every time I’ve seen someone make decisions based on the assumption that only one of their device will be installed all the time, I’ve seen them regret it shortly afterwards once someone starts actually using the device.? They disable it and re-enable it and suddenly everything else falls apart.

The device interface link remains the same from boot to boot.? Once your customers discover what it is, they can use it again and again (or make their own symlink to that) if they’re really flummoxed by SetupDI.

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 7:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links

OK. I can see the advantage for something common like a CDROM drive. For a proprietary device, it makes much less sense.
?
I can avoid name conflicts by giving it the same name as my driver with an enumeration appended to it to identify a particular instance (if it was easier to get the device instance number? - you know the 4 -digit decimal number that is the key under the class GUID for the device - I could use that). The possiblity of a name conflict is about as high as the possiblity of someone having a driver with the same name so I don’t see it as a? problem.
?
For multiple instances, that is taken care of with the instance ID appended to my device name as mentioned above.
?
I had RegisterDeviceNotification working with a symbolically linked named device, so it doesn’t seem to require device interfaces. My device does not fit any of the standard setup classes, so it has its own class, so I guess that’s why it worked?.
?
So for my purposes there still don’t seem to be any real advantages to device interfaces over symbolic links. So what about my concern that the DDI IoCreateSymbolicLink could go away because of the push towards device interfaces? Is that a valid concern? Can I continue to use it in order to make life easier for the users of my device? (Bear in mind that some of these users are accustomed to a linux-style interface and need to make their code work with both Linux and Windows (?and they pretty much vomit when they see the SetupDI stuff). Oh and they don’t want me to supply an API, they want to use standard OS interfaces, so wrapping the setupDI stuff in a library call or class is out of the question for what I am currently working on.
?
Beverly

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, May 18, 2006 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interfaces and symbolic links
1)??? Guids avoid name conflicts.
2)??? For device interfaces where there can be multiple instances, the hideous setupdi api provides a consistent and reliable enumeration mechanism.
3)??? For devices that can arrive and depart while the system is running the scheme is essential. RegisterDeviceNotification is essential and it is part of the whole guid based interface mechanism.

I just wrap the whole setupdi mess in a simple C++ class that takes a guid as a constructor argument.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 8:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device interfaces and symbolic links

I have used both device interfaces and symbolic links and quite frankly I do not see any advantages to using device interfaces. They are cumbersome for the user because it forces them to use that awful SetupDI API. It doesn’t save on documentation because I still have to document the GUID to use for the device interface. It seems a whole lot more user-friendly to use IoCreateSymboliLink instead and just document the symbolic link name. It’s much more readable and easier for the user to understand (and no SetupDI usage required). Opening a device with a published symbolic lionk name is much more user-friendly.
?
I don’t want to make life more difficult for the users of my driver because I chose to implement it “the right way”. My users don’t see it as the right way at all. They see it as overly cumbersome. But I am concerned that the IoCreateSymbolicLink DDI will go away because the docs state that WDM drivers do not create named devices. (Huh? Why not?)?However I don’t see the downside of using it and don’t see the advantages of device interfaces. Are there any that maybe I’m just not aware of?
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

17

>The SetupDI API isn’t great

The most major issue with it is using a set of 2 structures to denote the
context - HDEVINFO and SP_DEVINFO_DATA.

This is like a C++ class which requires to pass some additional context data in
addition to “this”.

Just amazing.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

18

> Peter Wieland:

It seems easy when you have one device with one link. Think about
having N devices which can come and go at will. How do you
disambiguate
them? You could tack a number at the end, but then do you fill holes
when you’re making new links or do you just keep counting up? If you
leave holes, how does your user know when to stop walking through all
the symlinks? When they get an error (which errors)? At some large
number (how large)…?

Peter, way you see so difficult on the really easy place? :slight_smile:

  1. Idea is simple. Cycle try to create names (as example only) CDROMxx,
    where xx starts from “00”. If successful, it’s OK, if error, it’s busy
    and try the next.
    It is looking for and assigns the empty name with appropriate base
    “CDROM”.
    I used this a lot of time ago in other situation, but I don’t remember
    any complaint on this place in the OEM worldwide distributed product.

  2. Other. The volume hard disk enumerator assigns the volumes
    \Device\HarddiskVolumeXX with numbers XX are growing through one reboot.
    As the result, if you plug in/plug out (or even enable/disable) the disk
    on key, it receives the new names every plug in remaining the “holes” in
    the enumeration. And it is not the problem for Windows!
    I guess it is not difficult to write the same algorithm for private
    device too.
    By the way, CDROM doesn’t so and keeps the number from disable/enable
    operations. And it also works in Windows!
    My opinion, the “hole” problem does not existing… :slight_smile:

Regards,
Michael.

19

The problem with simple solutions is that they often only look good
until you think through the edge cases. At that point they break down.

1 - How far do you iterate looking for a hole? 32 links? 256? Sounds
like a great way for some application to screw with your driver. What
does the application do when link CdRom02 goes away, should it skip to
3? What if 3 is gone, should it skip to 4? How far ahead should you go
across holes?

2 - It’s not a problem for “Windows” because “Windows” doesn’t rely on
that device object name for anything. The mount manager sets up stable
symbolic links for volumes (like c:), and windows uses those when it
needs to find a particular device. Or Windows uses device interfaces.
Or it scans everything and uses volume serial numbers.

It has been a real problem for every piece of software that I’ve seen
which tried to use driver-created symbolic link names as persistent
links to a device. They simply don’t work. I clung to them until I
found the hole problem, at which point I was convinced I couldn’t fix it
myself.

Whether you believe in the “hole” problem or not is your choice. It’s
quite real and it’s difficult to impossible to fix from the driver
level.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Grabelkovsky,
Michael
Sent: Sunday, May 21, 2006 7:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device interfaces and symbolic links

Peter Wieland:
It seems easy when you have one device with one link. Think about
having N devices which can come and go at will. How do you
disambiguate
them? You could tack a number at the end, but then do you fill holes
when you’re making new links or do you just keep counting up? If you
leave holes, how does your user know when to stop walking through all
the symlinks? When they get an error (which errors)? At some large
number (how large)…?

Peter, way you see so difficult on the really easy place? :slight_smile:

  1. Idea is simple. Cycle try to create names (as example only) CDROMxx,
    where xx starts from “00”. If successful, it’s OK, if error, it’s busy
    and try the next.
    It is looking for and assigns the empty name with appropriate base
    “CDROM”.
    I used this a lot of time ago in other situation, but I don’t remember
    any complaint on this place in the OEM worldwide distributed product.

  2. Other. The volume hard disk enumerator assigns the volumes
    \Device\HarddiskVolumeXX with numbers XX are growing through one reboot.
    As the result, if you plug in/plug out (or even enable/disable) the disk
    on key, it receives the new names every plug in remaining the “holes” in
    the enumeration. And it is not the problem for Windows!
    I guess it is not difficult to write the same algorithm for private
    device too.
    By the way, CDROM doesn’t so and keeps the number from disable/enable
    operations. And it also works in Windows!
    My opinion, the “hole” problem does not existing… :slight_smile:

Regards,
Michael.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

20

Even now there are problems with ‘holes’. When you have a removable storage
device such as USB & 1394 and a network mapped drive you can still have
conflicts. Too bad it just won’t work ‘right’. I love drive letters, but
we know they are only a symbolic link in a particular user’s environment.
They can be a pain to get the way you want them and trying to change the
system drive is almost impossible.

If you have three hard drives with multiple partitions on each making the
drive letters run on the first drive for all partitions is a real pain if
the system drive is not the primary partition on that drive. You can make
each of the other drives only have extended partitions and get the order you
want, but why can’t it be easier? Maybe going to volume guids or volume
names would be nicer and it would eliminate the 24 letter limit.

Too bad we can’t get the unused drive letter ‘B’ back or even both ‘A’ and
‘B’ for those machines without floppies. It would require BIOS changes
since bootable CDs/DVDs use ‘A’ for the boot image if emulation is present.

I can now state with certainty that no matter how much disk storage you
have, whatever you have will fill up sooner than you think.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
The problem with simple solutions is that they often only look good
until you think through the edge cases. At that point they break down.

1 - How far do you iterate looking for a hole? 32 links? 256? Sounds
like a great way for some application to screw with your driver. What
does the application do when link CdRom02 goes away, should it skip to
3? What if 3 is gone, should it skip to 4? How far ahead should you go
across holes?

2 - It’s not a problem for “Windows” because “Windows” doesn’t rely on
that device object name for anything. The mount manager sets up stable
symbolic links for volumes (like c:), and windows uses those when it
needs to find a particular device. Or Windows uses device interfaces.
Or it scans everything and uses volume serial numbers.

It has been a real problem for every piece of software that I’ve seen
which tried to use driver-created symbolic link names as persistent
links to a device. They simply don’t work. I clung to them until I
found the hole problem, at which point I was convinced I couldn’t fix it
myself.

Whether you believe in the “hole” problem or not is your choice. It’s
quite real and it’s difficult to impossible to fix from the driver
level.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Grabelkovsky,
Michael
Sent: Sunday, May 21, 2006 7:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device interfaces and symbolic links

> Peter Wieland:
> It seems easy when you have one device with one link. Think about
> having N devices which can come and go at will. How do you
disambiguate
> them? You could tack a number at the end, but then do you fill holes
> when you’re making new links or do you just keep counting up? If you
> leave holes, how does your user know when to stop walking through all
> the symlinks? When they get an error (which errors)? At some large
> number (how large)…?

Peter, way you see so difficult on the really easy place? :slight_smile:

1. Idea is simple. Cycle try to create names (as example only) CDROMxx,
where xx starts from “00”. If successful, it’s OK, if error, it’s busy
and try the next.
It is looking for and assigns the empty name with appropriate base
“CDROM”.
I used this a lot of time ago in other situation, but I don’t remember
any complaint on this place in the OEM worldwide distributed product.

2. Other. The volume hard disk enumerator assigns the volumes
\Device\HarddiskVolumeXX with numbers XX are growing through one reboot.
As the result, if you plug in/plug out (or even enable/disable) the disk
on key, it receives the new names every plug in remaining the “holes” in
the enumeration. And it is not the problem for Windows!
I guess it is not difficult to write the same algorithm for private
device too.
By the way, CDROM doesn’t so and keeps the number from disable/enable
operations. And it also works in Windows!
My opinion, the “hole” problem does not existing… :slight_smile:

Regards,
Michael.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer