Keith wrote:
http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my_... Can you make a goal of supporting iTunes with no glitches? ... Just this one app could be huge for Linux on the desktop.
The main problem is driver support, I think (mainly usb, but probably also cd-r).
There is some work on usb support going on; see http://wiki.winehq.org/USB I haven't tried that myself. (Has anyone tried this with iTunes yet?) According to $ winedump -j import ~/".wine/drive_c/Program Files/Common Files/Apple/Mobile Device Support/Drivers/usbaapl.sys" | grep offset offset 00009250 ntoskrnl.exe offset 00009264 HAL.dll offset 00009278 WMILIB.SYS offset 0000928c USBD.SYS support for wmilib.sys might need to be added for this app.
And I suspect the pcworld guy was using an outdated version of wine (given the problems he reported with the package manager ui).
Otherwise, current iTunes seems to be working reasonably well in current wine. I just downloaded and installed iTunes 10.3.1 with wine-1.3.23. I did have to set win7 mode, and I do have to click through one dialog saying it won't be able to burn cd's, but I can use the iTunes store to search for movies and play their trailers nicely; I can listen to internet radio or a local .mp3 for 5-10 minutes with no hint of trouble.
So: yeah, we know it's an important app. But it's hard. Feel free to help out. - Dan
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.
Let's win!
-Keith http://keithcu.com/
On 7/2/11 7:49 PM, Keith Curtis 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.
Keith:
Maybe you missed Dan's point. iTunes, for a while, did work. Most of the work to get it to work has been by volunteers and it remains up to the volunteer side of the project to 'make it so'. Syncing an iPod did work as far as I knew using the USB device patches. Also, this is, mainly, an all-volunteer effort. I, for instance, picked up three richedit functions that are very near and dear to the functioning of several programs that I use. There is a long known work-around, but I would like to see appropriate code included in the Wine project so that the work-around is no longer needed.
iTunes on the Linux platform may or may not be forthcoming. Making iTunes work on any flavor/distribution of Linux might take a very interested and talented user with programming skills in 'c' to generate the code and get appropriate fixes made in the Wine code. Attempts have been made and some successes gained, but more needs to be done and mostly by a small staff of volunteers.
Project priorities might say 'make this work' but without appropriately interested and skilled volunteers, iTunes might not be working under Linux anytime soon.
James McKenzie
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
On Sun, Jul 3, 2011 at 1:37 AM, Damjan Jovanovic damjan.jov@gmail.comwrote:
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.
Hi Damjan et al;
I don't know much about the USB architecture as my contributions to Windows were via RichEdit. I just know that the Linux kernel has mature USB support, WINE in general does many things, and you've got a big team now. Your contributor list shows 1250 and you've got 2M lines of code. I'm amazed at how many things work -- or almost work.
If you had a leaky roof in a house on fire, what would you work on first? It appears from the outside that the answer for WINE would be random.
In general, people can work where they want, but it is better if some work is prioritized. You don't need to use the buglist for this. When Linus finds a bug he needs fixed before he can make a release, he posts to the LKML and all the developers read it and the relevant ones respond. Typically he reverts, but sometimes he requests help, and he gets it within hours. He doesn't wait for someone to check in code that works.
You don't have to work like that. I am just pointing out that if you have goals (do not ship without certain apps working) or priorities (certain bugs are higher priority), or something, things will be better for the same amount of effort.
Regards,
-Keith http://keithcu.com/
On Mon, Jul 4, 2011 at 04:44, Keith Curtis keithcu@gmail.com wrote:
<...>
In general, people can work where they want, but it is better if some work is prioritized.
Well indeed volunteers work where they want, but also on the parts they're good at (not everybody is interested, and if they're are, they can lack the expertise in that domain). If you try to force contributors to work on something they don't like (or refuse work on sthg else), they generally won't agree, and probably even stop contributing altogether. Now it's probably different for codeweavers employees, and I'm sure they have priorities, but they don't necessarily match yours.
You don't need to use the buglist for this. When Linus finds a bug he needs fixed before he can make a release, he posts to the LKML and all the developers read it and the relevant ones respond. Typically he reverts, but sometimes he requests help, and he gets it within hours. He doesn't wait for someone to check in code that works.
This isn't about a random bug. IIRC you were basically talking about adding USB support which, as Damjan pointed out, needs a lot of work to be complete.
<...> Regards,
-Keith http://keithcu.com/
Just my 2 ¢
Frédéric
Hi Keith,
WINE in general does many things, and you've got a big team now. Your contributor list shows 1250 and you've got 2M lines of code.
Few of these contributors remain active. Most had small contributions. The total number of contributors obviously can only increase over time, but the number of active contributors has always remained small.
But really, what are we talking about? Talk is cheap. Code isn't. Your contributions are welcome. --Juan
On 4 July 2011 15:32, Juan Lang juan.lang@gmail.com wrote:
But really, what are we talking about? Talk is cheap. Code isn't. Your contributions are welcome.
In principle yes, but having worked for Microsoft complicates that a bit.
"Damjan" == Damjan Jovanovic damjan.jov@gmail.com writes:
Damjan> So it's slow going and there's a lot to do, and few Wine Damjan> developers seem to care. One can only hope that when some Damjan> devices start working, it will generate new interest in Wine Damjan> (and Linux), and Wine will get many more patches :-).
Damjan,
do you have a GIT tree to test with some easily available device to play with and some rmearks what to expect and what to expect not?
Lowering the entry barriere might help finding additional interest...
Bye
On Sat, Jul 16, 2011 at 2:38 PM, Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de wrote:
"Damjan" == Damjan Jovanovic damjan.jov@gmail.com writes:
Damjan> So it's slow going and there's a lot to do, and few Wine Damjan> developers seem to care. One can only hope that when some Damjan> devices start working, it will generate new interest in Wine Damjan> (and Linux), and Wine will get many more patches :-).
Damjan,
do you have a GIT tree to test with some easily available device to play with and some rmearks what to expect and what to expect not?
Lowering the entry barriere might help finding additional interest...
Bye
-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
When I have a Git tree that does something interesting, I will post back.
Damjan