WebUSB works in pretty much the same way. You'll have the same set of functions that libusb exposes there too.

Sadly it's not supported at all on anything but Chrome right now

Descriptors also were kind of a mystery for me until I realized that they're just a binary structure with a fixed format that the host reads and interprets.

The device descriptor is easy enough to get right as it doesn't have too many fields and every USB class just defines in the specification which Class and SubClass it uses for its interface descriptor as well as which endpoints that interface needs to have. And that's, for the most part, all you need for the host to recognize your device

ADB uses libusb or WinUSB directly from userspace too yeah. On Windows you still need a .inf driver though because the WinUSB driver isn't getting loaded by default for Android devices because they're lacking the MS OS Descriptor

In 99% of cases you don't need a kernel driver.

I don't think anyone uses the "native" usb way on either windows or mac os, when it's so much easier to go through libusb.

I've personally done a custom DFU updater for Mac OS some time ago by using libusb. It worked just fine(tm). I don't want to try and evaluate how long it would have taken to do it with the mac api.

dfu-util actually also just uses libusb under the hood! Any class or device that doesn't have a driver baked into the OS can be implemented like this. And if you'd need the DFU functionality in a different application, you may be able to just simply link parts of the dfu-util tool into your application

On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter.

Of course, when you're doing these things in userspace you either need some way of communicating with the Kernel or for the other subsystems to be in userspace as well.

Not to be too facetious but a great place for communicating with the kernel where there are a ton of other driver subsystems is... the kernel.

Possibly a good addition to the article would be parallel development of an lkm. I guess it wouldn't have that windows interop but I would also be interested to see how this driver would be implemented on Windows. If it's idk 10x as many lines in the kernel vs userspace, that's a great benefit to the userspace approach.

In HFT user-space networking drivers have a long history - there is too much latency induced by switching from kernel to user space to handle networking.

> OpenOnload: A user-space network stack that intercepts socket calls to bypass the kernel network stack, accelerating standard socket operations for faster networking.

> Netmap: A framework providing a simple API for high-speed packet I/O in user space, bypassing much of the kernel overhead for efficient packet forwarding and filtering.

https://dysnix.com/blog/high-frequency-trading-infrastructur...

Driver signing is a killer issue on Windows; if you put your machine into dev/unsigned mode you get an ugly banner that can't be turned off.

Much easier to design the device to avoid that. E.g. by abusing USB-HID. The desktop USB missile launcher toy is USB HID, for example.

No need to pretend to be HID. Windows has WinUSB for userspace USB drivers that don't need special signing.

iirc sending HID feature reports doesn’t need admin rights on windows

Arguably all these other subsystems shouldn't be in the Kernel either but that's a different topic :)

There are quite a few benefits to doing these things in userspace over the Kernel, not really necessarily just because of the code size:

- The code is much easier to write and debug, you just write code like you always would.

- Bugs don't have the possibility to taking down your entire system or introduce vulnerabilities

- Especially on Windows, everyone can do this without requiring an impossible to get driver signing certificate

Hey, I'd just like to tune in here real quick. I've been using this username since I was like 10, long before I really understood what Nazis are. By the time I learned about this, I've already had this username for years and changing it everywhere would have been a ton of work. As a native German speaker, this association is really not something people generally make. I'd mostly just like to state that I'm probably as far away from being a right extremist as I can be.

Nobody's accusing you of being one. Peace.

By default it uses a pixel-perfect font (the one that's included in ImGui) so anti-aliasing will not do anything but make text look blurry.

If you don't like the default font, it's super easy to change it though. Just go into the settings and under Font select your .ttf Font file

What do you mean by a pixel-perfect font? A bitmap font? Seems a very odd choice for the current era of high resolution screens.

Thanks a lot for the love! If you have any feature requests, face any problems or have any questions, please open an issue on my GitHub page and I'll make sure to look into it as soon as possible. There's also a Discord server linked at the top of the Readme