On Fri, Aug 19, 2016 at 10:50 AM, Hermann Hamann <hermann-***@web.de> wrote:
> Hi Tormod,
> thank you for your expertise; now I see clearer.
>
>> < Why it crashed?
>> I don't know.
>
> I will send you a crash dump later.
Great, thanks.
>
>> <If you want to use libusb-1.0 backend, you need to have libusb-1.0.dll in
>> <the system and better use WinUSB driver for your device.
>>
>> I want the backend that is in the registry.
>
>>pyusb by default looks for libusb1 first
>
> < .... you must select backend explicitly.
>
> Well how can I? I do not know which backend is available on my clients'
> machines.
You should know! The application that you deliver to your client is
your.py + pyusb + libusb backend. If your application is "taking care"
of a device you ship this bundle + hardware driver (libusb0.sys or inf
declaring WinUSB for the device). If your application is just an extra
tool and an existing application already installed a hardware driver
that you don't want to interfere with, you better know the application
which "owns" the device and which hardware driver it uses, but as you
already are aware of, you can also read out the registered hardware
driver from the registry. If the existing hardware driver can be
either libusb0.sys or winusb.sys, you must bundle all appropriate
backends to handle all cases. As I said before, the libusb1 backend
should handle both, but due the bug you encounter it seems you will
need to bundle both libusb1 and libusb-win32 for now and your
application must choose between either as function of the hardware
driver, as a workaround for this bug. Again, only if you cannot decide
the hardware driver for this device...
And whether the client may have other applications using some variety
of libusb or not, that is not something you should speculate about,
because the other "private" libusb libraries can be modified versions
for what you know. If the machine is well administrated, it might have
a relatively recent, official libusb installed in the system32 folder,
but you probably shouldn't rely on that. Your installation
program/instructions should install the libusb DLL that you need.
> I can only rely on the driver that was installed for my device and which is
> displayed
> in the control panel. I suppose the control panel gets it through the
> registry.
>
> << Flexibility comes at a cost.
> And what is the cost of reliability?
The cost of reliability here is that you shouldn't rely on the
convenience auto-detection of already installed libusb backends that
pyusb offers as an option. It is provided as a convenience, but as an
application programmer you don't have to rely on it. As any other
application programmer you should know what is the hardware driver
used for the device, and assure the existence of libraries that your
program needs. pyusb has the flexibility of working with many backends
and thus with many hardware drivers so it gives many possibilities.
The cost of flexibility is that is you have choose between all these
possibilities, and make sure your choice is implemented.
It would be very normal for a program or library to depend on one
specific hardware driver. Here pyusb is very flexible. The cost of
this flexibility is paid by the pyusb developers, and only your choice
of relying on the autodetection convenience is adding to your bill.
The client's flexibility to use different hardware drivers will cost
you as the application programmer. On the other hand if you know that
the device uses the libusb0.sys hardware driver, and you know that the
libusb-win32 backend works well with your device, you just select this
backend in your application and bundle libusb-win32 with it. You also
make sure that this libusb0.dll is the one picked up by pyusb by
having it first in the path that pyusb uses for DLL discovery. This is
how other Windows applications make sure they have the right DLL's
(and version) loaded, for instance by throwing them into the directory
where the executable is. Or you follow the suggestion in the pyusb
manual https://github.com/walac/pyusb/blob/master/docs/tutorial.rst#specifying-libraries-by-hand
(with the only catch that you might have to find out if the host is 32
or 64 bit).
>
> <And the pyusb application currently uses a DLL search to select default
> library
> <backend, regardless of the device.
>
> Well I rank the registry higher in authority than the library search order.
It looks like you are mixing up library backend and driver. The
registry will tell you which driver (part of OS) is handling the
device. The OS doesn't dictate what DLL's you make up your application
from. From the OS point of view, your application includes pyusb and
libusb backend. The libusb backend is not a driver or service, it is a
piece of code linked into your application (linked at run-time in the
case of pyusb).
>
>
> <Hermann, in your case you are probably better off selecting the
> <libusb0 backend in your python application, if you know that your
> <device requires libusb0.sys. Otherwise, register the device for WinUSB
> <(with .inf file or Zadig), make sure a known good libusb1.dll is
> <installed in the path (before any third party libusb1.dll) and select
> <the libusb1 backend in your python application for good measure.
>
> Well I am a bit confused when regarding recommendations for driver
> installation.
> The tutorial recommends the inf-wizard and libusb0 and so I did and it works
> fine.
Which exact tutorial? That must be for the libusb-win32 backend.
> Well I can instruct my clients to do the same and hardcode pyusb0 into my
> program.
BTW, do you actually mean pyusb0 (0.4) or libusb0? It actually gets
really fun if you have a pyusb 0.4 program, that either runs through
pyusb 0.4 (and its possible backends) or through the pyusb 1.0 legacy
mode (and thus the backend selection we have talked about) - a lot
more combinations possible and auto-selections that the poor 0.4
program wouldn't know about. I remember trying to draw a chart of
these once... This gets even more complicated with Linux factored in,
where many supported distributions still have pyusb 0.4 so making one
pyusb application that works everywhere is challenging, at least
without bundling your own pyusb, and python, and libusb - for each
platform...
> So much about flexibility.
Flexibility is not the same as autodetection. And the autodetection
actually works as intended. Just the above mentioned bug may have
ruined the result. Or the 3rd party libusb1.dll that was first in your
path is somehow broken - let us know if you can reproduce with the
official, latest libusb.
>
> <BTW, Hermann's example patch hardcodes "ControlSet002" which I believe
> <should be "CurrentControlSet", unless there are better ways to find
>
> I found this with a registry editor search. I do not understand enough to
> judge the generality of this approach.
>
> <(e.g. different serial numbers but same vid/pid) can have different
> <Service values, and I am not sure how the patch deals with that.
> I would not care, nobody will have two same oscilloscopes on its computer.
The Windows registry contains different instances for each serial
number. If the oscilloscopes have no USB serial number, there will be
a new instance for every USB hardware port address used. In theory you
can have different drivers associated depending on which USB port it
is plugged into :)
>
> Thank you again for your effort, this makes my issue obsolete an I will not
> open it.
Glad I could help. Your issue is at a level higher than pyusb.
Tormod
>
> Sincerely Hermann
------------------------------------------------------------------------------