On Sun, Jul 3, 2011 at 4:49 AM, Keith Curtis keithcu@gmail.com wrote:
So: yeah, we know it's an important app. But it's hard. Feel free to help out.
- Dan
Hi;
I am glad to hear you say that iTunes is an "important" app, but I don't understand what you mean because it has never worked.
You don't need my help. You've got a big group making many good fixes. It is just that priority is being ignored or something. Failure is not from lack of effort, but from planning.
Hi Keith
Having worked at Microsoft, you of all people should appreciate the size and complexity of the driver architecture on Windows. So I would say that "failure" is mostly from the scale of the problem to be solved.
My attempts at adding USB support to Wine have been painful and slow. In 2006 my first patches ever submitted to Wine dealt with some SETUPAPI.DLL bugs. By around 2007 hacks I made to Wine and the Linux kernel to emulate USBSCAN.SYS allowed my Windows-only user-space USB scanner driver to work in Ubuntu 6.06. Some of those hacks were eventually cleaned up and made their way into Wine's STI.DLL in 2009, but my kernel patch never worked on any other kernel version, and I doubt either Wine or the Linux kernel would accept the dodgy code I had to use. I began investigating the option of implementing USBSCAN in a user-space driver with something like CUSE, but then Wine got a rudimentary NTOSKRNL.EXE and the ability to load Windows SYS files. Since then the idea was to implement everything in Wine, and use libusb for USB I/O.
In 2010 I added some USBD.SYS functions and some USB headers to Wine. Later I tried to add libusb support, USB device monitoring, and basic on-demand driver loading infrastructure, but none of that was accepted into Wine for various reasons. Currently I am trying to gradually generalize driver loading in Wine. Then I hope to add loading drivers as USB devices are plugged in. Then add libusb support. Then actually add basic USB I/O. Then get ReadFile/WriteFile working for drivers. And even then, there's still higher-level drivers to write (eg. USBSCAN.SYS), and many SETUPAPI.DLL bugs and features like support for class installers that have to be added before drivers will even install properly. And then we hope they don't start using too many of the unimplemented functions in NTOSKRNL.EXE.
So it's slow going and there's a lot to do, and few Wine developers seem to care. One can only hope that when some devices start working, it will generate new interest in Wine (and Linux), and Wine will get many more patches :-).
Let's win!
-Keith http://keithcu.com/
Damjan