@Gus_Issa - Gus, I don’t think you have any personal time left, you are doing so much work on getting TinyCLR up and running, and no doubt more than a dozen other things on the go. I really don’t want to take you away from this, and certainly don’t want to eat into your personal time.
I started a company building embedded real time control systems, hardware and software from the ground up, way back in 1981. It grew quickly, and I know it can really take over your life, you need take care of your work/life balance.(Incidentally, I just watched your “Chain of Trust” video. We are still supporting both hardware (MC68340 based CPUs) and software installed as far back as 1992, 25 years ago)
So, to recap - the idea was to get Windows to recognize our device as WinUSB and use the in-box drivers, specifically because of Windows 10, but also works with Windows 7 up. Adding the required descriptors was ok, and they are recognized using the xusb test program, but Windows won’t load them unless the device identifies as USB2.0 or later, which means the descriptor value bcdUSB should be set to 0x200
The GHI UsbClient doesn’t allow this to be changed, seems to be locked in somewhere in the private native code.
@PHITEK came across this before and found a solution, but it required using the Microsoft UsbClient, couldn’t be done with the GHI libraries.
The only sample code provided is an example from Microsoft, and a couple of Codeshare projects which the GHI documentation points to as example code. The Microsoft one, “Mouse”, is in the NETMF sources and the GHI repo. I’ve been through the GHI repo code, it was updated at NETMF 4.3, but it doesn’t work (the controller Start() returns false from native code) on EMX firmware 4.2 or 4.3.
The same applies to the other examples in Codeshare. If I could trace into the native code (or see GHI’s implementation details, as I can see the MS code) I could figure out for myself what is going on, and whether there is a simple fix, work-around, or no way around it.
Regarding your policy of not releasing source to your Premium libraries, I quite understand. Our own policy has always been to provide our client with full source code and the tools to build it, along with all hardware design files in escrow, and we have never had a problem with that. They don’t want to build the hardware themselves, and certainly don’t want to invest time in understanding the details of our RTOS or network stacks, but it does give them a feeling of security knowing they won’t be left high and dry if we disappear. This seems to be confirmed by the lack of progress on the open-sourced NETMF 4.4. Anyway, different markets, different rules. Just saying…
I’m going to take a break from this now, I’ve provided the client with a somewhat fiddly way to get around the driver signing requirements, and perhaps before the Win10 rollout next year TinyCLR will be production ready and we can go with that instead. I’ll be happy to help test the TinyCLR UsbClient when it is available!