September 2007 - Wine-Devel

Re: Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

> > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless > > window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK > > without it. > > If you mean the following line in > dlls/winex11.drv/window.c,X11DRV_set_wm_hints() > > else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= > MWM_DECOR_BORDER; > > then you can always send a patch with an explanation why it's needed. Of course, I can send a patch, which just removes this line with some explanations (referring to winamp), but I'm afraid it may break something. Since original patch introduced this code, there is an application which depends on this. But that original patch does not contain any hint, so I ask the list in hope somebody might know the reason. -- Kirill

1 0

Re: mlang: fix memory leaks in error paths (found by Smatch).
by Lionel_Debroux Sept. 24, 2007

Sept. 24, 2007

Lionel_Debroux wrote: > EnumRfc1766_create leaks some heap memory in two error paths. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/mlang/mlang.c: > mlang: fix memory leaks in error paths (found by Smatch). > > > > ------------------------------------------------------------------------ > >>From 394f63633148d76fa322b726218e8a824e5a3930 Mon Sep 17 00:00:00 2001 > From: Lionel Debroux <lionel_debroux(a)yahoo.fr> > Date: Mon, 24 Sep 2007 14:12:10 +0200 > Subject: mlang: fix memory leaks in error paths (found by Smatch). > > --- > dlls/mlang/mlang.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index b5b8e0d..eb14ad0 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -1885,7 +1885,11 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > data.total = 0; > data.allocated = 32; > data.info = HeapAlloc(GetProcessHeap(), 0, data.allocated * sizeof(RFC1766INFO)); > - if (!data.info) return S_FALSE; > + if (!data.info) > + { > + HeapFree(rfc); > + return S_FALSE; > + } > > TlsSetValue(MLANG_tls_index, &data); > EnumSystemLocalesW(enum_locales_proc, 0/*LOCALE_SUPPORTED*/); > @@ -1893,7 +1897,12 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > > TRACE("enumerated %d rfc1766 structures\n", data.total); > > - if (!data.total) return FALSE; > + if (!data.total) > + { > + HeapFree(data.info); > + HeapFree(rfc); > + return FALSE; > + } > > rfc->info = data.info; > rfc->total = data.total; Err, screw that. The two first parameters "GetProcessHeap(), 0, " of the three HeapFree calls are missing... I did not forget to launch a make process to check my modifications were correct, though. What happened was that everything was recompiled, and by the time the compiler complained, I had already sent the mails by mistake... Sorry. Lionel Debroux.

1 0

Re: Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > I'm trying to get winamp playlist window to be painted correctly (bug > > #8300). The problem is: > > 0) wine version is git-current. > > 1) winamp playlist window style is WS_CLIPSIBLINGS > > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > > 3) This hint behaviour is WM-dependent: > > a) KDE - caption is painted; > > b) XFCE - ditto; > > c) fluxbox - correct (no caption). > > > > This situation confuses a little. I believe DECOR_BORDER does not add a > > caption to window, but it does under great WM such as KDE. Is this > > behaviour correct? If KDE/XFCE is a culprit, should we add a workaround > > into wine? > > There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. > If this is proved to be a KDE/XFCE bug it should be reported to an > appropriate bug tracking system. It's better to write pure X11 app to demonstate it, but I am not familiar with it :-( Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. -- Kirill

2 1

Re: pdh: add tests for XP variant of api call
by Hans Leidekker Sept. 24, 2007

Sept. 24, 2007

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c To prevent you doing any duplicate work, I have implementations of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and PdhValidatePath{,Ex} in my tree, along with a range of tests. -Hans

2 1

Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

Hi, I'm trying to get winamp playlist window to be painted correctly (bug #8300). The problem is: 0) wine version is git-current. 1) winamp playlist window style is WS_CLIPSIBLINGS 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) 3) This hint behaviour is WM-dependent: a) KDE - caption is painted; b) XFCE - ditto; c) fluxbox - correct (no caption). This situation confuses a little. I believe DECOR_BORDER does not add a caption to window, but it does under great WM such as KDE. Is this behaviour correct? If KDE/XFCE is a culprit, should we add a workaround into wine? Thanks for attention -- Kirill

2 1

Is ICU no longer a dependency of Wine?
by Scott Ritchie Sept. 24, 2007

Sept. 24, 2007

I stumbled across this patch while browsing recent commits: http://www.winehq.org/pipermail/wine-cvs/2007-September/036309.html Am I correct to say that we no longer need libicu when compiling Wine? By the way, it would be nice if someone shot off an email to wine-devel whenever the build dependencies change (either removing or adding a lib) -- it makes it a lot easier on we package maintainers. Thanks, Scott Ritchie

2 1

Re: [2/5] WineD3D: Recompile glsl pixelshaders if the sampler format changes
by Vitaliy Margolen Sept. 24, 2007

Sept. 24, 2007

Stefan Dösinger wrote: > > ------------------------------------------------------------------------ > > This patch causes noticeable slowdown in Counter Strike Source stress test in the first part of it (rotating panels). Testing in dxlevel 80, 1024x768 fbo, cl_monitors 0. I'm getting ~33 fps in that area before patch and around 7 fps with this patch. Vitaliy.

2 1

strange pixel format
by Jose Osvaldo Sept. 24, 2007

Sept. 24, 2007

The No-CD crack for "The Sims" calls to "IDirectDrawImpl_CreateSurface" (ddls/ddraw.c) which calls to "IDirectDrawImpl_CreateNewSurface". One of these calls passes a abnormal value for DDPixelFormat causing "PixelFormat_DD2WineD3D" (dlls/utils.c) to return "WINED3DFMT_UNKNOWN" (0). "IDirectDrawImpl_CreateNewSurface" returns immediately causing the program to fail by raising an exception. In this case, forcing the "IDirectDrawImpl_CreateNewSurface" function to continue with other pixel format, even a not defined one, avoids the exception and "The Sims" starts. The abnormal value is this: dwFlags = 0x00000000 dwSize = 32 dwFourCC = 0x00000000 u1 = 0x00000000 u2 = 0x00000000 u3 = 0x00000000 u4 = 0x00000000 u5 = 0x00000000 I do not know what is the expected behaviour in real Windows. The original executable file crashes with other error, but I think that is caused by the anticopy protection.

2 1

Re: [4/5] WGL: Remove GL scissors/viewport override
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > > ------------------------------------------------------------------------ > This patch causes crash with virtual desktop. Crash attached. Vitaliy.

2 2

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > This uses XComposite, when available, to render GL to an offscreen window, and > updates the win32 window when glFlush/glFinish/SwapBuffers is called. When > rendering to a top-level window with a matching visual, it renders > directly "onscreen", and setting the registry key > HKCU\Software\Wine\X11 Driver\CompositeGL > to false will disable GL compositing behavior even when XComposite is > available (default is enabled). > > Same here, default should be disabled. Do not introduce more regressions in something already broken by default. And don't punish something that works perfectly without anything extra. Vitaliy.

2 1