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