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

Implications for Wine from the Ubuntu Developer Summit

by Scott Ritchie

Hello everyone, I've just returned from the Ubuntu Developer Summit in Barcelona last week. A lot of interesting stuff that concerns Wine happened there, and a lot of applies to every distro. I'll give a brief summary in this email. Audio: First, I talked with a Pulseaudio expert about what we can do to make things work better. He said that if we want good compatibility we will need our ALSA stack to use the Pulseaudio safe subset: http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a metabug tracking this here: http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset can cause most problems with stuttering or even complete dropoff. I'm not completely familiar with how sound works in Wine, but in the past I remember that one complaint about PulseAudio over ALSA was latency. Latency issues these days are mostly due to bad kernel configurations, which Lennart wrote about here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150…. In the meantime we should develop for the future using kernels with preempt enabled at 1000 HZ. Currently neither Open SuSE nor Ubuntu are configured this way, however I know in the case of Ubuntu that this is being fixed for next release. In particular, if you develop on Ubuntu, you should either upgrade to Karmic Alphas or install a custom kernel. The -rt flavor of the kernel is known to have problems as well. Printing: A printing expert from http://openprinting.org says we should output .pdf files to cups rather than postscript. .pdf are becoming the standard for printers, and apparently they allow some good things that postscript does not. I've filed a bug on this here: http://bugs.winehq.org/show_bug.cgi?id=18741 Security and Usability: The security team thinks we should finally start respecting the execute bit - this means removing all MIME handlers for executable code from the desktop and replacing them with a single front end for programs lacking the execute bit. This front end would notify the user of the problem, scan the file for viruses, and then present some information about the path towards execution. It is still undecided whether the program should allow execution outright, however from a UI perspective this would clearly be more efficient. This creates a design challenge. In brief, we have to simultaneously manage expectations about Wine, inform the user that there are other (preferred) methods for installing software, not patronize them for installing a Windows program, tell them we scanned a file for viruses but that it may still be unsafe, make it easy to use, and make it hard to use accidentally. After input from the community and discussion with other designers, I believe I have some good ideas for how to handle these challenges. The Canonical design team has agreed to integrate the UI extensions I've gathered into their weekly user testing, so over the next few months we should be getting some real feedback on the merits of various approaches to this problem. I'll be working more on this personally, and already have a good chunk of the specifications and front end code done (thanks to some great community help). I will, of course, share it here when it's in a usable state. As far as we, as an upstream, are concerned, there's not much to change in Wine itself other than to keep making it work better and fix bugs. If I had to name one in particular, I'd have to say the "unclean removal of applications menu" entries is a particularly confusing issue for users. What I'm doing: Over the next few months I'm going to be working rather hard on the Karmic Wine Integration spec that I lead at the Summit: https://wiki.ubuntu.com/karmic-wine-integration. I'm still drafting the spec based on my notes and discussion, but at this point I have a very good idea of what I want to do. Most of the code involved is directly relevant to the Wine user, however almost none of it needs to go into Wine itself other than some icons. At this point it's mostly python scripts, modifications of other python programs, and Glade dialogs. I may set up a BZR/Git repository of the various bits once they start turning into actual packages (which I'll also be doing). Anyway, keep your eyes peeled, the next wave of distro releases are going to be very slick. Thanks, Scott Ritchie

June 2, 2009

Re: gdiplus: Stub for GdipCloneBitmapArea

by Vincent Povirk

Don't bother adding "stub" to existing FIXME's. If it's a FIXME with arguments, we know it's a stub. Vincent Povirk On Mon, Jun 1, 2009 at 8:01 PM, Andrew Eikum<andrew(a)brightnightgames.com> wrote: > Stubbing GDI+: > Add stub function for GdipCloneBitmapArea. Also add missing > prototype for GdipCloneBitmapAreaI, and add stub note to > FIXME in GdipCloneBitmapAreaI stub function. > --- > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/image.c | 10 +++++++++- > include/gdiplusflat.h | 2 ++ > 3 files changed, 12 insertions(+), 2 deletions(-) > > > >

June 2, 2009

Re: gdi32: Stub for GdiEntry13()

by Vincent Povirk

