Hi,
I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
This would greatly improve Wine on Mac as we could have native Mac fonts handling that's faster than FreeType, Dock icons for Wine applications, and few others. There's still old copy of the it hanging around, but it is abandoned, and no longer compiles with Wine.
Or I think it would be cool to write new winecocoa.drv or sthing like that, as Apple officially states that Carbon is deprecated.
While it is not well documented, it is pretty easy with Cocoa to make console non-bundled process to be UI foreground process and handle events and Dock: (This code is copyrighted by myself ;P)
int main(int argc, const char * argv[]) { ProcessSerialNumber psn = {0, kCurrentProcess}; OSStatus returnCode = TransformProcessType(&psn, kProcessTransformToForegroundApplication); SetFrontProcess(&psn);
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; [NSApplication sharedApplication]; NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"]; [NSApp setApplicationIconImage:icon]; [NSApp finishLaunching]; NSWindow *window = [[NSWindow alloc]initWithContentRect:NSMakeRect(0, 0, 100, 100) styleMask:NSTitledWindowMask| NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask backing:NSBackingStoreBuffered defer:NO]; [window center]; [window setTitle:@"Test"];
NSButton *button = [[NSButton alloc]initWithFrame:NSMakeRect(10, 10, 80, 80)]; [button setTitle:@"What?"]; [button setBezelStyle:1]; [[window contentView] addSubview:button]; [button release];
[window makeKeyAndOrderFront:NSApp]; while(1) { NSEvent *event = [NSAppnextEventMatchingMask:NSAnyEventMask untilDate :[NSDate distantFuture] inMode:NSDefaultRunLoopMode dequeue:YES ]; if(event) [NSApp sendEvent:event]; } [pool release]; return 0; }
BTW. I heard that someone previously working for Wine project is now in Apple, it is true?
Regards,
Am Sonntag, 2. März 2008 18:14:45 schrieb Adam Strzelecki:
I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
I think everyone would greatly welcome efforts to continue it, and in fact Steven Edwards is currently trying to bring the old driver up to date.
So the short answer: We accept (well written) patches!
The long answer: This isn't an easy undertaking. For one part, Wine's display driver model(how gdi32, user32, opengl32 and d3d talk to winex11.drv) still needs a bit of cleanup, currently some abstraction layers are at the wrong place. The other issue is that *a lot* of implicit knowledge is encoded in winex11.drv. To add to this, the gain of a native quartz/cocoa/whatever driver is rather limited:
* Faster font handling: Maybe, although I personally never had an app that had font performance problems. My view is rather limited though * Dock integration: Crossover has that, despite using winex11.drv. This is an entirely different story and comes down to the different ideas what an "Application" is at user interface level.
What we would gain: * No mess with X11 servers. Apple's X11 is rather broken. No Exposé headbanging with quartz_wm. No messing with Apple X11's opengl * No need for a DIB engine on MacOS. MacOS can give us everything we need. * No troubles with relative mouse movements, like we have them on X11 even on Linux
Hi,
On Sun, Mar 2, 2008 at 12:50 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 2. März 2008 18:14:45 schrieb Adam Strzelecki:
Do you guys think about reviving winequartz.drv?
I think everyone would greatly welcome efforts to continue it, and in fact Steven Edwards is currently trying to bring the old driver up to date.
There is a public branch where the Wine quartzdrv will go even if its not accepted in to Winehq. I have been from time to time bringing in infrastructure changes from the old winequartzdrv however the current tree is empty as the developer of the prior editions, Emmanuel Maillard, is in the process of overhauling it from recent changes to the Wine driver model.
Keep an eye on
http://wiki.winehq.org/MacOSX/QuartzDriver
And hopefully in the next few weeks we will have a newer patch in the winequartzdrv tree for a more recent version of Wine. I am not sure what design changes Emmanuel is wanting to make but hopefully they will be more to Alexandre's liking and can eventually go in to normal winehq. If you want to work on quartzdrv with Emmanuel, send him an email to get an idea of what he needs and what the design will be, then apply for write access to http://repo.or.cz and I will add you to the winequartzdrv branch.
Keep an eye on http://wiki.winehq.org/MacOSX/QuartzDriver
Oh, that's awesome! How did I missed this.
And hopefully in the next few weeks we will have a newer patch in the winequartzdrv tree for a more recent version of Wine. I am not sure what design changes Emmanuel is wanting to make but hopefully they will be more to Alexandre's liking and can eventually go in to normal winehq. If you want to work on quartzdrv with Emmanuel, send him an email to get an idea of what he needs and what the design will be, then apply for write access to http://repo.or.cz and I will add you to the winequartzdrv branch.
There're very neat Wine Mac builds made on http://www.kronenberg.org/darwine/ Do you have contact with the maintainer? I believe you can work out great Mac distro together especially once quartz is ready.
Cheers,
Keep an eye on http://wiki.winehq.org/MacOSX/QuartzDriver
Oh, that's awesome! How did I missed this.
I know, I didn't looked there for over month, and it was recently updated. I keep my fingers crossed for QuartzDriver!
Good night,
"Adam Strzelecki" ono@java.pl wrote:
There're very neat Wine Mac builds made on http://www.kronenberg.org/darwine/ Do you have contact with the maintainer? I believe you can work out great Mac distro together especially once quartz is ready.
"Neat" is what sense? It's not clear what additional functionality they provide, what's the status of quartz.drv in their sources, and why they don't send patches to WineHQ. Besides that sites claims that "Darwine and wine are released under the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
"Dmitry Timoshkov" dmitry@codeweavers.com wrote:
There're very neat Wine Mac builds made on http://www.kronenberg.org/darwine/ Do you have contact with the maintainer? I believe you can work out great Mac distro together especially once quartz is ready.
"Neat" is what sense? It's not clear what additional functionality they provide, what's the status of quartz.drv in their sources, and why they don't send patches to WineHQ.
The following notice in the upper right corner on that site makes it clear why :-)
"Bevore You install, please make sure: Tiger users: install X11 from your Tiger Installation DVD"
On Sun, Mar 2, 2008 at 10:00 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Neat" is what sense? It's not clear what additional functionality they provide, what's the status of quartz.drv in their sources, and why they don't send patches to WineHQ. Besides that sites claims that "Darwine and wine are released under the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
Dude chill with the hostility. Winehq currently provides no functionality for Mac users...see here
http://www.winehq.org/site/download
No one is currently offering officially blessed Winehq builds whenever Alexandre tags a release. There is no need in anyone to send patches to Winehq for code that we know Julliard is going to reject. He stated it to us during the Mac discussion at Wineconf in Redding that he viewed Darwine as a separate project and should do its only bundling. Basically anything done in Objective C he does not want in the tree which includes half of the current winequartzdrv, the Darwine launcher and Doc code and just about everything else.
If you want to review a patch, look at the patch for 0.9.48
http://sourceforge.net/tracker/?group_id=69890&atid=526089
And help further abstract user32/x11drv like has been done for Window creation and Window positioning.
"Steven Edwards" winehacker@gmail.com wrote:
On Sun, Mar 2, 2008 at 10:00 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Neat" is what sense? It's not clear what additional functionality they provide, what's the status of quartz.drv in their sources, and why they don't send patches to WineHQ. Besides that sites claims that "Darwine and wine are released under the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
Dude chill with the hostility.
I have no idea why you're treating asking the questions as a "hostility". This is the developers list, not the list for user complaints. Sending the patches is a usual activity here, not vague reasoning.
Winehq currently provides no functionality for Mac users...see here
http://www.winehq.org/site/download
No one is currently offering officially blessed Winehq builds whenever Alexandre tags a release.
Feel free to provide/suggest one.
There is no need in anyone to send patches to Winehq for code that we know Julliard is going to reject. He stated it to us during the Mac discussion at Wineconf in Redding that he viewed Darwine as a separate project and should do its only bundling. Basically anything done in Objective C he does not want in the tree which includes half of the current winequartzdrv, the Darwine launcher and Doc code and just about everything else.
If you want to review a patch, look at the patch for 0.9.48
http://sourceforge.net/tracker/?group_id=69890&atid=526089
And help further abstract user32/x11drv like has been done for Window creation and Window positioning.
Aren't you supposed to work on that according to http://wiki.winehq.org/MacOSX/QuartzDriver?
Looks like you overreacted, http://www.kronenberg.org/darwine/ has nothing to do with darwine except using its name.
Dmitry Timoshkov wrote:
Looks like you overreacted, http://www.kronenberg.org/darwine/ has nothing to do with darwine except using its name.
Actually, I have Mike's code and it uses the Darwine build system and applies two patches to it. One brings in FontForge so that Apple Native fonts will work in Wine, and this is discussed on the Building Wine for MacOSX web page. The other fixes a known problem for Leopard's handling of screen location (it does not always use :0.0 for security reasons). I will suggest that he bring back into the Darwine project his fixes. I think he already has tried but received no response from the Project.
As to the rest, AJ has stated, repeatedly, that he wants no Obj-C in the Wine tree. This prevents bringing in some Mac specific code, and completely eliminates the winequartz.drv project. I'm not going to argue with his reasoning, but this forces a Native version of Wine to be a continuous fork with fixes in Wine requiring fixes (if winex11.drv is changed) in the code.
As to support for the Mac, I have been doing what some Mac users are doing now: Building my own. Unfortunately, I do not have a place to put my builds where the public can download them. Also, they contain code that has not been approved for the main Wine build and may contain 'dangerous' code. I'm willing to risk my system's stability to test, but not others.
James McKenzie
Any developer that wants to maintain source and/or binaries on the Darwine project at SF.net is welcome to do so.
I have responded to every such request that I have seen, which isn't to say of course that someone hasn't sent such a message that I haven't seen. Folks should be aware that you must subscribe to the list to post (although I do manually review posts from non-subscribers and try to put through any that are actually about Darwine and not male enhancement or get rich quick...). It is true that questions from users trying to run application X may not get much help other than being told Darwine isn't ready for end users.
Of course folks are also welcome to host their own builds, and I'd be happy if someone came along and just fixed the web site (which suffered greatly in the move back to SF.net from opendarwin.org - I didn't want to leave SF.net in the first place...), so we could point other folks to those builds.
It was never my intention that Darwine be a fork of Wine, but rather a friendly haven for Mac developers working on Wine. If that means doing more for users such as hosting binaries, then I'm fine with that too.
Geeze. I just looked at the download stats and folks are pulling almost 300 copies a day (nearly 7GB). It would be nice if they were using that bandwidth to get something useful...
Jim White http://darwine.sf.net/
James McKenzie wrote:
Dmitry Timoshkov wrote:
Looks like you overreacted, http://www.kronenberg.org/darwine/ has nothing to do with darwine except using its name.
Actually, I have Mike's code and it uses the Darwine build system and applies two patches to it. One brings in FontForge so that Apple Native fonts will work in Wine, and this is discussed on the Building Wine for MacOSX web page. The other fixes a known problem for Leopard's handling of screen location (it does not always use :0.0 for security reasons). I will suggest that he bring back into the Darwine project his fixes. I think he already has tried but received no response from the Project.
As to the rest, AJ has stated, repeatedly, that he wants no Obj-C in the Wine tree. This prevents bringing in some Mac specific code, and completely eliminates the winequartz.drv project. I'm not going to argue with his reasoning, but this forces a Native version of Wine to be a continuous fork with fixes in Wine requiring fixes (if winex11.drv is changed) in the code.
As to support for the Mac, I have been doing what some Mac users are doing now: Building my own. Unfortunately, I do not have a place to put my builds where the public can download them. Also, they contain code that has not been approved for the main Wine build and may contain 'dangerous' code. I'm willing to risk my system's stability to test, but not others.
James McKenzie
James McKenzie wrote:
As to the rest, AJ has stated, repeatedly, that he wants no Obj-C in the Wine tree. This prevents bringing in some Mac specific code, and completely eliminates the winequartz.drv project. I'm not going to argue with his reasoning, but this forces a Native version of Wine to be a continuous fork with fixes in Wine requiring fixes (if winex11.drv is changed) in the code.
That means no good for Mac users. With Leopard release Carbon (pure C) is more-less deprecated API, Apple pushes all new functionality only to Obj-C Cocoa, also there's is no 64-bit Carbon at all. I don't want to argue what's wrong with Obj-C that it cannot go into Wine code-base, but staying out of it won't ever bring full Wine support for Mac users.
Dmitry Timoshkov wrote:
This is the developers list, not the list for user complaints. Sending the patches is a usual activity here, not vague reasoning.
That's bizarre, but OK, every society has its own rules. I raised here subject about implementation (or call it development) of some Wine module (winequartz.drv), so I thought it is more adequate to post it here, but if you call it user complaint alright, this list is "sending patches" (even I thought wine-patches is the one) I cut this chit-chat.
On Sun, Mar 2, 2008 at 10:45 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
I have no idea why you're treating asking the questions as a "hostility". This is the developers list, not the list for user complaints. Sending the patches is a usual activity here, not vague reasoning.
Sorry I misread one of your statements. There is no point in sending the patches when we already know they are going to be rejected.
Feel free to provide/suggest one.
There is a script posted here to make it less of a hassle to build a stock Winehq release on OS X.
http://www.wine-forum.org/showthread.php?t=16
I'm happy to start making builds of Winehq snapshots for OS X. I just don't see the point when the Darwine packages are better for the end user experience. With Winehelper you get Doc integration and a partial menu system. The stock X.org on OS X is broken and has inherit overhead that will always be present, being able to write directly to the native Windowing system seems like a much more logical long term solution rather than trying to keep Xorg from breaking and or developing hacks to work around X and its tricky interaction with Quartz.
Aren't you supposed to work on that according to http://wiki.winehq.org/MacOSX/QuartzDriver?
I have been but I've put my work on it on hold pending a new round of patches from Emmanuel. My point was that you asked for patches, there is one for your pleasure. I welcome your thoughts and I am sure Emmanuel does as well. I know Pierre seemed to get disappointed when he wanted to develop quartzdrv in winehq but could not get a clear idea of what Julliard really wanted. What do you want/think quartzdrv in winehq should look like? How should it be implemented? What infrastructure changes should be made?
Looks like you overreacted, http://www.kronenberg.org/darwine/ has nothing to do with darwine except using its name.
Sorry like I said I mis-read the other email. My point was that it does not seem that anyone wants to provide real solutions. I don't think Emmanuel or Pierre really knew what Julliard wants in Quartzdrv. I don't know know what you want in it. I know there is a certain level of abstraction that needs to be done in user32 and I was glad to see Julliard started working on it, thats what made me interested in bringing some life back in to quartzdrv. It would be nice if those people that are the experts on the Wine driver model would speak up and say would needs to be done before we can have this driver.
"Steven Edwards" winehacker@gmail.com wrote:
I have been but I've put my work on it on hold pending a new round of patches from Emmanuel. My point was that you asked for patches, there is one for your pleasure. I welcome your thoughts and I am sure Emmanuel does as well. I know Pierre seemed to get disappointed when he wanted to develop quartzdrv in winehq but could not get a clear idea of what Julliard really wanted. What do you want/think quartzdrv in winehq should look like? How should it be implemented? What infrastructure changes should be made?
Alexandre has moved a lot of things to user32 that previously were needed to be implemented on the driver side (SetWindowPos, ShowWindow, DCE) which should greatly simplify the quartzdrv efforts.
Hi,
I post a new quartzdrv patch for wine-0.9.56 on Darwine SF patches page : http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gro...
It's not fully update to wine changes (SysCommandSizeMove didn't be reviewed) and don't contain all changes I initially planned but will be next time.
Cheers
Emmanuel
Le 2 mars 08 à 19:53, Steven Edwards a écrit :
Hi,
On Sun, Mar 2, 2008 at 12:50 PM, Stefan Dösinger <stefan@codeweavers.com
wrote: Am Sonntag, 2. März 2008 18:14:45 schrieb Adam Strzelecki:
Do you guys think about reviving winequartz.drv?
I think everyone would greatly welcome efforts to continue it, and in fact Steven Edwards is currently trying to bring the old driver up to date.
There is a public branch where the Wine quartzdrv will go even if its not accepted in to Winehq. I have been from time to time bringing in infrastructure changes from the old winequartzdrv however the current tree is empty as the developer of the prior editions, Emmanuel Maillard, is in the process of overhauling it from recent changes to the Wine driver model.
Keep an eye on
http://wiki.winehq.org/MacOSX/QuartzDriver
And hopefully in the next few weeks we will have a newer patch in the winequartzdrv tree for a more recent version of Wine. I am not sure what design changes Emmanuel is wanting to make but hopefully they will be more to Alexandre's liking and can eventually go in to normal winehq. If you want to work on quartzdrv with Emmanuel, send him an email to get an idea of what he needs and what the design will be, then apply for write access to http://repo.or.cz and I will add you to the winequartzdrv branch.
-- 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
Hi,
On Thu, Mar 6, 2008 at 9:08 AM, Emmanuel Maillard mahanuu@free.fr wrote:
I post a new quartzdrv patch for wine-0.9.56 on Darwine SF patches page : http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gro...
It's not fully update to wine changes (SysCommandSizeMove didn't be reviewed) and don't contain all changes I initially planned but will be next time.
It looks really good. With the most recent changes I can start Office 2003 applications such as Excel and Winword
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel2.png http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel3.png http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel4.png http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel5.png http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/winword.png
The only problem I have is that the windows are not being managed. It looks like MainMenu.nib is not being created properly by the patch/script. Is this a known issue or is that SysCommandSizeMove problem?
Emmanuel Maillard wrote:
Hi,
I post a new quartzdrv patch for wine-0.9.56 on Darwine SF patches page : http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gro...
It's not fully update to wine changes (SysCommandSizeMove didn't be reviewed) and don't contain all changes I initially planned but will be next time.
Cheers
Emmanuel
Thank you. I also noticed there are new .nib files available.
James McKenzie
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective-C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
Regards,
2008/7/4 Adam Strzelecki ono@java.pl:
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
Someone needs to do the work to resolve the conflicts that you just mentioned. Do you expect that to just magically happen with no work?
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective-C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective.
While I don't know how complete the code is or how well it work, once a reasonable set of applications work the same or better with winequartz.drv as they do with winex11.drv then there will likely be enough demand to overcome the objection or an alternative solution will be found.
Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Huh?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard.
Oh yeah, sure...
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
And that is why your conspiracy theory is complete and utter rubbish - because CodeWeavers would get many more customers with a working quartz driver. The real reasons are technical. If they weren't then you would already find CrossOver 7.0 shipping with winequartz.drv, which it doesn't.
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective- C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective- C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
Regards,
Adam Strzelecki |: nanoant.com :|
Cheers Emmanuel
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
Good to read from you.
I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too.
Please contact me off-list when this is complete. I would like to get this into Darwine and see what needs to be fixed. I would like to see Darwine become a more complete Mac application and to leave X11 behind. Not that the current program is not complete, but Mac users tend to not like to look at and use X11 based applications.
I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)
The rumor was that OpenGL was broken in Mac OS X and not in winequartz.drv. Thank you for the clarification.
I for one, support your ongoing efforts to support the Quartz interface for Mac OS X applications, like Wine.
James McKenzie
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective- C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective- C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
Regards,
Adam Strzelecki |: nanoant.com :|
Cheers Emmanuel
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch was for 1.1.2.
James McKenzie
Le 3 janv. 09 à 04:14, James McKenzie a écrit :
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective- C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective- C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
Regards,
Adam Strzelecki |: nanoant.com :|
Cheers Emmanuel
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch was for 1.1.2.
James McKenzie
Hi,
I didn't really work on winequartz.drv since this patch, start a new version at the beginning of October, but more or less waiting for DIB engine.
Emmanuel
Emmanuel Maillard wrote:
Le 3 janv. 09 à 04:14, James McKenzie a écrit :
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective- C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective- C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
Regards,
Adam Strzelecki |: nanoant.com :|
Cheers Emmanuel
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch was for 1.1.2.
James McKenzie
Hi,
I didn't really work on winequartz.drv since this patch, start a new version at the beginning of October, but more or less waiting for DIB engine.
Emmanuel
Well, I hope your wait will not be long for the DIB engine.
I await the next winequartz.drv release and will keep checking here.
James McKenzie
Comments on Adam's message
Adam Strzelecki wrote:
Hi Emmanuel, hello Wine developers,
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
Mac OS X support is really not on the radar, from what I can determine. Remember the original goal of Wine was to allow Windows programs to run on a Windows API for Linux and UNIX. Mac OSX switched from a proprietary system to FreeBSD/OpenBSD after the project started. Also add that a parallel project was started to allow Windows32s programs to run on OS/2.
I know Alexandre Julliard's decision about NOT taking any Objective-C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective-C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective.
There are several reasons why ObjC code is not allowed in the Wine project. First, the code cannot be examined by Alexandre. He does not have the desire to build it. I don't know if he does or does not own a Mac. The second is that Wine is and continues to be written in 'c'. ObjC code may cause problems with 'straight' c compilers, like those that are included with Linux. This happens even if ObjC code is wrapped in selection statements as the compiler must 'read' through all of the code. Thus, all Mac specific code has to reside outside of the main Wine project. I highly recommend that we revive the Darwine project and place Emmanuel's and others code into this project's add-on code. We can also help with the PowerPc to X86 emulator that is needed by the older processors to properly work with X86 code.
Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source?
Because there may be additional code to support the Windows GUI framework, which is within the scope of the Wine project. One purpose of Wine is to emulate the API of an older version of Windows without the need to have virtual machines.
Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard.
Maybe this could be further queried as: "What is CodeWeaver's offical stance on supporting a Mac OS X native user interface when the code becomes stable and supportable?" and "Would CodeWeavers consider bringing Emmanuel on as a paid employee at that time to ensure that the code is maintained?"
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system.
I would also do such a thing, even if it were in the future plans of CodeWeavers. I would like to see a more programs be given a native Mac OS X GUI 'wrapper'. However, this may take years (as in the OpenOffice.org and NeoOffice.org projects) or be found not practical; this is the case for several projects. Keep in mind that what we want may not be possible or financially reasonable.
James McKenzie
On Fri, Jul 4, 2008 at 5:43 PM, James McKenzie jjmckenzie51@sprintpcs.com wrote:
Maybe this could be further queried as: "What is CodeWeaver's offical stance on supporting a Mac OS X native user interface when the code becomes stable and supportable?" and "Would CodeWeavers consider bringing Emmanuel on as a paid employee at that time to ensure that the code is maintained?"
I can't speak for CodeWeavers, being a former employee now running a competing business but I plan on looking at the new 1.0 Quartzdrv and if the performance is acceptable (it was not in prior versions), building a custom version of Bordeaux for OS X. Not that I expect it to make much money, Bordeaux for Linux has not brought in that much yet, but if it does, I'm willing to try to help fund development.
Steven Edwards wrote:
On Fri, Jul 4, 2008 at 5:43 PM, James McKenzie jjmckenzie51@sprintpcs.com wrote:
Maybe this could be further queried as: "What is CodeWeaver's offical stance on supporting a Mac OS X native user interface when the code becomes stable and supportable?" and "Would CodeWeavers consider bringing Emmanuel on as a paid employee at that time to ensure that the code is maintained?"
I can't speak for CodeWeavers, being a former employee now running a competing business but I plan on looking at the new 1.0 Quartzdrv and if the performance is acceptable (it was not in prior versions), building a custom version of Bordeaux for OS X. Not that I expect it to make much money, Bordeaux for Linux has not brought in that much yet, but if it does, I'm willing to try to help fund development.
Steven:
Great. I would like to see more development work with Emmanuel's work. Of course, Emmanuel's code will never be incorporated into the main Wine master because it contains ObjC code.
James McKenzie
Hi,
Maybe this could be further queried as: "What is CodeWeaver's offical stance on supporting a Mac OS X native user interface when the code becomes stable and supportable?" and "Would CodeWeavers consider bringing Emmanuel on as a paid employee at that time to ensure that the code is maintained?"
We are very interested in Wine having a more native OS X interface.
However, our analysis is that the task is difficult and will require a long time to stabilize and get right. I am excited by and interested in Emmanuel's work, but I am told not to be too excited, that it's not a magic bullet, and that the bulk of the hard work is still ahead.
We have a long history of hiring proven Wine developers and thereby sponsoring their work. We do that as much as our income will allow, gated by peoples ability and willingness to work with us.
To answer the seemingly implied question: "Are we deliberately crippling Wine for Mac OS X to serve our own nefarious ends", the answer is no. That's in no small part because our main nefarious end is to improve Wine :-).
Did we make a decision to focus on an X11 based solution for Mac OS X? Yes, for the time being. The advantages are that it's here now, works now, and that most of what we do now also benefits Linux and other platforms. The disadvantage, apparently, is that people suspect us of all kinds of nefarious plots...
And, on a final note, just so its clear: the contract between CodeWeavers and Alexandre is very explicit: CodeWeavers gets *no* say in what does or does not go into Wine. We probably curse his decisions as much or more than any Wine developer, and whether or not Objective C
Cheers,
Jeremy
We probably curse his decisions as much or more than any Wine developer, and whether or not Objective C
*blush* Teach me to send email late at night on a foreign computer.
The point is that CodeWeavers has no control over whether or not Emmanuel's code goes into Wine. That's entirely Alexandre's decision.
Cheers,
Jeremy
We are very interested in Wine having a more native OS X interface. However, our analysis is that the task is difficult and will require a long time to stabilize and get right. I am excited by and interested in Emmanuel's work, but I am told not to be too excited, that it's not a magic bullet, and that the bulk of the hard work is still ahead.
But it is fairy complete, since a long while. It lays in the front of your eyes so why don't put it into the Wine's repository, as it is the most obvious way for the others to polish and stabilize it.
We have a long history of hiring proven Wine developers and thereby sponsoring their work. We do that as much as our income will allow, gated by peoples ability and willingness to work with us.
Look, I don't think you need to hire anybody. There're numerous talented developers as Emmanuel or Mike that did great Wine packaging at kronenberg.org that would help to put all the code together. I shouldn't speak for them, but just note that both of them do all their work already for free. I'm willing to help too, I'd be happy if I could send some patches improving Mac support.
To answer the seemingly implied question: "Are we deliberately crippling Wine for Mac OS X to serve our own nefarious ends", the answer is no. That's in no small part because our main nefarious end is to improve Wine :-).
Very well, my previous mail was intentionally perversive just to cheer up everybody for Mac discussion.
Did we make a decision to focus on an X11 based solution for Mac OS X? Yes, for the time being. The advantages are that it's here now, works now, and that most of what we do now also benefits Linux and other platforms. The disadvantage, apparently, is that people suspect us of all kinds of nefarious plots...
Well it would be me then :) So why just not put Emmanuel's work into Wine repository, while there're lot of other incomplete modules. Let's give it a chance.
And, on a final note, just so its clear: the contract between CodeWeavers and Alexandre is very explicit: CodeWeavers gets *no* say in what does or does not go into Wine. We probably curse his decisions as much or more than any Wine developer, and whether or not Objective C
(...)
The point is that CodeWeavers has no control over whether or not Emmanuel's code goes into Wine. That's entirely Alexandre's decision.
OK, I'm sorry. I don't want to accuse anybody, I just made a false equation between Alexandre and CodeWeavers taken from About Us page. It was just said once that winequartz.drv won't go into official Wine, and the top reason was Objective-C and this was just a bizarre decision for me. Objective-C is almost as old as C++ and it was just chosen for an object model of OSX (NextStep previously) in opposition to pure C messaging of Windows and C++ for COM interfaces, etc. So IMHO no for Objective-C means no for decent Mac OSX support, period.
Best regards and thank you all for your replies,
On Mon, Jul 7, 2008 at 5:41 AM, Adam Strzelecki ono@java.pl wrote:
OK, I'm sorry. I don't want to accuse anybody, I just made a false equation between Alexandre and CodeWeavers taken from About Us page. It was just said once that winequartz.drv won't go into official Wine, and the top reason was Objective-C and this was just a bizarre decision for me. Objective-C is almost as old as C++ and it was just chosen for an object model of OSX (NextStep previously) in opposition to pure C messaging of Windows and C++ for COM interfaces, etc. So IMHO no for Objective-C means no for decent Mac OSX support, period.
I don't know if having the quartzdrv in Winehq, even if was written in pure C would be a good idea. I think there is a lot of pressure on him to accept it (I've pestered him about it enough before) but he needs to be free to break the driver interface from time to time to improve it and its really forcing him to do work twice if quartzdrv and x11drv are both in the winehq repo.
I think everybody would be better served if there was a "blessed" branch or git repo that quartzdrv was maintained in, where it could be done in Objective-C or however its maintainer wanted to do it, and Winehq could recommend users wanting it to go there. If the maintainer does not do a good job keeping it stable, fast and passing all of the wine tests, Alexandre could always revoke his blessing. I created a branch on repo.or.cz to do this but it needs more attention than I've been able to give it lately. If we just accept that quartzdrv might never be merged its not a big deal. Winehq users, CodeWeavers and anyone else can still pull from it and or throw resources at it to make it better, without adding more work on Julliard.
On Mon, 7 Jul 2008, Adam Strzelecki wrote: [...]
It was just said once that winequartz.drv won't go into official Wine, and the top reason was Objective-C and this was just a bizarre decision for me. Objective-C is almost as old as C++ and it was just chosen for an object model of OSX (NextStep previously) in opposition to pure C messaging of Windows and C++ for COM interfaces, etc.
Hehe. If it can comfort you, code submissions in Cobol and Fortran would be refused too, even though these languages are older than C++. As far as I know only C is accepted for the Wine core, and for support scripts and development tools Bourne shell and Perl scripts are accepted too. There are at least three reasons for that: * The first and probably most important reason is that we want to avoid a proliferation of languages which would make it harder to compile Wine (multiple tool chains), and also harder for developpers to understand the code. Currently if you write a test or modify notepad and you get a crash in winex11, you will be able to look at the winex11 code and hopefully figure out the reason for the crash. If winex11 was written in C++ you would first have to understand C++ in order to figure things out. The same goes with an Objective-C winequartz driver. * Additional languages may also be causing trouble for winedbg. I'm not entirely sure about that one but I believe additional code is needed to properly parse the C++ debug information and thus produce proper backtraces, be able to inspect the contents of objects, etc (actually I'm not sure winedbg supports C++ right now). Adding code in Objective-C would probably entail another round of extensions. * Finally, at least for C++, there was an issue with ABI stability. It used to be that a C++ program compile with a version of g++ (e.g. 3.3) would not be able to use a C++ library compiled with an older or newer version of g++ (2.95 or 4.x). Things may have become a bit more stable on that front. Also this may not apply to Objective-C on Mac OS X (presumably Apple does not want to break all the 3rd party applications everytime they upgrade they upgrade the standard compiler).
So IMHO no for Objective-C means no for decent Mac OSX support, period.
Is it really technically impossible to access the Quartz APIs or write Mac applications using C?
Is it really technically impossible to access the Quartz APIs or write Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon (API) app AFAIK. Problem is that Carbon (pure C interface) is considered as deprecated by Apple and may disappear from future releases of OSXes at all, most 98% of applications are Objective-C Cocoa anyway. Moreover most of the functionality introduced in 10.5 or 10.4 went just into Cocoa, and never was backported to Carbon. So it isn't matter that it isn't possible, but it is IMHO more reasonable to do it in Objective-C.
Best regards,
Sorry for the lag,
* On Thu, 10 Jul 2008, Adam Strzelecki wrote:
Is it really technically impossible to access the Quartz APIs or write Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon (API) app AFAIK. Problem is that Carbon (pure C interface) is considered as deprecated by Apple and may disappear from future releases of OSXes at all, most 98% of applications are Objective-C Cocoa anyway. Moreover most of the functionality introduced in 10.5 or 10.4 went just into Cocoa, and never was backported to Carbon. So it isn't matter that it isn't possible, but it is IMHO more reasonable to do it in Objective-C.
Then what about some thunking from carbonic source code to binary Objective-C code?
Well, I have found some text [1] on the web about bridging D (not C) [2] with ObjectiveC:
| So basically, since the whole Objective-C runtime is accessible from C | calls, it’s pretty easy to do whatever we want with it.
If that's true, then some MacOSy hacker should give it a try. The bigger task here probably would be implementation of some callback stuff in C with the right calling convention / ABI (as ObjC seems to send some kind of "messages" back).
Somewhat scary part may be bridging of exception handling, but if Wine did this for WinAPI, with gobjc/libFoundation present and with Apple docs given [3] it should be doable also.
I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4]
And the last -- I found libffi for Unix-like systems which seems to be used on the MacOS X [5]:
| On Mac OS X libffi is commonly used with BridgeSupport, which provides | programming language neutral descriptions of framework interfaces, and | Nu which binds direct Objective-C access from Lisp.
HTH.
[1] http://michelf.com/weblog/2007/d-objc-bridge/ [2] http://en.wikipedia.org/wiki/D_(programming_language) [3] http://www.google.lt/search?q=+objectivec+abi+site:developer.apple.com [4] http://www.opengroupware.org/en/devs/languages/ansic/index.html [5] http://en.wikipedia.org/wiki/Libffi
Am 02.10.2008 um 20:16 schrieb Saulius Krasuckas:
- On Thu, 10 Jul 2008, Adam Strzelecki wrote:
Is it really technically impossible to access the Quartz APIs or write Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon (API) app AFAIK. Problem is that Carbon (pure C interface) is considered as deprecated by Apple and may disappear from future releases of OSXes at all, most 98% of applications are Objective-C Cocoa anyway. Moreover most of the functionality introduced in 10.5 or 10.4 went just into Cocoa, and never was backported to Carbon. So it isn't matter that it isn't possible, but it is IMHO more reasonable to do it in Objective-C.
Then what about some thunking from carbonic source code to binary Objective-C code?
While the above is correct, modern Cocoa, in opposite to it's precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation, both of which are plain C APIs. There's no need for neither Carbon nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X screen.
MarKus
- - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Refe...
While the above is correct, modern Cocoa, in opposite to it's precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation, both of which are plain C APIs. There's no need for neither Carbon nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X screen.
You are right, however what we all want to have is probably some Wine seamless integration with OSX GUI at higher level than Quartz which is just equivalent of WinGDI, and for this you need to somehow use HIToolkit of Carbon extra to do windows management, font handling etc. for example: http://developer.apple.com/documentation/Carbon/Reference/Window_Manager/Ref... /apple_ref/c/func/CreateNewWindow .. to create new window.
The problem here is that HIToolkit from Carbon is a bit pushed away by Apple in favor of Cocoa, and the reason is that Carbon has its roots in Mac OS 8, and Cocoa is the new API for Mac OS X NextStep based system, moreover there's no 64-bit HIToolkit (which doesn't matter for Wine now, but may matter in the future).
There's nice discussion here: http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=printview...
I believe if pure C source is a constraint for Wine, one should try to make winequartz.drv to be Quartz API for all WinGDI like stuff + some HIToolbox for Window management and CoreText for text display.
Regards,
Adam Strzelecki wrote:
I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Refe...
While the above is correct, modern Cocoa, in opposite to it's precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation, both of which are plain C APIs. There's no need for neither Carbon nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X screen.
You are right, however what we all want to have is probably some Wine seamless integration with OSX GUI at higher level than Quartz which is just equivalent of WinGDI, and for this you need to somehow use HIToolkit of Carbon extra to do windows management, font handling etc. for example: http://developer.apple.com/documentation/Carbon/Reference/Window_Manager/Ref... /apple_ref/c/func/CreateNewWindow .. to create new window.
The problem here is that HIToolkit from Carbon is a bit pushed away by Apple in favor of Cocoa, and the reason is that Carbon has its roots in Mac OS 8, and Cocoa is the new API for Mac OS X NextStep based system, moreover there's no 64-bit HIToolkit (which doesn't matter for Wine now, but may matter in the future).
There's nice discussion here: http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=printview...
I believe if pure C source is a constraint for Wine, one should try to make winequartz.drv to be Quartz API for all WinGDI like stuff + some HIToolbox for Window management and CoreText for text display.
Regards,
What is the status of work on this project?
James McKenzie
Adam Strzelecki wrote:
I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Refe...
Adam:
Is this still true? I would like to convert what work we do have into c level code so that it will pass AJs 'c' scan and to avoid using ObjC code.
In addition, if an exported Carbon/Cocoa library exists, this would help move the project along.
James McKenzie
On 06.07.2009, at 06:13, James McKenzie wrote:
Adam Strzelecki wrote:
I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Refe...
Adam:
Is this still true? I would like to convert what work we do have into c level code so that it will pass AJs 'c' scan and to avoid using ObjC code.
In addition, if an exported Carbon/Cocoa library exists, this would help move the project along.
James McKenzie
Hi James,
I think You don't need any ObjC at all to replace X11. Apples modern CoreGraphics API is mostly C. And OpenGL can be accessed in C anyway. There is also a C API for the window manager. I do a lot of CG programming, if you have a task for me, just drop a line ;)
There is a drawback with CG or OpenGL with Apples current APIs: Manipulating individual pixels live in the screenbuffer. This was fast & possible with the old (now depreciated & partly defunct) QuickDraw API. With Apple window server, based fully on Quartz, this API is of no use now, as the underlaying system is already fully OpenGL. The once direct access to the fb is now just as you would manipulate a texture and flush it to the viewport in OpenGL. We did a lot of testing on this topic when we changed the qemu vga output from QuickDraw to OpenGL/Quartz on OS X. We finally changed the whole output to OpenGL, as it was the fastest and most compatible with the future freely scaleable UI ideas of Apple (and others ;).
This way, all 2d pixelmanipulation is taking place in a texture and if it comes to 3d, half of the environment is already set.
Mike
James,
Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Refe...
Is this still true? I would like to convert what work we do have into c level code so that it will pass AJs 'c' scan and to avoid using ObjC code.
Those functions allow pure C code call and work on Objective-C (shortened to Obj-C later) object pointers. While it gives you possibility to write an Obj-C Cocoa based pure-C extension for Wine, IMHO this would be a nightmare. Because of few reasons: (1) You'd need to write lot more code than writing Obj-C, (2) This code would be suboptimal (Obj-C isn't translated to C, it is separate compiler), (3) You can expect lot of problems with memory allocation and freeing that is done more less automatically with Obj-C memory pools, etc.
In addition, if an exported Carbon/Cocoa library exists, this would help move the project along.
As I previously mentioned Carbon is pure-C UI/graphics library for Mac OS X that is legacy and partial compatible with older versions such as Mac OS 8 & 9. Since it is legacy, all new features doesn't go into Carbon so Carbon doesn't expose all OSX functionality, also there's no 64-bit Carbon. So, Yes you can write Wine OSX support using pure-C Carbon library, but beware that it is LEGACY and Apple doesn't recommend you to use it. Moreover it can be discontinued at some 10.x release, so all your work will be wasted.
Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is NextStep based objective oriented GUI & OS. And Obj-C is a basement of both NextStep and OSX. So if you want to write OSX GUI application properly you have to use Obj-C, same as C++ & KDE and so on.
So forcing constraint that all Wine source files have to be C is simply unreasonable in this case. You can easily achieve that only OSX dependent source files will be Obj-C, while having OS independent code to be pure-C - as C is a subset of Obj-C, and Obj-C is backwards compatible with C. So from the other OSes point of view Wine will be still pure-C program.
Cheers,
Adam Strzelecki [mailto:ono@java.pl]
Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is NextStep based objective oriented GUI & OS. And Obj-C is a basement of both NextStep and OSX. So if you want to write OSX GUI application properly you have to use Obj-C, same as C++ & KDE and so on.
With the same argument you could say that writing COM objects has to be done in C++. Yet Wine has lots and lots of COM code written all in standard C.
Agreed, writing object oriented code in C is not exactly trivial and often quite tedious and the difference with Object-C might be even bigger as it is likely using more advanced techniques.
Rolf Kalbermatter
Rolf,
See my comments below.
With the same argument you could say that writing COM objects has to be done in C++. Yet Wine has lots and lots of COM code written all in standard C.
You're wrong. COM isn't a full C++ interface, it uses/exposes limited C ++ subset - just to be C and other languages compatible. You never create a COM class instance C++ way by name (like "= new Direct3DTexture" or "Direct3DTexture tex;"), you never use ctors/ dtors, you always query/ask for GUID, your COM objects are always pointers which has to be explicitly freed. You don't link to C++ libs where are methods and class are C++ mangled using C++ lib naming.
And finally it is opposite situation, it is Wine that implements some COM interfaces, so it is you that write the COM interface and create C compatible API too.
I don't think there any place where Wine hooks to existing (external) C ++ library like QT. AFAIK wine uses C POSIX functions and Xwindow API that is pure C too.
Moreover I didn't say that wrapping Cocoa can't be done in pure-C, already said that there's a C API to call Obj-C methods etc. (look at the link below) All I say it will be a nightmare for a program that uses more than 2 classes and 10 method calls, and implementing video/GUI driver will trigger much more of them for sure.
Image, you'd need to implement Wine video driver with QT/Kde which is full C++ interface and all you get from them is C++ headers and C++ libraries. You couldn't link just to QT lib, because pure C wouldn't understand C+ + naming, you'd need to use a lot of *dlopen* & *dlsym*s, void pointers, etc.
Agreed, writing object oriented code in C is not exactly trivial and often quite tedious and the difference with Object-C might be even bigger as it is likely using more advanced techniques.
Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20... .
This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a "nightmare", or maybe "happy coding".
Regards,
On Thu, Jul 9, 2009 at 7:18 AM, Adam Strzeleckiono@java.pl wrote:
Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20....
This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a "nightmare", or maybe "happy coding".
The link seems to be malformed. Can you resend it? I am really interested in looking at this.
The link seems to be malformed. Can you resend it? I am really interested in looking at this.
http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20....
The trick, it seems, is to include the dot in the end. Interesting URL scheme(and snippet)...
//Nicklas
Steven Edwards wrote:
On Thu, Jul 9, 2009 at 7:18 AM, Adam Strzeleckiono@java.pl wrote:
Just to explain things better, I found great sample of calling Obj- C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20... .
This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a "nightmare", or maybe "happy coding".
The link seems to be malformed. Can you resend it? I am really interested in looking at this.
Link is fine, but mind the dot at the end of the link, it is a part of the link, even your mail client says it isn't. Sorry I spotted it too late once I sent this mail that Mail.app omits trailing dot when underscoring the URL.
Regards,
Adam Strzelecki wrote:
Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20....
This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a "nightmare", or maybe "happy coding".
Ugly, but if this will work, it works. I don't like code obfusicusion just to have it there. I like clean, commented, understandable code. Unfortunately, we have to stick with c/C++ code here.
I'm wondering if there is a C++ to ObjC library interface that would be cleaner.
James McKenzie
I'm wondering if there is a C++ to ObjC library interface that would be cleaner.
Never encountered any. I doubt it is possible since Obj-C is dynamically typed (binded) language, which means you can pass any kind of msg to any kind of obj and it will compile/run. Either you will receive an "method not found" exception or "nil" as return. It is very close to what Ruby is. Actually both Ruby & ObjC as based on Smalltalk idea.
Of course there's wxWidgets for example which wraps Cocoa as one of its backends, but the wrapper is C++ & ObjC mixture.
I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/ Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac.
Regards,
Adam Strzelecki wrote:
Never encountered any. I doubt it is possible since Obj-C is dynamically typed (binded) language, which means you can pass any kind of msg to any kind of obj and it will compile/run. Either you will receive an "method not found" exception or "nil" as return. It is very close to what Ruby is. Actually both Ruby & ObjC as based on Smalltalk idea.
Now I understand. It is very interesting that Obj-C is based upon something that I actually have an idea of how it works...
Of course there's wxWidgets for example which wraps Cocoa as one of its backends, but the wrapper is C++ & ObjC mixture.
I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux.
Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers.
James McKenzie
On Sat, Jul 11, 2009 at 4:21 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Adam Strzelecki wrote:
I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux.
What problems are you referencing?
Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers.
No, I don't have one. I have ssh access to one, but that's it. I'd like to see more testing done on the Mac, but until I get one personally, that won't happen for a while.
Austin English wrote:
On Sat, Jul 11, 2009 at 4:21 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Adam Strzelecki wrote:
I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux.
What problems are you referencing?
The fact that the test suite was not working properly if built using mingw32 vice building it with MS tools. If this has been overcome, good work for the devs.
Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers.
No, I don't have one. I have ssh access to one, but that's it. I'd like to see more testing done on the Mac, but until I get one personally, that won't happen for a while.
There is nothing like owning one....(I have three, my partner two, just for the record, I also own a Thinkpad A22p, that was the last PC I will buy unless Apple disappears.)
As to testing, what needs to be done? I would like to see a native version of Wine for the Mac, vice the requirement to use X11. That of course, may be years away (I worked with both the NeoOffice.org and OpenOffice.org projects with this. It was a multi-year adventure.)
James McKenzie
On Sat, Jul 11, 2009 at 4:45 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Austin English wrote:
On Sat, Jul 11, 2009 at 4:21 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Adam Strzelecki wrote:
I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux.
What problems are you referencing?
The fact that the test suite was not working properly if built using mingw32 vice building it with MS tools. If this has been overcome, good work for the devs.
It *IS* built daily by mingw32/64. Building on windows (last I checked), doesn't fully work yet, though the test suite it much closer than full wine (obviously).
Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers.
No, I don't have one. I have ssh access to one, but that's it. I'd like to see more testing done on the Mac, but until I get one personally, that won't happen for a while.
As to testing, what needs to be done? I would like to see a native version of Wine for the Mac, vice the requirement to use X11. That of course, may be years away (I worked with both the NeoOffice.org and OpenOffice.org projects with this. It was a multi-year adventure.)
Daily building from git, reporting broken compiles/compiler warnings and running the test suite daily would do a lot of good. I've asked this multiple times on wine-users and mentioned it it pretty much every OS X related thread on -devel, but no one (with a mac) has done anything about it.
On Thu, Jul 9, 2009 at 4:46 AM, Rolf Kalbermatterr.kalbermatter@hccnet.nl wrote:
With the same argument you could say that writing COM objects has to be done in C++. Yet Wine has lots and lots of COM code written all in standard C.
Agreed, writing object oriented code in C is not exactly trivial and often quite tedious and the difference with Object-C might be even bigger as it is likely using more advanced techniques.
While we are on the subject, could anyone point me to a reference that would show how I can create a mib file using C?
Thanks
Steven Edwards wrote:
While we are on the subject, could anyone point me to a reference that would show how I can create a mib file using C?
You meant Nib? It is binary format which is some Mac equivalent of Windows RES format. So this is not a source code.
Nib can be created from Xib source files (XML files) via "ibtool".
Cheers,
On Thu, Jul 9, 2009 at 9:02 AM, Adam Strzeleckiono@java.pl wrote:
Steven Edwards wrote:
While we are on the subject, could anyone point me to a reference that would show how I can create a mib file using C?
You meant Nib? It is binary format which is some Mac equivalent of Windows RES format. So this is not a source code.
Nib can be created from Xib source files (XML files) via "ibtool".
Thanks, thats what I need.
On Thursday 09 July 2009 1:46:59 am Rolf Kalbermatter wrote:
Adam Strzelecki [mailto:ono@java.pl]
Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is NextStep based objective oriented GUI & OS. And Obj-C is a basement of both NextStep and OSX. So if you want to write OSX GUI application properly you have to use Obj-C, same as C++ & KDE and so on.
With the same argument you could say that writing COM objects has to be done in C++. Yet Wine has lots and lots of COM code written all in standard C.
It has to, because the class vtable layout and calling convention can be different in Windows than how the host system's compiler will generate it. COM objects have to interface with existing Windows code, and so need to be setup in memory in a specific way.
By contrast, an OSX-specific driver can use Obj-C without consequence to existing Windows code. As long as said driver can expose a C-only interface for gdi32 or whatever, the Obj-C code is entirely self-contained and anything outside the app is none-the-wiser.
If OSX will always have Obj-C support, and the Obj-C code can be restricted to OSX-only code, then the only sticking point, in my eyes, would be how maintainable it is. After all, if only one or two people can work with Obj-C code, it can bit-rot that much more quickly.
On Friday 04 July 2008 23:43:11 James McKenzie wrote:
Comments on Adam's message
Adam Strzelecki wrote:
Hi Emmanuel, hello Wine developers,
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources.
Mac OS X support is really not on the radar, from what I can determine. Remember the original goal of Wine was to allow Windows programs to run on a Windows API for Linux and UNIX. Mac OSX switched from a proprietary system to FreeBSD/OpenBSD after the project started. Also add that a parallel project was started to allow Windows32s programs to run on OS/2.
Also, I'm not sure how many wine devs own macintels. I own a mac, but it's a PPC, and I'm not going to spend more money on macs any time soon.
Cheers, Kai
-
Adam Strzelecki -
Austin English -
Chris Robinson -
Dmitry Timoshkov -
Emmanuel Maillard -
Francois Gouget -
James McKenzie -
James McKenzie -
Jeremy White -
Jeremy White -
Jim White -
Kai Blin -
Markus Hitter -
Mike Kronenberg -
Nicklas Börjesson -
Rob Shearman -
Rolf Kalbermatter -
Saulius Krasuckas -
Stefan Dösinger -
Steven Edwards