July 2009 - Wine-Devel - list.winehq.org

Re: ntdll: For Darwin/Mac OS X, use legacy getdirentries if 64-bit inodes enabled.

by Ken Thomases

On Jul 31, 2009, at 5:15 PM, Austin English wrote: > On Fri, Jul 31, 2009 at 4:25 PM, Ken Thomases<ken(a)codeweavers.com> > wrote: >> >> Fixes building on Snow Leopard. >> --- >> dlls/ntdll/directory.c | 30 ++++++++++++++++++++++++++++++ >> 1 files changed, 30 insertions(+), 0 deletions(-) > > FWIW, NetBSD has a similar bug > (http://bugs.winehq.org/show_bug.cgi?id=18166) but AJ refused the > patch, saying NetBSD should fix it on their end. Well, Alexandre was consulted on this approach, although not this specific patch. In part, I think NetBSD suffers because he has higher expectations. He's basically written Apple off, entirely. ;) Cheers, Ken

July 31, 2009

Re: How far away are we from .net 3.0 install working?

by Dan Kegel

On Fri, Jul 31, 2009 at 3:41 PM, Austin English<austinenglish(a)gmail.com> wrote: > On Fri, Jul 31, 2009 at 5:29 PM, Dan Kegel<dank(a)kegel.com> wrote: >> >> says that the offline installer for .net 3.0 works >> fine with that one patch, but it didn't seem to work >> when I tried it. Anyone know what the story is? > > The AppDB has a pretty good overview (AF keeps a close eye on it): > http://appdb.winehq.org/objectManager.php?sClass=version&iId=9828 > from the looks of it, you need to hack around several bugs to get > anywhere near working. He does put lots of info there, but he doesn't actually list which bugs are showstoppers for install. I suspect he won't put a simple recipe there until the showstoppers are finished, and supposedly the only showstopper left is LsaLookupNames2, according to comments in http://www.winehq.org/pipermail/wine-patches/2009-June/074701.html http://bugs.winehq.org/show_bug.cgi?id=16882 and http://bugs.winehq.org/show_bug.cgi?id=16884 But I didn't have any joy when I tried it, hence my question. - Dan

July 31, 2009

Re: How far away are we from .net 3.0 install working?

by Austin English

On Fri, Jul 31, 2009 at 5:29 PM, Dan Kegel<dank(a)kegel.com> wrote: > http://www.winehq.org/pipermail/wine-patches/2009-June/074701.html > says that the offline installer for .net 3.0 works > fine with that one patch, but it didn't seem to work > when I tried it. Anyone know what the story is? The AppDB has a pretty good overview (AF keeps a close eye on it): http://appdb.winehq.org/objectManager.php?sClass=version&iId=9828 from the looks of it, you need to hack around several bugs to get anywhere near working. -- -Austin

July 31, 2009

How far away are we from .net 3.0 install working?

by Dan Kegel

http://www.winehq.org/pipermail/wine-patches/2009-June/074701.html says that the offline installer for .net 3.0 works fine with that one patch, but it didn't seem to work when I tried it. Anyone know what the story is? - Dan

July 31, 2009

Re: ntdll: For Darwin/Mac OS X, use legacy getdirentries if 64-bit inodes enabled.

by Austin English

On Fri, Jul 31, 2009 at 4:25 PM, Ken Thomases<ken(a)codeweavers.com> wrote: > > Fixes building on Snow Leopard. > --- > dlls/ntdll/directory.c | 30 ++++++++++++++++++++++++++++++ > 1 files changed, 30 insertions(+), 0 deletions(-) FWIW, NetBSD has a similar bug (http://bugs.winehq.org/show_bug.cgi?id=18166) but AJ refused the patch, saying NetBSD should fix it on their end. -- -Austin

July 31, 2009

WGL: fix usage of non-GLX visual in glXCreateContext

by Roderick Colenbrander

Hi, We should not expect that the default Wine visual supports GLX, use glXChooseVisual instead. This should fix bug 19570. Regards, Roderick Colenbrander

July 31, 2009

Re: WINE and iTunes

by Nikolay Sivov

Stephen Eilert wrote: > I have seen patches in that bug report to add the firewall stubs. Is > there any problem with those patches? http://www.winehq.org/pipermail/wine-devel/2009-July/077523.html This explains it. Next commits should start on Monday 3rd. > > Or, more to the point, is there any way I could contribute? I am not > too familiar with the firewall API or Marteen's work, but I am sure > that can be mitigated with some study :) Looks like in this particular iTunes case stub is enough. It needed only to make msi installation procedure happy obtaining firewall api interfaces. Anyway contributors are more than welcome here. Just start with developer section of WinHQ.org and choose area you're interested in. Feel free to ask here where help is needed if in doubt. Regards. > > I might have found my personal Wine itch to scratch :) > > > --Stephen > > programmer, n: > A red eyed, mumbling mammal capable of conversing with > inanimate monsters.

July 31, 2009

Re: WINE and iTunes

by Stephen Eilert

I have seen patches in that bug report to add the firewall stubs. Is there any problem with those patches? Or, more to the point, is there any way I could contribute? I am not too familiar with the firewall API or Marteen's work, but I am sure that can be mitigated with some study :) I might have found my personal Wine itch to scratch :) --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters. On Wed, Jul 29, 2009 at 9:21 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > 2009/7/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > > According to appdb there is indeed some small installer regressions > > and for that some hack is posted there (see > > http://appdb.winehq.org/objectManager.php?sClass=version&iId=14793) > > Using this hack the program apparently installs and runs. The main > > limitation is that we don't have USB support for ipod/iphone > > synchronization. Maarten Lankhorst worked a bit on that last year but > > his work needs to be finished and cleaned up. Fixing the msi issue > > might be easy but it requires writing of a small msi test case I > > think. > > It is failing because the installer is running a custom action that is > trying to update the Windows firewall configuration (see > http://bugs.winehq.org/show_bug.cgi?id=15533) So this isn't an error > specific to MSI -- MSI is doing the right thing here. > > Particularly: > > ------- Comment #10 From Reece Dunn 2009-01-06 11:30:58 ------- > > MSI error 1603 is a generic "something went wrong" error. > > WiX is an open source MSI installer creator by Microsoft, available on > sourceforge. Using the power of Google, I suspect that this functionality > is > mentioned in > http://www.joyofsetup.com/2008/05/17/new-wix-feature-firewall-extension/. > > It looks like iTunes is trying to query the Windows Firewall services and > is > failing because Wine does not implement this interface yet (bug 15563, bug > 12876 and others). > > Do you know if the logs mention trying to CoCreate > {304ce942-6e39-40d8-943a-b913c40c9cd4} (CSLID_NetFwMgr)? If it does, then > this > seems the most likely scenario. > > ------- Comment #11 From Cheba 2009-01-07 17:04:20 ------- > > (In reply to comment #10) > > Do you know if the logs mention trying to CoCreate > > {304ce942-6e39-40d8-943a-b913c40c9cd4} (CSLID_NetFwMgr)? If it does, then > this > > seems the most likely scenario. > > Yes it tries. I see this lines in terminal: > > err:ole:CoGetClassObject class {304ce942-6e39-40d8-943a-b913c40c9cd4} not > registered > err:ole:CoGetClassObject no class object > {304ce942-6e39-40d8-943a-b913c40c9cd4} > could be created for context 0x1 > > ------ > > NOTE: It appears that other applications are failing for similar > reasons (lack of firewall API implementation in Wine). AFAIU, the API > implementation does not actually need to do anything, it just needs to > be sufficiently stubbed to allow the applications that are using it to > succeed. > > - Reece > > >

July 31, 2009

Re: New Wine Gecko 1.0.0 RC

by Austin English

On Wed, Jul 29, 2009 at 10:01 AM, Jacek Caban<jack(a)itma.pwr.wroc.pl> wrote: > Hi, > > It's time for the new Wine Gecko package release. I've prepared a new > package based on Mozilla code a bit newer than Firefox 3.5 and my fixes > (most of them are on their way to mainstream Mozilla repository). This > release fixes a few known bugs. It's not as big change as 0.9.0 release was, > so I don't expect that many problems. Last time we had a few serious > regressions and I'd like to avoid them now. That's why I'd like to ask you > for help in testing (last time I did too, but somehow we've missed serious > problems). To use it, just apply the attached patch, download the build > from: > > http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko-1.0.0.cab > > and place it in correct location according to (note s/0.9.1/1.0.0/): > > http://wiki.winehq.org/Gecko > > Everything that uses MSHTML is interesting for testing. Please let me know > about any regression. Everything worked in appinstall (though, there's not too much stuff using gecko there..) -- -Austin

July 31, 2009

Re: gdi32: Ensure child fonts have names

by Aric Stewart

Thanks, resent. -aric Dmitry Timoshkov wrote: > "Aric Stewart" <aric(a)codeweavers.com> wrote: > >> load_child_font calls neither WineEngCreateFontInstance nor >> GetEnumStructs. >> >> It allocates the the child font structure above in the function sets >> the few fields it thinks it needs and then goes on. I see no evidence >> that it is being expected to have been set at any other point. > > Then child->font->name should be initialized explicitly, 'if ()' check > is redundant. Setting it to child->font->font_desc.lf.lfFaceName looks > also incorrect, other places set it to face->family->FamilyName. >

July 31, 2009