> I think you should add @ stdcall DdQueryDisplaySettingsUniqueness() line > to gdi32.spec file, otherwise you will get message like this: > err:module:find_forwarded_export function not found for forward > 'gdi32.DdQueryDisplaySettingsUniqueness' used by L"C:\\windows\\system32 > \\gdi32.dll". If you are using builtin L"gdi32.dll", try using the > native one instead. I just checked the gdi32 on Windows XP. It has no export named DdQueryDisplaySettingsUniqueness, only GdiEntry13. I think this was not meant to be a forwarded export, just an export with a different name. If so, the "gdi32." should be removed.

June 2, 2009

Re: gdi32: Stub for GdiEntry13()

by Kovács András

Hi, I think you should add @ stdcall DdQueryDisplaySettingsUniqueness() line to gdi32.spec file, otherwise you will get message like this: err:module:find_forwarded_export function not found for forward 'gdi32.DdQueryDisplaySettingsUniqueness' used by L"C:\\windows\\system32 \\gdi32.dll". If you are using builtin L"gdi32.dll", try using the native one instead. Best regards, Andras 2009. 06. 2, kedd keltezéssel 01.37-kor Nikolay Sivov ezt írta: > Requested in bug http://bugs.winehq.org/show_bug.cgi?id=18638 > > Changelog: > - Stub for GdiEntry13() > > >From 860bd34f2f0927c306a3f58825ffe46981b522bf Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Tue, 2 Jun 2009 01:27:30 +0400 > Subject: Stub for GdiEntry13 > > --- > dlls/gdi32/driver.c | 11 +++++++++++ > dlls/gdi32/gdi32.spec | 1 + > 2 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/driver.c b/dlls/gdi32/driver.c > index 20d3f36..8a3c7ed 100644 > --- a/dlls/gdi32/driver.c > +++ b/dlls/gdi32/driver.c > @@ -741,3 +741,14 @@ INT WINAPI NamedEscape( HDC hdc, LPCWSTR pDriver, INT nEscape, INT cbInput, LPCS > lpszOutData); > return 0; > } > + > +/******************************************************************* > + * DdQueryDisplaySettingsUniqueness [GDI32.@] > + * GdiEntry13 [GDI32.@] > + */ > +ULONG WINAPI DdQueryDisplaySettingsUniqueness(VOID) > +{ > + FIXME("stub\n"); > + > + return 0; > +} > diff --git a/dlls/gdi32/gdi32.spec b/dlls/gdi32/gdi32.spec > index 36a8fb1..a50f763 100644 > --- a/dlls/gdi32/gdi32.spec > +++ b/dlls/gdi32/gdi32.spec > @@ -174,6 +174,7 @@ > # @ stub GdiDrawStream > # @ stub GdiEndDocEMF > # @ stub GdiEndPageEMF > +@ stdcall GdiEntry13() gdi32.DdQueryDisplaySettingsUniqueness > # @ stub GdiFixUpHandle > @ stdcall GdiFlush() > # @ stub GdiFullscreenControl

June 2, 2009

Re: [PATCH 5/5] wininet: Test gzip encoded read.

by Jacek Caban

Hi Paul, Paul Vriens wrote: > Jacek Caban wrote: >> --- >> dlls/wininet/tests/http.c | 107 >> ++++++++++++++++++++++++++++++++++---------- >> 1 files changed, 82 insertions(+), 25 deletions(-) >> >> >> >> ------------------------------------------------------------------------ >> >> > Hi Jacek, > > This patch introduces test failures on all platforms: > > 1 failure with IE7 > 1 new failure with IE8 (there was 1 with IE8 before this patch) These were passing for me because I had stored cookies. > 5 failures with IE6 INTERNET_OPTION_HTTP_DECODING is supported on IE >6. > > Could you have a look (test.winehq.org)? Thanks for notification, I've sent a fix. Thanks, Jacek

June 1, 2009

Re: [PATCH 5/5] wininet: Test gzip encoded read.

by Paul Vriens

Jacek Caban wrote: > --- > dlls/wininet/tests/http.c | 107 > ++++++++++++++++++++++++++++++++++---------- > 1 files changed, 82 insertions(+), 25 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, This patch introduces test failures on all platforms: 1 failure with IE7 1 new failure with IE8 (there was 1 with IE8 before this patch) 5 failures with IE6 Could you have a look (test.winehq.org)? -- Cheers, Paul.

