winehacker at gmail.com
Tue Nov 1 21:47:54 CST 2005
I am forwarding a copy of this message on to Hervé Poussineau with the
ReactOS Project. He has been doing some work on setupapi, Plug and
Play and USB in ReactOS so maybe he can add some comments. I have been
working with him to try and get his changes merged in to Wine.
On 11/1/05, Phil Lodwick <Phil.Lodwick at efi.com> wrote:
> I was introduced to Wine a few months ago and ran into a problem with an
> application I wanted to use. This application makes use of setupapi.dll and
> hid.dll to communicate with a USB HID class device. I quickly determined
> that in this case using native dlls was not an option and created an
> implementation of hid.dll. This solution has worked fine for me.
> >From what I have gathered from monitoring the Wine community, making
> something work for yourself is easy -- getting a general fix into Wine for
> everybody to use, not so easy :-) There is much work that needs to be done
> before I attempt to submit my first patch. Please bear with me as I no doubt
> ask newbie/dumb questions.
> I would like to start with what I consider my most troubling solution. My
> gut tells me there must be a better way, but if there is, it is not obvious
> to me.
> >From MSDN: "To communicate with the device, call the
> SetupDiGetDeviceInterfaceDetail function. This function returns device
> information in an SP_DEVICE_INTERFACE_DETAIL_DATA structure. The DevicePath
> member provides the symbolic link name, which can be used in the CreateFile
> function to access the device."
> On Windows this DevicePath takes the form:
> Obviously, if we were to call Wine's implementation of CreateFile with this
> path, we would not be opening the correct file to communicate with the
> My solution is to have SetupDiGetDeivceInterfaceDetail return a special
> escape string that we can escape in CreateFile to indicate we are really
> talking about getting a file descriptor for an open USB HID device.
> There already seems to be precedence in CreateFile for this type of escape
> mechanism. Currently it appears to be checking for:
> Does my solution for adding a third special escape sequence (\\??\\HID\\)
> seem acceptable?
> If this is the wrong approach, has there been anybody who has thought about
> this problem and what the correct approach would be?
More information about the wine-devel