You do that.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage().
AddDevice routine is used by device drivers to be notified when their device arrives at the bus (e.g. an USB bus).
Insufficient. I don't WANT to have to install a damn device driver to handle a general class of devices. This is the Microsoft model, and it is flawed. I want to write a program in userspace which gets notified when devices arrive, and then it goes out and sniffs their butt to see if it's a device I can claim, and if it is, then I claim it by opening it as a raw USB device and handle the device specific communications protocols in userspace. This is the Mac OS X / Linux / BSD model.
The benefits of this model over the model Microsoft wants us to use is that it allows us to deal with classes of devices without writing a new driver for the device -- or in this case, since we want to start a user space program, a new service for the device.
Conceptually, I suppose it's possible to build a Rube-Goldberg contraption that would consist of a device driver that used the mechanism you suggest, a service in userspace to talk to the Rube-Goldberg contraption, and then launch the application based on it being a device it recognized. That just trades unknown GUIDs for unknown vendor IDs, if not both them and device IDs as well.
Then we are left with replicating the Microsoft USB class driver functionality in its entirety, since the device will have been claimed by our USB driver, and that is the driver our service and application will end up having to talk to.
The notifications need to be able to go to windowless services.
Yes, agree. But they can. It is right there in the documentation.
But now we are back in the same boat of having to install new software - it's just a device driver, instead of a service. Or we can access a vendor/device ID table from the registry - but again, this new table has to be installed for the device to be used.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
That's the thing with GUIDs: It is perfectly safe to choose them during *development*. Generating a guid for a device or an event virtually guarantees that no other device or event will use the same ID. The main problem with GUIDs is that such "well-known" guids needs to be documented. But if Apple writes the device driver that broadcasts the event, surely they can find a way to use the clipboard and use the same GUID during notification registration.
This is the part that's insufficient about GUIDs: if I have a per-device GUID during device development, then I have to put it in the table somewhere, and that's an installation step before I can use the new device.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
I wasn't aware that they are eating CPU like iTunes. Citation?
iTunes is a pig when it polls, no question; PhoneTools and other software is less of a pig, but the main complaint of the OP was that it's using any cycles at all (probably a battery/thermal issue for them), and not blocking when there's no work to do.
... the DataPilot folks, who have no idea in heck what the phone GUID would be when you plug in your stupid random phone, particularly if you are using their DataPilot Universal PRO Kit, which connect up to almost all the phones from Apple, Motorola, LG, Samsung, Sanyo,
Sony Ericsson, and Audiovox.
I have more concrete examples, but I think you get the point.
not really, no. Do they eat CPU cycles polling like the crApple software?
There's no need to be snide in a civil discussion; that's twice, if I include the original posting's comment about moderation.
The answer is that they do not implement the functionality precisely because it would take a service which eats CPU all the time (or the aforementioned Rube-Goldberg, or something like it).
Companies which offer contact sync software for a single device/device class (for example) DO implement the polling, and yes, they take CPU.
The current Microsoft APIs do not solve this general problem; they require either an open application window, or they require a service which polls.
Wrong. Read the documentation. I linked to it and quoted it above. It really is not that difficult.
This sounds like a problem for Microsoft Developer Relations to solve by providing working sample code. Remember, however, the requirements:
(1) Everything needs to block until a device arrives
(2) When a device arrives, a service needs to wake up
(3) None of this must be contingent on a specific vend/device ID pair or GUID
(4) The service then gets to decide if it wants it's application to have the device, and if so, launch the application
(5) When the application claims the device, it needs to be able to do so as a generic USB device, per current APIs
I don't think you will be able to do this without contortions, or without extending the generic USB class device driver, but either would be an acceptable solution. For one thing, you need to be aware that most mobile phones (Motorolla, for example) implement multi-endpointing, where the secondary endpoint only shows up after a conversation with the first. This works by opening the endpoint, and putting the device in an alternate mode which causes a second endpoint to be advertised by the device (effectively, a new USB device arrives), after which the new USB device is talked to with a vendor-private protocol.
BTW, this last (one endpoint arrives, you talk to it, then you get a second endpoint) is exactly how the IronKey and similar secure USB FOBs work, except they also need to launch an intermediate application from the service in order to handle password exchange with the device.
The point here being that I want to be able to plug in my just released Tuesday device, and have my released last year software intended to work with all my devices, including future ones, come up and be able to talk to it.
I do not want to have to do an install, and I do not want to go through the "Windows has discovered a new device; Search for drivers?" dance.
I want it to Just Work(tm).