June 1, 2009

Re: Patchwatcher not reporting failures?

by André Hentschel

Zachary Goldberg schrieb: > On Mon, Jun 1, 2009 at 5:34 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Testing patchwatcher with a patch that simply removes two todo_wine's >> should've caused some failures. Indeed, looking at the log: >> cred.c:315: Test failed: expected CredentialBlobSize of 0 but got 20 >> cred.c:315: Test failed: expected NULL credentials but got 0x11d4ec >> cred.c:328: Test failed: expected CredentialBlobSize of 0 but got 20 >> cred.c:328: Test failed: expected NULL credentials but got 0x11d4d0 >> >> it did. But patchwatcher shows an 'OK'. Can you take a look? >> >> -- >> -Austin >> > > Indeed. I reset it, re ran your patch again and its still passing. > Unfortunately I cannot debug it today so I turned it off (so as to not > give people false data). Hopefully I'll find time to fix it before > Wednesday otherwise sadly it won't be back for another 2 weeks when > I'm back from vacation. > > -Zach > > the logs say that it never compiles completely: > make[2]: Leaving directory `/home/wine/patchwatcher-ro/wine-continuous-workdir/active/dlls/xinput1_3/tests' > make[1]: Target `test' not remade because of errors. > make[1]: Leaving directory `/home/wine/patchwatcher-ro/wine-continuous-workdir/active/dlls' > make: *** [dlls/__test__] Error 2 > make: Target `test' not remade because of errors. > Patchwatcher: difference versus baseline: > Patchwatcher: no new errors! > Patchwatcher:ok

June 1, 2009

Re: Patchwatcher not reporting failures?

by Zachary Goldberg

On Mon, Jun 1, 2009 at 5:34 AM, Austin English <austinenglish(a)gmail.com> wrote: > Testing patchwatcher with a patch that simply removes two todo_wine's > should've caused some failures. Indeed, looking at the log: > cred.c:315: Test failed: expected CredentialBlobSize of 0 but got 20 > cred.c:315: Test failed: expected NULL credentials but got 0x11d4ec > cred.c:328: Test failed: expected CredentialBlobSize of 0 but got 20 > cred.c:328: Test failed: expected NULL credentials but got 0x11d4d0 > > it did. But patchwatcher shows an 'OK'. Can you take a look? > > -- > -Austin > Indeed. I reset it, re ran your patch again and its still passing. Unfortunately I cannot debug it today so I turned it off (so as to not give people false data). Hopefully I'll find time to fix it before Wednesday otherwise sadly it won't be back for another 2 weeks when I'm back from vacation. -Zach

June 1, 2009

Re: gdiplus: GdipDrawString

by Stephan Rose

>I don't know why gdiplus does its own linebreaks. I haven't really >done any work in that area. > >If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no >equivalent flag for DrawText. That probably means you can't pass it >off to DrawText. > >Since they'll probably have to be done differently, it's best to >implement one direction at a time. When you're happy with horizontal >alignment, you can send a patch for that regardless of the status of >vertical alignment. > >You should be able to use GdipMeasureString to get the size of the >text. In fact, the alignments will need to be implemented there too, >and it may be better to start there. Hmm the only way I can see alignments having any influence on MeasureString would be if the boundingBox of the text is to be aligned to the layoutRect based on the alignment flags. Should just be able to then take the calculated bounding rect and align that to the layout based on the flags. And you're right, if I use MeasureString I solve my issue where I don't know the height of the text ahead of time. Perfect. Thanks, Stephan

June 1, 2009

Re: gdiplus: GdipDrawString

by Vincent Povirk

I don't know why gdiplus does its own linebreaks. I haven't really done any work in that area. If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no equivalent flag for DrawText. That probably means you can't pass it off to DrawText. Since they'll probably have to be done differently, it's best to implement one direction at a time. When you're happy with horizontal alignment, you can send a patch for that regardless of the status of vertical alignment. You should be able to use GdipMeasureString to get the size of the text. In fact, the alignments will need to be implemented there too, and it may be better to start there. Vincent Povirk

June 1, 2009