The news is good.
First, if you are using Tiger, X11 is still broken and probably will remain so. Second, you do not need to upgrade to Leopard 10.5.7 to use XQuartz 2.3.3, the installer was fixed so it would install on 10.5.6. Third, Graphical games that depend on GLSL functions work. I tried dOOm, the Windows95 version, and it is definitely playable. Frame rates drop whenever you pick something up, but this also happens with CrossOver Games for Mac. This does not happen with Crossover Pro for Mac 7.1.
I do not have any other programs that depend on GLSL functionality, but I suspect they will work on this combination.
BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5.
James McKenzie
On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5.
I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run?
Thanks
On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwards@bordeauxgroup.com wrote:
On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5.
I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run?
Ideally, against a more recent wine version.
Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh
On May 17, 2009, at 3:45 PM, Austin English wrote:
Ideally, against a more recent wine version.
Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh
I have (yet another) build script, but OS X requires a number of deps to be compiled and installed as Apple doesn't ship some libraries, headers, or ships incomplete packages here and there. This is all pretty bare bones stuff.
I can vouch for functionality with Mac OS X 10.5.7 + XQuartz 2.3.3.1 + Wine 1.1.21 (from source). If and when I can find some time IRL, I can get the entire Wine compile and install with deps scripted up. This of course depends on free time, which is always somewhat lacking.
Your script looks good, Austin - lots of functionality there!
ryan woodsmall rwoodsmall@mac.com
"Be well, do good work, and keep in touch." - Garrison Keillor
Austin English wrote:
On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwards@bordeauxgroup.com wrote:
On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5.
I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run?
Ideally, against a more recent wine version.
Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh
Austin:
Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there.
James McKenzie
On Sun, May 17, 2009 at 6:43 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Austin English wrote:
On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwards@bordeauxgroup.com wrote:
On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5.
I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run?
Ideally, against a more recent wine version.
Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh
Austin:
Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there.
It's not really made to install all the needed dependencies (there is install-wine-deps.sh for that).
The Mac platform is so different in many ways that it's a bit hard to do. Does the user want to use fink/macports? Or install each from source? Do we install to /usr/local/bin? Or to a custom directory elsewhere? It's a big mess...
There is an OS X code path in place, but it is untested.
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin:
Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
Hi,
It's not about being willing to, but plain lack of time. I follow this list closely and work as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again.
There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm.
License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced to not double the work.
As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal.
Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports.
But if the name-change is the most pressing issue, I will gladly do that for you.
Mike Kronenberg
On 18.05.2009, at 06:56, Dmitry Timoshkov wrote:
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
-- Dmitry.
On 18.05.2009, at 06:56, Dmitry Timoshkov wrote:
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
-- Dmitry.
Hi,
(I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes)
It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again.
There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm.
License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work.
As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal.
Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports.
But if the name-change is the most pressing issue, I will gladly do that with this weekends release.
Mike Kronenberg
On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
On 18.05.2009, at 06:56, Dmitry Timoshkov wrote:
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
-- Dmitry.
Hi,
(I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes)
It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again.
There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm.
License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work.
As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal.
Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports.
But if the name-change is the most pressing issue, I will gladly do that with this weekends release.
Mike Kronenberg
Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it).
Roderick
On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
On 18.05.2009, at 06:56, Dmitry Timoshkov wrote:
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
-- Dmitry.
Hi,
(I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes)
It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again.
There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm.
License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work.
As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal.
Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports.
But if the name-change is the most pressing issue, I will gladly do that with this weekends release.
Mike Kronenberg
Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it).
Roderick
It's available under 'build env': http://www.kronenberg.org/darwine/buildenv-1.1.5.zip
On Wed, May 20, 2009 at 4:04 PM, Austin English austinenglish@gmail.com wrote:
On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg mike.kronenberg@kronenberg.org wrote:
On 18.05.2009, at 06:56, Dmitry Timoshkov wrote:
"James McKenzie" jjmckenzie51@earthlink.net wrote:
Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have.
IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project.
If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from).
-- Dmitry.
Hi,
(I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes)
It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again.
There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm.
License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work.
As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal.
Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports.
But if the name-change is the most pressing issue, I will gladly do that with this weekends release.
Mike Kronenberg
Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it).
Roderick
It's available under 'build env': http://www.kronenberg.org/darwine/buildenv-1.1.5.zip
-- -Austin
Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;)
Roderick
Roderick Colenbrander wrote:
Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;)
Can you provide the updates to the scripts? Since I am using Leopard, the opengl fix is not needed anymore, but it may have to stay until XQuartz 2.3.3 is backported for Tiger.
James McKenzie
On Sun, May 24, 2009 at 2:49 AM, James McKenzie jjmckenzie51@earthlink.net wrote:
Roderick Colenbrander wrote:
Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;)
Can you provide the updates to the scripts? Since I am using Leopard, the opengl fix is not needed anymore, but it may have to stay until XQuartz 2.3.3 is backported for Tiger.
James McKenzie
Hi James,
This is the script I used. It mainly consists of some new servers and updated version numbers because the original versions weren't available anymore (sure they are useally in some 'old' directory). Further I'm not building with the opengl patch.
Roderick
-
Austin English -
Dmitry Timoshkov -
James McKenzie -
Mike Kronenberg -
Roderick Colenbrander -
ryan woodsmall -
Steven Edwards