drive list is not refreshed in winecfg, no more disk label
Hi, [resend, 1st message disappeared?] since somewhere between wine-1.1.6 and 1.1.21, going to winecfg's drives tab does not (re)scan all drives such as CD-ROMs anymore. So access to the tab is faster, but winecfg does not display the disk label (shown empty) and serial number (always 0) any more. wine cmd -> "dir D:" still lists a disk's label and serial number. Did I miss a voluntary change or shall I file a regression? I'm not aware that my compilation setup may have changed. hal+dbus-dev have been there for ages. Thanks, Jörg Höhle
Joerg-Cyril.Hoehle(a)t-systems.com schrieb:
Hi, [resend, 1st message disappeared?]
since somewhere between wine-1.1.6 and 1.1.21, going to winecfg's drives tab does not (re)scan all drives such as CD-ROMs anymore. So access to the tab is faster, but winecfg does not display the disk label (shown empty) and serial number (always 0) any more.
wine cmd -> "dir D:" still lists a disk's label and serial number.
Did I miss a voluntary change or shall I file a regression?
I'm not aware that my compilation setup may have changed. hal+dbus-dev have been there for ages.
Thanks, Jörg Höhle
Maybe some of these commits did this: http://source.winehq.org/git/wine.git/?a=commitdiff;h=cda8e4410ace2616fdabde... http://source.winehq.org/git/wine.git/?a=commitdiff;h=abe00bbebe6c64df9d5403... http://source.winehq.org/git/wine.git/?a=commitdiff;h=18b66912b7f0c27cf5caca... http://source.winehq.org/git/wine.git/?a=commitdiff;h=6483f2f201c15b650c5e0e... http://source.winehq.org/git/wine.git/?a=commitdiff;h=f150ddc3ed5ce35fb06f5b... http://source.winehq.org/git/wine.git/?a=commitdiff;h=f410cf7c98aa60b7d6beb4... specially the second one may have caused it. can you make a regression test? Best Regards André Hentschel
Hi, I've just submitted a patch to fix this bug, #19045. This issue is caused by commit f7e6777e6e19ca3be4b84f98baf22ef53ab19f96 Author: Guy Albertelli <galberte(a)neo.rr.com> Date: 29.04.2009 03:08:22 Follows: wine-1.1.20 (Release 1.1.20.) kernel32: Fix GetVolumeInformation[AW] to require trailing \. I spotted three places where I added a trailing \ (one of them obviously in winecfg). However, there are more calls to GetVolumeInformation in the source. They need a review because it was not obvious to me whether they supplied the required trailing backslash, e.g. int21.c:3234 /* LONG FILENAME - GET VOLUME INFORMATION */ ... see below Others, like in shell32/shellpath.c are just pass-through, so the callers need be reviewed. So I invite interested parties to check the calls to GetVolumeInformation in the wine source to assess whether the callers provide the \. Otherwise, please submit a patch. In the annoated output of grep below, "pass" means pass-through; "review" please; and "ok" means I found the code to be either fine or fixed by my patch. pass ./dlls/msi/media.c:56: if (!GetVolumeInformationW(source_root, volume_name, MAX_PATH + 1, review ./dlls/shell32/shfldr_mycomp.c:711: GetVolumeInformationW (pszPath, wszDrive, pass ./dlls/shell32/shellpath.c:453: if (!GetVolumeInformationA(lpszPath, NULL, 0, NULL, &fnlen, NULL, NULL, 0)) pass ./dlls/shell32/shellpath.c:465: if (!GetVolumeInformationW(lpszPath, NULL, 0, NULL, &fnlen, NULL, NULL, 0)) pass ./dlls/user32/network.c:194: GetVolumeInformationA( lpLocalName, label, sizeof(label), NULL, NULL, NULL, NULL, 0 ); ok ./dlls/winedos/int21.c:2608: GetVolumeInformationW(drivespec, label, 12, &serial, NULL, NULL, fsname, 9); review ./dlls/winedos/int21.c:3234: if (!GetVolumeInformationW( pathW, NULL, 0, NULL, &filename_len, ok ./dlls/winedos/int21.c:3426: if (!GetVolumeInformationW( path, label, 11, &serial, NULL, NULL, NULL, 0)) ok ./dlls/winedos/int21.c:3884: if (!GetVolumeInformationW(path, entry->cAlternateFileName, 13, NULL, NULL, NULL, NULL, 0)) return 0; ok ./dlls/kernel32/tests/volume.c:... tests assumed ok ./dlls/kernel32/volume.c:507:BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR label, DWORD label_len, ./dlls/kernel32/volume.c:628:BOOL WINAPI GetVolumeInformationA( LPCSTR root, LPSTR label, ok ./dlls/kernel32/volume.c:642: if ((ret = GetVolumeInformationW(rootW, labelW, label_len, serial, ok ./dlls/shell32/shelllink.c:2154: r = GetVolumeInformationW(drive, volume->label, label_sz, ok ./programs/cmd/builtins.c:2482: status = GetVolumeInformation (NULL, label, sizeof(label)/sizeof(WCHAR), ok ./programs/cmd/builtins.c:2492: status = GetVolumeInformation (curdir, label, sizeof(label)/sizeof(WCHAR), ok ./programs/winefile/winefile.c:1402: GetVolumeInformation(drv, root->volname, _MAX_FNAME, 0, 0, &root->fs_flags, root->fs, _MAX_DIR); ok ./programs/winecfg/drive.c:287: if (!GetVolumeInformationW( root, volname, sizeof(volname)/sizeof(WCHAR), Regards, Jörg Höhle
Hi, Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/ This is unappropriate censorship to me. http://wiki.winehq.org/MacOSX/FAQs?action=diff&rev2=39&rev1=40 Am I upset? It costs me precious time to write code and documentation, so I dislike it when it gets deleted for uncomprehensible reasons. Censorship may be too strong a word. The only gripes I understand about Kronenberg's work are: - Although he agreed to change the name from Darwin to Wine in May, he has not yet done so. Cf. http://www.winehq.org/pipermail/wine-devel/2009-May/075775.html - Similarly, the license is still GPL, while Wine switched to LGPL long ago. Other than that, his work seems solid and provides for a great user experience: + It's built with Xcode 2.5, so it does not suffer from bug #14920 http://bugs.winehq.org/show_bug.cgi?id=14920 So 16bit applications work. + It provides a WineHelper GUI applications that supposedly makes it easy to start applications by clicking on icons. I never used it and am still researching the equivalent of xyz.desktop files from Linux. winemenubuilder does not work on MacOS so far. + It contains a newer FreeType library than Apple's which I've read is buggy. I can confirm that e.g. his winecfg "About" page looks as crisp as on Linux, whereas my build using only Apple resources shows ugly 'W' and kerning: in "Bibliothek", there should be one pixel horizontal space between letters, never 2. On Linux all lines are exactly one pixel wide, crisp as if hand-drawn. HKCU\FontSmoothing does not help, as the ugly 'W' just gets shades of grey. Perhaps the only difference is Tahoma.ttf (the 'f' looks different), i.e. font files rather than FreeType, but so far I did not further investigate this issue. + He's been providing a binary distribution for a long time. Linux experience shows that most people tend to download binaries rather than build themselves from source. Users of gentoo are sometimes considered exotic for that reason. OTOH on Mac, this seems normal, as neither Fink nor MacPorts provide online binary repositories. Strange. + I looked into his build script. http://www.kronenberg.org/darwine/buildenv-1.1.5.zip It is basically ./configure & make as far as Wine is concerned. I can start /Volumes/Darwine/Contents.../bin/wine foo.exe like on Linux. Beside that, it builds WineHelper, FreeType and lots of other open source libraries. All but one of the 3-4 patches therein are obsolete (already in Wine git or perhaps only needed on Tiger). There's a single patch not in Wine: XGravity event handling. Hopefully Mike can comment on it. Presumably it should get into Wine as well. So to me his binary appears like a pretty normal Wine build. This is not Cedega. I am about to submit a bug report to Wine bugzilla about MIDI audio based on his binary; I see no reason to dismiss it. Sadly I cannot produce the bug compiling myself, because of the above all-16bit-apps-crash bug with the Xcode3.x that I own. Not knowing whether there have been past disputes between him and others, Mr. Kronenberg (whom I don't know) appears to me like a normal user of Web and Mac resources. This does not justify censorship. I've updates to other MacOS Wiki pages in the queue that I'll put on hold until the situation clarifies -- hopefully for the best to all people. Please get together. Regards, Jörg Höhle
Greetings Jörg,
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
This is unappropriate censorship to me.
I can't speculate about Dmitry's motivations, but there is one simple rationale I can think of for such an action: the Wine project does not generally provide support for binary distributions. The only exceptions are those that are simple compiles of the official WineHQ git source, with required dependencies, but otherwise unmodified source. Mike Kronenberg's package may be close to this, but as long as it has any patches applied that are not in mainline, it doesn't qualify, at least in my opinion. This isn't to say that Mike isn't free to make his own distribution available, subject to the usual license restrictions. It just means that we're under no obligation to mention it. --Juan
Hi Jörg, Juan, On 25 Jun 2009, at 22:05, Juan Lang wrote:
Greetings Jörg,
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
This is unappropriate censorship to me.
I can't speculate about Dmitry's motivations, but there is one simple rationale I can think of for such an action: the Wine project does not generally provide support for binary distributions. The only exceptions are those that are simple compiles of the official WineHQ git source, with required dependencies, but otherwise unmodified source. Mike Kronenberg's package may be close to this, but as long as it has any patches applied that are not in mainline, it doesn't qualify, at least in my opinion.
This isn't to say that Mike isn't free to make his own distribution available, subject to the usual license restrictions. It just means that we're under no obligation to mention it. --Juan
IMHO, it would be sufficient to add a "not supported by winehq.org" disclaimer next to the mention. If there currently is no binary distribution that packs the vanilla wine tree then you're making it unnecessarily difficult to obtain a binary distribution for the Mac OS X crowd. XCode is a separate install/download (weighing in at almost 1GB) and people are generally less comfortable with the command line than Linux folks. I had to google quite a bit to find current wine packages for OS X and a link on the wiki would have been much appreciated. Cheers, -Maik
"Maik Schulz" <ladenlokalvelbert(a)gmail.com> wrote:
IMHO, it would be sufficient to add a "not supported by winehq.org" disclaimer next to the mention. If there currently is no binary distribution that packs the vanilla wine tree then you're making it unnecessarily difficult to obtain a binary distribution for the Mac OS X crowd. XCode is a separate install/download (weighing in at almost 1GB) and people are generally less comfortable with the command line than Linux folks. I had to google quite a bit to find current wine packages for OS X and a link on the wiki would have been much appreciated.
In my opinion WineHQ Wiki is not an appropriate place for that. It would look like WineHQ somehow suggests to download and use that package, while that's not true. Darwine builds fall in the same category as WineX, and other Wine forks with not clear or conflicting licenses, or not supported and even listed/published patches applied. Users are not welcome to download, use, and report bugs for these packages, moreover these packages/packagers have nothing to do with WineHQ at all, and not deserve mentioning, as it would look like inappropriate advertising using WineHQ resources. IMHO. -- Dmitry.
On 26 Jun 2009, at 10:29, Dmitry Timoshkov wrote:
"Maik Schulz" <ladenlokalvelbert(a)gmail.com> wrote:
IMHO, it would be sufficient to add a "not supported by winehq.org" disclaimer next to the mention. If there currently is no binary distribution that packs the vanilla wine tree then you're making it unnecessarily difficult to obtain a binary distribution for the Mac OS X crowd. XCode is a separate install/ download (weighing in at almost 1GB) and people are generally less comfortable with the command line than Linux folks. I had to google quite a bit to find current wine packages for OS X and a link on the wiki would have been much appreciated.
In my opinion WineHQ Wiki is not an appropriate place for that. It would look like WineHQ somehow suggests to download and use that package, while that's not true. Darwine builds fall in the same category as WineX, and other Wine forks with not clear or conflicting licenses, or not supported and even listed/published patches applied. Users are not welcome to download, use, and report bugs for these packages, moreover these packages/packagers have nothing to do with WineHQ at all, and not deserve mentioning, as it would look like inappropriate advertising using WineHQ resources.
IMHO.
-- Dmitry.
Fair enough, but then, as long as there is no "approved" binary package, we have to accept that we probably get as many OS X users as you would get on Windows for an application that requires you to compile it yourself. The vast majority will be happy to find winehq.org, read that it works on OS X... then get disappointed when they don't find a binary package and turn to google to find one--and end up with a non-supported build. Maybe we shouldn't even advertise the "works on OS X" as long as we target only a minority on that platform. Cheers, -Maik
On Thu, Jun 25, 2009 at 8:56 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Hi,
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
This is unappropriate censorship to me. http://wiki.winehq.org/MacOSX/FAQs?action=diff&rev2=39&rev1=40
Am I upset? It costs me precious time to write code and documentation, so I dislike it when it gets deleted for uncomprehensible reasons. Censorship may be too strong a word.
The only gripes I understand about Kronenberg's work are: - Although he agreed to change the name from Darwin to Wine in May, he has not yet done so. Cf. http://www.winehq.org/pipermail/wine-devel/2009-May/075775.html - Similarly, the license is still GPL, while Wine switched to LGPL long ago.
Other than that, his work seems solid and provides for a great user experience:
+ It's built with Xcode 2.5, so it does not suffer from bug #14920 http://bugs.winehq.org/show_bug.cgi?id=14920 So 16bit applications work.
+ It provides a WineHelper GUI applications that supposedly makes it easy to start applications by clicking on icons. I never used it and am still researching the equivalent of xyz.desktop files from Linux. winemenubuilder does not work on MacOS so far.
+ It contains a newer FreeType library than Apple's which I've read is buggy. I can confirm that e.g. his winecfg "About" page looks as crisp as on Linux, whereas my build using only Apple resources shows ugly 'W' and kerning: in "Bibliothek", there should be one pixel horizontal space between letters, never 2. On Linux all lines are exactly one pixel wide, crisp as if hand-drawn. HKCU\FontSmoothing does not help, as the ugly 'W' just gets shades of grey. Perhaps the only difference is Tahoma.ttf (the 'f' looks different), i.e. font files rather than FreeType, but so far I did not further investigate this issue.
+ He's been providing a binary distribution for a long time. Linux experience shows that most people tend to download binaries rather than build themselves from source. Users of gentoo are sometimes considered exotic for that reason. OTOH on Mac, this seems normal, as neither Fink nor MacPorts provide online binary repositories. Strange.
+ I looked into his build script. http://www.kronenberg.org/darwine/buildenv-1.1.5.zip It is basically ./configure & make as far as Wine is concerned. I can start /Volumes/Darwine/Contents.../bin/wine foo.exe like on Linux. Beside that, it builds WineHelper, FreeType and lots of other open source libraries. All but one of the 3-4 patches therein are obsolete (already in Wine git or perhaps only needed on Tiger). There's a single patch not in Wine: XGravity event handling. Hopefully Mike can comment on it. Presumably it should get into Wine as well.
So to me his binary appears like a pretty normal Wine build. This is not Cedega. I am about to submit a bug report to Wine bugzilla about MIDI audio based on his binary; I see no reason to dismiss it. Sadly I cannot produce the bug compiling myself, because of the above all-16bit-apps-crash bug with the Xcode3.x that I own.
The lingering problem is that those extra features make it different from 'vanilla' wine. While most of the patches in there are obsolete, they're still in the source and still applied. The build source isn't current, some of the package downloads are busted (not really a reason to 'block it' though). In that discussion you've already referenced, most of this is already mentioned. If there were a plain vanilla wine built on OS X, I think more developers would be receptive to it. Unfortunately, most developers don't have access to Mac's, and/or aren't focused on packaging/etc., but on more practical coding (fixing bugs, adding features, etc.). -- -Austin
On Thu, Jun 25, 2009 at 10:06 PM, Austin English<austinenglish(a)gmail.com> wrote:
On Thu, Jun 25, 2009 at 8:56 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Hi,
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
This is unappropriate censorship to me. http://wiki.winehq.org/MacOSX/FAQs?action=diff&rev2=39&rev1=40
Am I upset? It costs me precious time to write code and documentation, so I dislike it when it gets deleted for uncomprehensible reasons. Censorship may be too strong a word.
The only gripes I understand about Kronenberg's work are: - Although he agreed to change the name from Darwin to Wine in May, he has not yet done so. Cf. http://www.winehq.org/pipermail/wine-devel/2009-May/075775.html - Similarly, the license is still GPL, while Wine switched to LGPL long ago.
Other than that, his work seems solid and provides for a great user experience:
+ It's built with Xcode 2.5, so it does not suffer from bug #14920 http://bugs.winehq.org/show_bug.cgi?id=14920 So 16bit applications work.
+ It provides a WineHelper GUI applications that supposedly makes it easy to start applications by clicking on icons. I never used it and am still researching the equivalent of xyz.desktop files from Linux. winemenubuilder does not work on MacOS so far.
+ It contains a newer FreeType library than Apple's which I've read is buggy. I can confirm that e.g. his winecfg "About" page looks as crisp as on Linux, whereas my build using only Apple resources shows ugly 'W' and kerning: in "Bibliothek", there should be one pixel horizontal space between letters, never 2. On Linux all lines are exactly one pixel wide, crisp as if hand-drawn. HKCU\FontSmoothing does not help, as the ugly 'W' just gets shades of grey. Perhaps the only difference is Tahoma.ttf (the 'f' looks different), i.e. font files rather than FreeType, but so far I did not further investigate this issue.
+ He's been providing a binary distribution for a long time. Linux experience shows that most people tend to download binaries rather than build themselves from source. Users of gentoo are sometimes considered exotic for that reason. OTOH on Mac, this seems normal, as neither Fink nor MacPorts provide online binary repositories. Strange.
+ I looked into his build script. http://www.kronenberg.org/darwine/buildenv-1.1.5.zip It is basically ./configure & make as far as Wine is concerned. I can start /Volumes/Darwine/Contents.../bin/wine foo.exe like on Linux. Beside that, it builds WineHelper, FreeType and lots of other open source libraries. All but one of the 3-4 patches therein are obsolete (already in Wine git or perhaps only needed on Tiger). There's a single patch not in Wine: XGravity event handling. Hopefully Mike can comment on it. Presumably it should get into Wine as well.
So to me his binary appears like a pretty normal Wine build. This is not Cedega. I am about to submit a bug report to Wine bugzilla about MIDI audio based on his binary; I see no reason to dismiss it. Sadly I cannot produce the bug compiling myself, because of the above all-16bit-apps-crash bug with the Xcode3.x that I own.
The lingering problem is that those extra features make it different from 'vanilla' wine. While most of the patches in there are obsolete, they're still in the source and still applied. The build source isn't current, some of the package downloads are busted (not really a reason to 'block it' though).
In that discussion you've already referenced, most of this is already mentioned.
If there were a plain vanilla wine built on OS X, I think more developers would be receptive to it. Unfortunately, most developers don't have access to Mac's, and/or aren't focused on packaging/etc., but on more practical coding (fixing bugs, adding features, etc.).
-- -Austin
I would be willing to assist with any Mac issues as I would need a LGPL'ed version of Wine on OSX myself. I'm assisting bringing a university program to Linux/Mac using Wine and for that I need decent Mac support. Darwine set some steps in the right direction and we could help making it a better experience. I do agree that the license / name issues should be solved. I'm also interested in a way to create application bundles of Wine + win32 app for Mac and plan to work on that. Perhaps others are interested as well. Roderick
On Fri, Jun 26, 2009 at 5:00 AM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
I would be willing to assist with any Mac issues as I would need a LGPL'ed version of Wine on OSX myself. I'm assisting bringing a university program to Linux/Mac using Wine and for that I need decent Mac support. Darwine set some steps in the right direction and we could help making it a better experience. I do agree that the license / name issues should be solved.
For those interested, I've got an OSX dependency building script written, based on Darwine. Get it here (http://winezeug.googlecode.com/svn-history/r564/trunk/install-osx-deps.sh). It simply downloads wine dependencies (jpeg/png/etc.), builds and installs to $HOME/.winedeps, then spits out a build script to use for compiling 'vanilla' wine. I don't have a mac here to test with (builds fine over ssh), so testing would be great. AFAICT, you'll hit bug 17674, so use http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html to fix that...not sure why that hasn't been applied yet. If mac users could test the script and send me any feedback/problems/good vibes, I'd appreciate it. (I don't want to send it to wine-users until I'm sure it works well). -- -Austin
If there were a plain vanilla wine built on OS X
IMHO, Mac Users can expect from a binary distribution something Mac-like, e.g. some kind of GUI. Another OSS project I've worked on for over a decade used to embed NeXtStep specific GUI source code. There was no GUI for any other UNIX derivative. Why not ship something that meets the OS users' expectations? What I like about Kronenberg's distribution is that GUI and Wine are (at least internally) separated. /Volumes/Darwine/Darwine/Contents.../bin/wine winecfg|regedit|xyz.exe just works like I'm used to on Linux. Actually, I've never used the GUI to start something beside winecfg. Maybe one could turn this into a requirement for a more or less official Wine distribution? + Do not hide or stand in the way of a plain "wine foo.exe". Rather than that, document it! BTW, I now understand that this WineHelper GUI originates from the defunct Darwine project. I'd recommend removing from this GUI's preferences menu anything that's settable in winecfg today (...most of "preferences"!). (AFAIK, winecfg is only 6 years old, Linux Wine users used to edit configuration files before that GUI was created, so back then, this Mac preferences GUI was a real benefit to users). Regards, Jörg Höhle
On 29 Jun 2009, at 14:10, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com
wrote:
If there were a plain vanilla wine built on OS X
IMHO, Mac Users can expect from a binary distribution something Mac- like, e.g. some kind of GUI.
Another OSS project I've worked on for over a decade used to embed NeXtStep specific GUI source code. There was no GUI for any other UNIX derivative. Why not ship something that meets the OS users' expectations?
+1
James McKenzie wrote:
Something that I do have to point out is that freetype, a very important library for Wine is not shipped with XCode nor MacOSX. We have to include it.
Huh? On my 10.5.7 Leopard system, Wine was able to find FreeType -- with LD_LIBRARY_PATH guidance. And I have nothing but - MacOS (with iLife preinstalled) - (selected packages from) the Xcode install DVD and - XQuartz 2.3.3.2 installed on that box. Did you install Apple's X11 before installing XQuartz, as the XQuartz site recommends? Are you mislead by the following error message? ---- snip Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Building font metrics. This may take some time... Font metrics: 0.0% done fixme:font:LFD_InitFontInfo DBCS fonts like '-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0' are not working correctly now. ... ---- http://bugs.winehq.org/show_bug.cgi?id=17674#c4 I saw those on my first compile && make && ./wine winecfg LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad prevents those messages. Wine then starts up much faster (still slower than a slower Ubuntu box, some people suppose that is due to the many fonts) and does not re-generate font data for *every* subprocess ran inside Wine. LD_LIBRARY_PATH=/usr/X11/lib is needed because libfreetype.* is there. If you want, I'll try to identify (using pkgutil) what package installed /usr/X11/lib/libfreetype.*. BTW, it would be nice if MacOS users could comment on a) my comment #4 to bug #17674 above or on b) my patch http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html It was not included in Wine-1.1.25 perhaps because AJ awaits confirmations from other users? Are there so many differences between MacOS systems (even Leopard only) or how to explain the different experience reports in this mailing list? For completeness, Apple's libfreetype may have some bugs. E.g. some letters, esp. W and w look ugly in winecfg, while Kronenberg's version looks as crisp as a Linux one. I have not yet investigated this further, so it's too early for recommendations. For sure, it's not a matter of anti-aliasing (FontSmoothing): that works, the 'W' then gets shades of grey, but it's still not crisp, sharp, 1 pixel wide as on Linux. BTW, I was about to rewrite the http://wiki.winehq.org/MacOSX/Installing wiki page, explaining how to build&compile when I faced that "censorship" issue. Regards, Jorg Hohle
Joerg-Cyril.Hoehle(a)t-systems.com wrote:
James McKenzie wrote:
Something that I do have to point out is that freetype, a very
important
library for Wine is not shipped with XCode nor MacOSX. We have to include it.
Huh? On my 10.5.7 Leopard system, Wine was able to find FreeType -- with LD_LIBRARY_PATH guidance. And I have nothing but - MacOS (with iLife preinstalled) - (selected packages from) the Xcode install DVD and - XQuartz 2.3.3.2 installed on that box.
Did you install Apple's X11 before installing XQuartz, as the XQuartz site recommends?
Are you mislead by the following error message? ---- snip Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Building font metrics. This may take some time... Font metrics: 0.0% done fixme:font:LFD_InitFontInfo DBCS fonts like '-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0' are not working correctly now. ... ---- http://bugs.winehq.org/show_bug.cgi?id=17674#c4 I saw those on my first compile && make && ./wine winecfg
LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad prevents those messages. Wine then starts up much faster (still slower than a slower Ubuntu box, some people suppose that is due to the many fonts) and does not re-generate font data for *every* subprocess ran inside Wine.
LD_LIBRARY_PATH=/usr/X11/lib is needed because libfreetype.* is there.
If you want, I'll try to identify (using pkgutil) what package installed /usr/X11/lib/libfreetype.*.
It's there. I'll check Fink to see what the latest versions are and how they compare. James McKenzie
Joerg-Cyril.Hoehle(a)t-systems.com wrote:
BTW, it would be nice if MacOS users could comment on a) my comment #4 to bug #17674 above or on b) my patch http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html It was not included in Wine-1.1.25 perhaps because AJ awaits confirmations from other users?
That patch looks very familiar. I think it is the fallback path that Mike uses. James McKenzie
<Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
The explanation is here: http://wiki.winehq.org/MacOSX/FAQs#head-fb45851cc05c63812c5660d1b0216b84a339... 1. Darwine is a separate project with different licensing terms from Wine (GPL vs. LGPL), 2. it's not clear what kind of patches they apply on top of Wine, 3. the fact that they insist on a different name And promises to rename the product to Wine and change the licensing differences still do remain promises. -- Dmitry.
Hi, Darwine tools WineHelper and create_darwine_distrib script are not GPL but LGPL. Don't know for Mike Kronenberg patches or other stuffs, but we never change Wine licensing in Darwine. Emmanuel Le 26 juin 09 à 05:19, Dmitry Timoshkov a écrit :
<Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less outdated than before and today I found that Dmitry Timoshkov removed all references to Mike Kronenberg's Wine binary distribution at http://www.kronenberg.org/darwine/
The explanation is here:
http://wiki.winehq.org/MacOSX/FAQs#head-fb45851cc05c63812c5660d1b0216b84a339...
1. Darwine is a separate project with different licensing terms from Wine (GPL vs. LGPL), 2. it's not clear what kind of patches they apply on top of Wine, 3. the fact that they insist on a different name
And promises to rename the product to Wine and change the licensing differences still do remain promises.
-- Dmitry.
"Emmanuel Maillard" <mahanuu(a)free.fr> wrote:
Darwine tools WineHelper and create_darwine_distrib script are not GPL but LGPL. Don't know for Mike Kronenberg patches or other stuffs, but we never change Wine licensing in Darwine.
Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple. -- Dmitry.
On Fri, Jun 26, 2009 at 10:51 AM, Dmitry Timoshkov<dmitry(a)codeweavers.com> wrote:
Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple.
I have a Mac that I've given Austin English access to for his Wine hacking needs and he's got a set of scripts for building and running Winetests. I am happy to provide binaries of stock Winehq but I don't see any reason why we can't link to Mike's Darwine build. Maybe he's not had time to cleanup his site, documentation or whatever. As far as the patches go, fewer and fewer of them are needed. Austin has been cleaning up the build script, which btw mostly just satisfies dependencies. I don't know of any major patch we currently need to make stock Wine not suck on OS X. Having the extra Darwine stuff like the helper should not be a problem as it does not mess with Wine directly. For my own tree, the only major hack I've used from Darwine is the wine script that is used to launch Wine. It simply insures the environment is always sane and has the normal stock wine binary renamed to mwine. Certain Linux package maintainers have recently expressed interest in bundling the DIB Engine and custom Icon sets in their Wine packages are we going to stop allowing those package maintainers to link on Winehq if they do this? None of these changes seem like a major enough issue to warrant not supporting the package. I mean hell you support packages built with different compiler revisions, minor glibc, freetype, libxml2, libjpeg, libpng, X11, etc library versions and God only knows how many Linux distribution combinations if someone reports a bug to bugzilla while the mess that is the Linux distro's gets an easy pass. I think its clearly a double standard. -- 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
On Fri, Jun 26, 2009 at 9:42 PM, Steven Edwards<winehacker(a)gmail.com> wrote:
On Fri, Jun 26, 2009 at 10:51 AM, Dmitry Timoshkov<dmitry(a)codeweavers.com> wrote:
Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple.
I have a Mac that I've given Austin English access to for his Wine hacking needs and he's got a set of scripts for building and running Winetests. I am happy to provide binaries of stock Winehq but I don't see any reason why we can't link to Mike's Darwine build. Maybe he's not had time to cleanup his site, documentation or whatever.
As far as the patches go, fewer and fewer of them are needed. Austin has been cleaning up the build script, which btw mostly just satisfies dependencies. I don't know of any major patch we currently need to make stock Wine not suck on OS X. Having the extra Darwine stuff like the helper should not be a problem as it does not mess with Wine directly. For my own tree, the only major hack I've used from Darwine is the wine script that is used to launch Wine. It simply insures the environment is always sane and has the normal stock wine binary renamed to mwine. Certain Linux package maintainers have recently expressed interest in bundling the DIB Engine and custom Icon sets in their Wine packages are we going to stop allowing those package maintainers to link on Winehq if they do this?
If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows. Roderick
On Fri, Jun 26, 2009 at 4:36 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows.
Maybe that was a bad example though it is opt-in to turn on the DibEngine even it is installed so the amount of false reports from it should be pretty low. But fine, I grant maybe the DibEngine is slightly invasive and if enabled could lead to bogus bug reports. To my knowledge none of the required patches for a Darwine build with current Wine are very invasive. Normally I wouldn't care about such things but we decided at Wineconf (in Reading I think), when the question of Mac users came up, the consensus was point them at Darwine because nobody wanted to do binary builds. I think we have a brief talk about it at the last Wineconf (I was pretty sick and out of it for most of it) but I don't recall the policy being changed. If we are going to arbitrarily decide to just nuke support for Mike's package (The only semi-actively maintained Darwine) there should be some discussion first because it was a topic at Wineconf. Like I said, I'm happy to offer my box for doing builds if there is really consensus that it needs to change. Thanks -- 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
On Fri, Jun 26, 2009 at 3:36 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows.
I wouldn't call the DIB engine a hack. A large piece of code not accepted into official WineHQ, sure. -- -Austin
2009/6/27 Austin English <austinenglish(a)gmail.com>:
On Fri, Jun 26, 2009 at 3:36 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows.
I wouldn't call the DIB engine a hack. A large piece of code not accepted into official WineHQ, sure.
Even the author considers it a *bit* of one :-) - d.
On Fri, Jun 26, 2009 at 7:10 PM, David Gerard<dgerard(a)gmail.com> wrote:
2009/6/27 Austin English <austinenglish(a)gmail.com>:
On Fri, Jun 26, 2009 at 3:36 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
If they ship hacks like the DIB engine then we won't accept bug reports for it as it a real big hack and shouldn't be linked to from our website. Tweaking themes or icons is fine. Actually we just need to refine our .msstyles support and then icon can just be part of a theme like they are on Windows.
I wouldn't call the DIB engine a hack. A large piece of code not accepted into official WineHQ, sure.
Even the author considers it a *bit* of one :-)
Without starting a huge side argument, until a proper way is known, it can't really be a hack. Besides...the test suite passes with it :-). -- -Austin
On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:
"Emmanuel Maillard" <mahanuu(a)free.fr> wrote:
Darwine tools WineHelper and create_darwine_distrib script are not GPL but LGPL. Don't know for Mike Kronenberg patches or other stuffs, but we never change Wine licensing in Darwine.
Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple.
-- Dmitry.
This is very true. Prolog The main purpose is here, like with other people, to have a crossdev option. I just share the outcome, i.e. binaries. OS X My main concern is to have usable builds. Ie, usable without the need of a terminal. People on OS X don't care about how stuff works, it just has to work. Vanilla build I totally agree that by adding certain patches, the builds can't be considered as vanilla. I'll recheck the necessity of the patches again on Tiger and Leopard and they really get less and less. Added libs As pointed out, the build ships with some libs not installed by default on OS X. My solution is to hide them inside the app folder, this way they are not installed in the users /usr or /opt. Drag the folder to trash and they are all gone at once. Clean system. Next try. Helper app The average user on OS X needs the help of a launcher to run it's windows bins. This is why I use to pack the WineHelper from Darwine Project. The WineHelper is LGPL as stated by Emmanuel Maillard. Where to? As pointed out above, I'm probably not going to build 10 versions of wine, but I will move closer to source, as functionality permits. If I understand Dmitry and a lot of other mails (from way back) correct, there is no space to include a helper app or 3rd party libs in the package as it would "not be wine". I am perfectly ok with this, as vanilla wine is for me really a "lib". There is no space for multi-platform UI stuff in this lib. The lib has to remain clean of clutter. But exactly as the back-end has to be done right, UI and front-end needs to be done right. For me, this is at least specific to every platforms HIGs. As the user would expect it. This is why there is no room for obj-c, nibs and the like in wine. (same goes fro qt et al.) I could write a basic app in plain c and a shell-script to create the needed app bundle (and document types to be launch by wine) at compile- time. The question is, is it of use? I say no. Most average user tend for "all in one solutions" like "Crossover", "Bordeaux" and other "Tools" from the "3rd Party Tools" site... as setting up a working environment still is way beyond their knowledge. So what? I know that codeweavers are one (if not the) the main force behind the wine project and respect all the input. The "endorsement" note behind the first download on the downloads page is rather misleading as the input is way bigger than the hosting for wine ;) But as this still is an open project, I would grant other "distributions and tools" aka "3rd Party Tools" at least a prominent (not like now in text) link on the download page. Then I'd structure the "3rd Party Tools" page similar to the Downloads page, where a users sees at once which product might A) run on his system B) serve his particular needs. There is where I'd put my wine builds if they are not vanilla enough for semi-official builds :) Why? Sysadmins and maintainers need no wine rpm's, they build it. Power-users need rpms. But the big lot of the average user is on the lookout for a solution to a problem, which they rather find on the "Tools" page. I will not put % behind these groups, but I think that group 3 deserves better access to the things they are looking for. Lookout I'm not really into these renaming things atm. Removing the "Dar" they would lead to new paths, which break installations on a lot of Macs. As suggested my focus lies in creating a wine.framework, like the mono project has done. It should include all the needed libs (3rd party libs as framework, too). I succeeded in turning all the dependencies into frameworks already. I'm now stuck with wine building against these frameworks. This way, the wine.framework will be cleanly separated from any "3rd Party Tool" and can be accessed the OS X way by them, and name/path changes will no longer affect these tools as long wine remains wine. Mike Kronenberg Btw. I'm alone. And as I know that my builds do not qualify as "official", I do a lot of first level support on my builds and wine tools... this mail reflects the user spectrum I've got to do with ;)
On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg < mike.kronenberg(a)kronenberg.org> wrote:
OS X My main concern is to have usable builds. Ie, usable without the need of a terminal. People on OS X don't care about how stuff works, it just has to work.
Vanilla build I totally agree that by adding certain patches, the builds can't be considered as vanilla. I'll recheck the necessity of the patches again on Tiger and Leopard and they really get less and less.
My $.02: we've got two different problems we're trying to solve with the same build. We're trying to give the user a great user experience by including lots of extras; and this is a Noble Goal and a Good Thing. We're also trying to collect good bug reports that aren't tainted by crap; and this is also a Noble Goal and Good Thing. It seems like this could be solved by two different builds. Keep the Darwine stuff the way it is, just put a huge warning label on it that says the code is unsupported. Second, provide another binary build that's as much of a vanilla wine as possible. Because we like our user community and we like to be nice to them, we'll provide links to BOTH of them from the Wine website as well as put the giant UNSUPPORTED stamp on the first one. Then we tell Mac users if they want to submit a bug report they should download and install this other package and try to reproduce their bug. Now, the side effect there is that maybe it will improve the quality of bugs being reported. Folks who take the time to download that extra package, set up their environment properly, etc, etc, well, they probably have the ability to also write a coherent bug report. (You could also argue that rather than provide this second package you could simply make people compile it themselves, but I'd argue that it makes it an order of magnitude harder to submit a bug report and we'd effectively alienate the vast majority of the user community.) Oh, and we have a branding issue where this code magically transforms from Wine into something by another name. I completely understand why we're not a big fan of that. I also understand it could break things if you attempt to change paths. However, the sooner you do that, the sooner it gets done. It's actually doing the user community a disservice by calling it Darwine rather than Wine. If you throw "Darwine" into Google, you don't turn up a single site on the first page that's a Wine web page. As a result, all the great things like our AppDB, Wiki, developer tips, etc aren't a resource for that user community. (Wow! Look at our Page Rank for "Wine". We need to start selling bottles of wine on winehq.org.) -Brian
Mike Kronenberg wrote:
On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:
"Emmanuel Maillard" <mahanuu(a)free.fr> wrote:
Darwine tools WineHelper and create_darwine_distrib script are not GPL but LGPL. Don't know for Mike Kronenberg patches or other stuffs, but we never change Wine licensing in Darwine.
Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple.
-- Dmitry.
This is very true.
Prolog The main purpose is here, like with other people, to have a crossdev option. I just share the outcome, i.e. binaries.
OS X My main concern is to have usable builds. Ie, usable without the need of a terminal. People on OS X don't care about how stuff works, it just has to work.
Vanilla build I totally agree that by adding certain patches, the builds can't be considered as vanilla. I'll recheck the necessity of the patches again on Tiger and Leopard and they really get less and less.
Added libs As pointed out, the build ships with some libs not installed by default on OS X. My solution is to hide them inside the app folder, this way they are not installed in the users /usr or /opt. Drag the folder to trash and they are all gone at once. Clean system. Next try.
Something that I do have to point out is that freetype, a very important library for Wine is not shipped with XCode nor MacOSX. We have to include it. Both MacPorts and Fink's builds make this a dependency and force you to install it. Fortunately, Fink puts it in a place where installing other software with freetype (and the other libraries required for Wine) do not interfere with each other. Right now, a 'vanilla' build of Wine using just Wine code on MacOSX is not possible. There are dependencies, just like there are on Linux. The X11SDK is not installed and that is just a start... And Mike's builds are LGPL, just like Wine's. James McKenzie
participants (14)
-
André Hentschel -
Austin English -
Brian Vincent -
David Gerard -
Dmitry Timoshkov -
Emmanuel Maillard -
James McKenzie -
Joerg-Cyril.Hoehle＠t-systems.com -
Juan Lang -
Ladenlokal Velbert -
Maik Schulz
-
Mike Kronenberg -
Roderick Colenbrander -
Steven Edwards