Understanding libusb within Windows USB architecture

[gwideman]

Hi Jan and all,

I have been trying to understand the "world of libusb", and how it fits into the Windows USB realm. I have Jan's USB Complete 4ed (which barely mentions libusb), and I'm greatly looking forward to the fifth edition. But I'd really like to make some headway ASAP.

This topic arises particularly when trying to install USB gadgets that use libusb, and something goes wrong. Knowing how these pieces are supposed to cooperate (or don't) would go along way to sorting out (or anticipating) the trouble.

My two main questions are regarding Microsoft's diagram(s) of the library and driver components, and how libusb library and driver components fit into that picture (or don't).

These diagrams seem a good start:

USB Driver stack architecture
https://msdn.microsoft.com/en-us/library/windows/hardware/hh406256%28v=vs.85%29.aspx

WinUSB Architecture and Modules
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540207%28v=vs.85%29.aspx

First puzzle: in the WinUSB diagram, there are three instances of winusb.sys shown, and mentioned in the narrative. But then the narrative also says "There is exactly one loaded instance of Winusb.sys." How does one reconcile this seeming contradiction?

Main puzzle: how the following libusb components fit into the USB driver stack architecture, including cases where they rely on WinUSB:

libusb-win32, implements libusb API 0.1, and includes:

• libusb0.sys driver
• libusb0.dll library
• libusb.lib (no zero in the name, but exposing presumably the actual 0.1 API)

libusbK, the successor project to libusb-win32, described as implementing a "100% WinUSB compatible api/function set" plus additional features. Embodied in:

• libusbK.sys driver
• libusbK.dll library
• Also includes the libusb0 components as well.

libusb from libusb.info. Implements libusb 1.0 API, and appears to be favored for use by applications that need to run on multiple operating systems, as it's available also for linux and Mac. Includes:

• libusb-1.0.dll (separate versions for MS64, MS32, MinGW64, MinGW32), plus static-linkable versions (libusb-1.0.lib)

Libusb docs say that on Windows, libusb requires driver(s) from WinUSB, or libusbK, or libusb-win32 via libusbK.

There are also disjointed discussions in various docs about how these can be used as upper or lower drivers, or filters and so on (and I'm not clear what those actually refer to on specific diagrams).

I think, but am not sure, that I'm stumbling on further confusion in terminology and discussions between kernel mode and user mode _drivers_, and between user mode _drivers_ and _libraries_. Some authors perhaps imply "kernel mode" when they say "driver", while other authors may refer to a library as a "user mode driver"? I'm not sure.

I'd like to piece together a coherent picture of how the pieces fit together.

Enlightenment would be appreciated!

-- Graham

[Jan Axelson]

The language MS used is unfortunate. As I understand it, winusb.sys loads once, but multiple devices can use the loaded driver.

I would use libusb 1.0. It's more recent and I believe more robust. I'm not familiar with libusbk, but if using Windows, I would just use WinUSB rather than libusbk.

The Microchip Libraries for Applications includes WinUSB/libusb host applications that might be useful.

[gwideman]

Hi Jan,

Thanks very much for your reply, addressing the first part of my question. Your further pointer to Microchip was definitely very interesting, but seems to address mostly the client application, and the external device stack, but not the Windows USB stack and where the libusb-related components I mentioned fit in.

In brief, what I'm trying to learn is:  Where, in the USB software stack architecture diagrams on MS's site (or in USB Complete 4ed) would libusb-1.0.dll, libusb0.sys, libusb0.dll, libusbk.dll and libusbk.sys fit?

If you have insight into any or all of these, I'd appreciate it!

-- Graham

[Jan Axelson]

Typically, .sys drivers are low-level (kernel mode) drivers, and dlls are user-mode drivers that expose functions that applications can call.