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

[André Hentschel]

[e-mail] 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 
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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Juan Lang]

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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Maik Schulz]

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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Dmitry Timoshkov]

"Maik Schulz"  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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Ladenlokal Velbert]

On 26 Jun 2009, at 10:29, Dmitry Timoshkov wrote:
> "Maik Schulz"  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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Austin English]

On Thu, Jun 25, 2009 at 8:56 AM,  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.).

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Roderick Colenbrander]

On Thu, Jun 25, 2009 at 10:06 PM, Austin English wrote:
> On Thu, Jun 25, 2009 at 8:56 AM,  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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Austin English]

On Fri, Jun 26, 2009 at 5:00 AM, Roderick
Colenbrander 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).

why is Kronenberg's Wine/Mac work blacklisted on winehq?

> 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Maik Schulz]

On 29 Jun 2009, at 14:10,  <[e-mail]
> 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[James McKenzie]

[e-mail] 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[James McKenzie]

[e-mail] 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Dmitry Timoshkov]

 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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Emmanuel Maillard]

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 :
>  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...
> - 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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Dmitry Timoshkov]

"Emmanuel Maillard"  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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Steven Edwards]

On Fri, Jun 26, 2009 at 10:51 AM, Dmitry
Timoshkov 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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Roderick Colenbrander]

On Fri, Jun 26, 2009 at 9:42 PM, Steven Edwards wrote:
> On Fri, Jun 26, 2009 at 10:51 AM, Dmitry
> Timoshkov 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Steven Edwards]

On Fri, Jun 26, 2009 at 4:36 PM, Roderick
Colenbrander 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Austin English]

On Fri, Jun 26, 2009 at 3:36 PM, Roderick
Colenbrander 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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[David Gerard]

2009/6/27 Austin English :
> On Fri, Jun 26, 2009 at 3:36 PM, Roderick
> Colenbrander 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.

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Austin English]

On Fri, Jun 26, 2009 at 7:10 PM, David Gerard wrote:
> 2009/6/27 Austin English :
> > On Fri, Jun 26, 2009 at 3:36 PM, Roderick
> > Colenbrander 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 :-).

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Mike Kronenberg]

On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:
> "Emmanuel Maillard"  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 ;)

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[Brian Vincent]

On Fri, Jun 26, 2009 at 2:42 PM, Mike Kronenberg <
[e-mail]> 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

why is Kronenberg's Wine/Mac work blacklisted on winehq?

[James McKenzie]

Mike Kronenberg wrote:
> On 26.06.2009, at 16:51, Dmitry Timoshkov wrote:
> > "Emmanuel Maillard"  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