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