May 2008 - Wine-Devel - list.winehq.org

Re: winex11.drv: Avoid setting DIALOG type to windows, this imposes not expected limitations in functionality

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Metacity explicitly disables maximize, minimize and fullscreen capabilities > for windows of type _NET_WM_WINDOW_TYPE_DIALOG. Since Windows applications > don't expect such a restriction (dialogs can have maximize/minimize buttons > under Windows) it's better to avoid setting DIALOG type to windows at all. This will break z-order management, Metacity ignores the transient for hint on TYPE_NORMAL windows. Maybe we should try to not set the type at all? -- Alexandre Julliard julliard(a)winehq.org

May 1, 2008

Re: usp10: Fix a few tests that fail in win2k3

by Hans Leidekker

On Thursday 01 May 2008 08:30:40 James Hawkins wrote: > + /* get new psc */ > + hr = ScriptPlace(hdc, &psc, pwOutGlyphs1, pcGlyphs, psva, &pItem[0].a, piAdvance, > + pGoffset, pABC); > + ok (hr == 0, "Should return 0 not (%08x)\n", hr); > + ok (psc != NULL, "psc should not be NULL\n"); > /* Set that is gets a psc and that returns 0 status */ > hr = ScriptTextOut(hdc, &psc, 0, 0, 0, NULL, &pItem[0].a, NULL, 0, pwOutGlyphs1, pcGlyphs, > piAdvance, NULL, pGoffset); test.winehq.org shows that this ScriptTextOut test fails on all versions of Windows and succeeds on Wine, so a better fix would be to reverse the check for psc and make Wine pass the test. The fix depends on Guy Albertelli's recent fix for ScriptTextOut, I'll send a patch after that one has been committed. -Hans

May 1, 2008

Re: [PATCH 4/5] kernel32: implement __wine_kernel_init_environment.

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > This makes several internal kernel32 process functions more flexible > in order to accommodate __wine_kernel_init_environment. > __wine_kernel_init_environment is needed for CreateEnvironmentBlock. It's not appropriate to export that from kernel32; userenv should use only standard APIs. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2008

Re: RFC: detecting wine drivers in the audio tests

by Stefan Dösinger

I just wanted to add that exactly the same problem exists with graphics drivers. There, we use approximately this scheme: -> If there's a driver difference, and both driver behaviors are somewhat sane, then we accept both results. An application couldn't depend on a specific result either -> If the behavior of one driver is not sane, and the functionality tested is somewhat exotic(e.g. fixed function vertex processing with non-standard attribute types), then we accept the failure as well if there is no known application that uses the feature -> If a feature is obviously broken and it is a more common feature(e.g. texdepth or texkill on a Radeon 9000), then I just let the test fail on Windows; any game that uses those features will fail as well. (Luckily for the card no ps_1_4 game uses texdepth and texkill; only later ones do) The reference rasterizer is just another "driver" for me. There are some behaviors in per-MSDN undefined cases where the refrast shows a behavior that is known to cause problems with a game. In that case we let it fail on the refrast as well. The Intel and VMware drivers aren't drivers I care for because many games are known to fail on them on Windows. Whenever a test is known to fail I add a comment to the test implementation.

May 1, 2008

Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.

by Dan Kegel

James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > Dan Kegel wrote: > > And we can probably make high-res users happier still > > by defaulting to Xft.dpi (used by Gnome and maybe KDE; > > it's set by default to 96, but is increased by some users > > of high-res displays). > > > This will break Darwine. Xft.dpi does not exist on Apple's X11 > implementation. Wouldn't break Wine on MacOSX at all. We wouldn't do it there. - Dan

May 1, 2008

Re: wineserver socket file and DOS attacks

by Ove Kaaven

Maarten Lankhorst skrev: > Wine checks ownership of the socket and directory, so race conditions > aren't really a problem. This means that despite being put in a public > directory there is no chance of a race condition. I don't see a > security risk here, if someone is evil they could create that > directory so wine wouldn't run, but that harm is only restricted to > 'wine does not start'. Which is exactly what the OP was concerned about.

May 1, 2008

Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.

by James McKenzie

Dan Kegel wrote: > And we can probably make high-res users happier still > by defaulting to Xft.dpi (used by Gnome and maybe KDE; > it's set by default to 96, but is increased by some users > of high-res displays). > > This will break Darwine. Xft.dpi does not exist on Apple's X11 implementation. James McKenzie

May 1, 2008

Re: wineserver socket file and DOS attacks

by Maarten Lankhorst

Hell Ove, 2008/4/30 Ove Kaaven <ovek(a)arcticnet.no>: > Maarten Lankhorst skrev: > > > > The latter won't work, they could create the directory and then delete > > it after wineserver started. I don't think it is really a problem, by > > the time someone else can put that directory in /tmp chances are that > > they can do a lot more malicious things then just making Wine refuse > > to run. > > > > Like what? The UNIX user/permission system, including the sticky bit used > on /tmp, is supposed to protect local users against each other, but this is > contingent on files created in /tmp using unique names (like what mktemp > generates). There's very little else malicious people can do if the system > is otherwise properly set up in a secure fashion, and this socket-in-/tmp > thing sounds like a quite legitimate concern. Wine checks ownership of the socket and directory, so race conditions aren't really a problem. This means that despite being put in a public directory there is no chance of a race condition. I don't see a security risk here, if someone is evil they could create that directory so wine wouldn't run, but that harm is only restricted to 'wine does not start'. Cheers, Maarten.

May 1, 2008

Re: Wine t-shirts?

by Maarten Lankhorst

Hi, 2008/4/23 Jeremy White <jwhite(a)winehq.org>: > > http://kegel.com/wine/wine-penguin-corkscrew.png > > Jon Parshall is proud of his ability to draw those penguins, > and we'd gladly send that artwork to anyone that wanted to make a T-shirt. > > Note, though, that we felt we had to (very sadly) drop the penguin; it doesn't > really work for Mac users. Or the bsd users. It seems it is increasingly popular to use wine in bsd also. Still, can I have the artwork? Cheers, Maarten.

May 1, 2008