Hello all, What's the story with wine on intel os x? It's barely mentioned in the wine wiki and on the darwine website (not at all on winehq). I'm under the impression darwine is concentrating on running wine on ppc/ darwin. I know codeweavers is working specifically on making wine on intel/darwin happen, however there is no status page anywhere.
Just from keeping up with the mailing list, I've gleaned that Quartz and Core Audio are being worked on, in addition to a stack alignment patch. They seem to be pretty far along, but I don't really know. Are there any other intel/darwin areas that require attention or are being worked on?
I'd like to add this info to the wine wiki. It seems odd that intel os x is sort of not officially recognized by wine, what with there being no mention of it on the download page, to do lists, or bugzilla... I know there're some politics involved, but it really should have more attention. Its existence is practically not even recognized by wine. At the least, that's turning away potential wine developers, and the thing is, the mac community could be all about wine with a little effort.
Thanks, Will
William Knop william.knop@gmail.com writes:
Just from keeping up with the mailing list, I've gleaned that Quartz and Core Audio are being worked on, in addition to a stack alignment patch. They seem to be pretty far along, but I don't really know. Are there any other intel/darwin areas that require attention or are being worked on?
At this point, many simple apps should probably work OK. The main problems areas that need work are exception handling (mainly because of kernel bugs) and the debugger support that essentially doesn't work at all. You'll also need to disable optimizations when building because of the gcc stack-realign bug (we need to come up with a configure check for it), and you most likely have to use an x.org X server because the Apple one has some serious bugs in rootless mode.
So it's not quite ready for prime time yet. We are hoping to have binary packages on WineHQ in the near future, that should make it somewhat easier to get things going.
On 6/26/06, Alexandre Julliard julliard@winehq.org wrote:
At this point, many simple apps should probably work OK. The main problems areas that need work are exception handling (mainly because of kernel bugs) and the debugger support that essentially doesn't work at all. You'll also need to disable optimizations when building because of the gcc stack-realign bug (we need to come up with a configure check for it), and you most likely have to use an x.org X server because the Apple one has some serious bugs in rootless mode.
Alright, so this is what I've got so far:
Overall Status: Simple applications should work.
Notes: Make sure to disable gcc optimizations when building since gcc has a stack realignment bug. Also, Apple's X11 has serious bugs in rootless mode, so x.org's X11 may be necessary.
Tasks: Quartz Driver: works Core Audio Driver: works 16 Byte Stack Alignment: work in progress Mach Kernel Workarounds and Exception Handling: needs a lot of work Debugger: does not work
Anything to add or correct?
Thanks, Will
Hi William,
On 6/26/06, William Knop william.knop@gmail.com wrote:
Quartz Driver: works
Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq.
The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also....
Yeah, a wiki page for the Quartz driver would be nice. There are a couple implementations floating around, some using QuickDraw and some using CoreGraphics. Most have endian bugs, since they were written with Darwine/PPC in mind. As far as which is best, it seems to be that QD is easiest, but it's a deprecated API.
I think I'd use CG if I decided to sit down and write it, which I might do. I've got some free time, and in a week or so I'll have access to an intel mac for development. Thoughts on CG? Alexandre?
Will
On 6/26/06, Steven Edwards winehacker@gmail.com wrote:
Hi William,
On 6/26/06, William Knop william.knop@gmail.com wrote:
Quartz Driver: works
Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq.
The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also....
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
After looking at Darwine's quartzdrv, it looks like it uses CoreGraphics.
On 6/26/06, William Knop william.knop@gmail.com wrote:
Yeah, a wiki page for the Quartz driver would be nice. There are a couple implementations floating around, some using QuickDraw and some using CoreGraphics. Most have endian bugs, since they were written with Darwine/PPC in mind. As far as which is best, it seems to be that QD is easiest, but it's a deprecated API.
I think I'd use CG if I decided to sit down and write it, which I might do. I've got some free time, and in a week or so I'll have access to an intel mac for development. Thoughts on CG? Alexandre?
Will
On 6/26/06, Steven Edwards winehacker@gmail.com wrote:
Hi William,
On 6/26/06, William Knop william.knop@gmail.com wrote:
Quartz Driver: works
Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq.
The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also....
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
-
Alexandre Julliard -
Steven Edwards -
William Knop