win32 VS InputShareUSB

Yeah, I feel you... docs should be more specific because in v1.1 you only get an ErrorLevel of 1 which means "Yo! There's an error" and that's it. At least in v2, it raises an ERROR_INVALID_HANDLE which at least is in the ballpark.

OK, but how? Does this still apply? is it the same? Oh wait, that doesn't detail how IExplorerCommand is registered. is it just part of the ShellEx key like IContextMenu? Microsoft docs used to be actually good for this, if anything you'd get too many technical details. The documentation for this new way they want everybody to use is seemingly non-existent.

The documentation source is available (e.g. https://github.com/MicrosoftDocs/win32) but I can't figure out how to build it. There's hints of docfx being used but I can't get it to build without errors due to the markdown being too deeply nested.

This seems to be a good discussion of mouse messages.

2147500036 from dec to hex is 80004004. When I look at the extended reason code info from https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/TermServ/extendeddisconnectreasoncode.md

Have you tried using a different cable? A few months ago I wrote a similar program and someone experienced the same issue and it turned out to be the cable.

I wrote something similar (windows --network--> raspi zero w --usb--> target device). My first attempt used a simple tcp stream without nagle's algorithm and it was completely useable because I was sending way to many packets this way. After turning nagle's algorithm back on it generally usable but it also introduced something like a 0.5s delay (it's easily noticable, trust me). However the whole thing was pretty unstable, because even a small hick-up in network quality would result in a death spiral that took around 2-3s to resolve itself and make the program usable again. I'm sure I could've optimized my naive tcp protocol further to make it more stable but I chose to fix the problem on the source and wrote my own simple, reliable, ordered network protocol on top of UDP. While it currently has some limitations (no encryption, no congestion control, connection loss is somewhat ungraceful) it runs amazingly stable even under bad network conditions and with unnoticeable latency.

Both the Windows and Raspberry Pi parts of this project are written in Rust and can be found here.

Yes. When you use the Linux gadget driver it creates a device like /dev/hid0 for you in that you can write your usb-hid packets. This means that you can write a simple script that listens to a TCP connection and simply forwards everything it receives into /dev/hid0. On the PC side of things you then simply connect to this TCP server and you're good to go. Here is an example of what I'm talking about.