Glitch-free iTunes?

[Damjan Jovanovic]

On Sun, Jul 3, 2011 at 4:49 AM, Keith Curtis <keithcu at 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