On 2012.09.03 03:51, Alan Stern wrote: > It's kind of a shame that Windows goes to such lengths > to provide the illusion of a continuous data stream instead of the > packetized stream that USB actually uses -- this just causes more > complications in the end.
But aren't we trying to do the same, i.e. provide the illusion of a continuous data stream, in libusbx? ;) With WinUSB (and its DLL) intended to be used as a standalone API, rather than the lower part of a higher level library, I'm not sure we can blame Microsoft from trying to hide some of the native complexity from Windows USB app developers in WinUSB. It seems that, for better or for worse, much of Windows model tries to hide complexity... and we're doing some of that too. For what is worth, we're also seeing some of the limitations of that model with the Windows HID API, as we have no means to retrieve the actual HID Report Descriptor data there, Thus, when asked for it in libusbx, we have to reconstruct an approximation from the bits and pieces we have... As to adding support for transfer breakdown in the Windows backend, I don't think I'll look into that any time soon, especially as, at the risk of reopening an old wound, I wasn't entirely happy with Graeme's solution when he did some of it with the original libusb0.sys driver support (and I don't think his implementation was that different from your proposal). Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
