September 2007 - Wine-Devel

Re: shell32[1/2]: shlview: make the shell view control Unicode (fixesbuf #9767)
by Dmitry Timoshkov Sept. 26, 2007

Sept. 26, 2007

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > When the control class is Unicode the listview will be sending > LVN_GETDISPINFOW instead of LVN_GETDISPINFOA and filenames with > charactes outside of the ACP will display properly. > I'm changing the type of a define from the include/ directory but > that's a define not present in the Windows SDK. If that define doesn't present in SDK it shouldn't be in Wine either. > --- a/include/shlobj.h > +++ b/include/shlobj.h > @@ -149,7 +149,7 @@ typedef struct > */ > > typedef GUID SHELLVIEWID; > -#define SV_CLASS_NAME ("SHELLDLL_DefView") > +#define SV_CLASS_NAME ((const WCHAR[]){'S','H','E','L','L','D','L','L','_','D','e','f','V','i','e','w',0}) This construct is not portable. Please move this to appropriate source file, and use 'static const WCHAR ...' syntax. -- Dmitry.

1 0

Re: comctl32: remove unneeded todo_wine, because test pass
by James Hawkins Sept. 26, 2007

Sept. 26, 2007

On 9/25/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > I am running make test an a fresh git fetch; git rebase origin and am > getting this: > > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > comctl32_test.exe.so monthcal.c && touch monthcal.ok > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 > make[2]: *** [monthcal.ok] Fehler 1 > > This patch removes the todo_wine.. as it seems to work now. If this > patch gets not accepted, please tell me why. > Becuase it doesn't pass for other people, particularly Julliard; otherwise, it would have been fixed by now. -- James Hawkins

5 4

Wine GSoC 2007 project membership
by Alexander Nicolaysen Sørnes Sept. 25, 2007

Sept. 25, 2007

Hello all, I received a passing evaluation in this year's GSoC, but I was not added to the Wine project hosting for 2007, does anyone here have the power to add me? Alexander N. Sørnes

2 3

Re: user32: Make message test pass cleanly under XP SP2
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > /* posted message */ > PostMessageA( hwnd, WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > > /* posted thread message */ > PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); I'm not sure I see the point of that change, since the message is not tested when PeekMessage fails. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Chris Robinson <chris.kcat(a)gmail.com> writes: > + if(w > 0 && h > 0) { > + XFlush(gdi_display); > + XCopyArea(gdi_display, physDev->gl_drawable, physDev->drawable, > + physDev->gc, 0, 0, w, h, physDev->dc_rect.left, > + physDev->dc_rect.top); Why do you need an XFlush here? > + if(data->whole_window && vis->visualid == XVisualIDFromVisual(visual)) > + { > + TRACE("Whole window available and visual match, rendering onscreen\n"); > + goto done; > + } > + > + if(!composite_gl) > + goto done; There's no sense in having a config option for this since the alternative doesn't work anyway, particularly since you removed the scissor support. > + data->gl_drawable = XCreateWindow(gdi_display, root_window, -w, 0, w, h, > + 0, vis->depth, InputOutput, > + vis->visual, > + CWColormap | CWOverrideRedirect, > + &attrib); The window needs to be created on the thread display, and as a child of the main window. > +static void update_gl_drawable(struct x11drv_win_data *data) > +{ > + unsigned int border, depth; > + int x, y, w, h; > + Window root_win; > + > + if(!data->gl_drawable) > + return; > + > + wine_tsx11_lock(); > + XGetGeometry(gdi_display, data->gl_drawable, &root_win, &x, &y, > + (unsigned int*)&w, (unsigned int*)&h, &border, &depth); You must not use XGetGeometry, this incurs a server round-trip. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Make message test pass cleanly under XP SP2
by Anatoly Lyutin Sept. 25, 2007

Sept. 25, 2007

Dmitry Timoshkov wrote: > Hello, > > Changelog: > user32: Make message test pass cleanly under XP SP2. > > --- > dlls/user32/tests/msg.c | 142 +++++++++++++++++++++++++++++++++------------- > 1 files changed, 102 insertions(+), 40 deletions(-) > > > > @@ -224,51 +226,53 @@ static const struct message WmSwitchChild[] = { > /* Switch MDI child */ > { WM_MDIACTIVATE, sent },/* in the MDI client */ > { WM_WINDOWPOSCHANGING, sent|wparam,SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > + { EVENT_OBJECT_REORDER, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_CHILDACTIVATE, sent },/* in the 1st MDI child */ > /* Deactivate 2nd MDI child */ > - { WM_NCACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_MAXIMIZE }, > /* Preparing for maximize and maximaze the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_STATECHANGED },/* in the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_CHILDACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 1st MDI child */ > + { WM_GETMINMAXINFO, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_STATECHANGED }, /* in the 1st MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { WM_CHILDACTIVATE, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 1st MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_MAXIMIZED }, /* in the 1st MDI child */ > /* Lock redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_NORMALNA }, > /* Restore 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_SHOWWINDOW|SWP_STATECHANGED },/* in the 2nd MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|0x8000 },/* in the 2nd MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + { EVENT_OBJECT_SHOW, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 2nd MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_RESTORED }, /* in the 2nd MDI child */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > /* Redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_NOSIZE|SWP_FRAMECHANGED|SWP_NOMOVE },/* in the MDI frame */ > - { WM_NCCALCSIZE, sent|wparam, 1 },/* in the MDI frame */ > - { WM_WINDOWPOSCHANGED, sent},/* in the MDI frame */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > - { WM_NCACTIVATE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_SETVISIBLE, hook }, > - { WM_KILLFOCUS, sent|defwinproc|optional }, /* in the 2nd MDI child */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 0 }, /* in MDI client */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 1 }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + /* Redraw MDI frame */ > + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE },/* in MDI frame */ > + { WM_NCCALCSIZE, sent|wparam, 1 },/* in MDI frame */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE}, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, /* in the 1st MDI child */ > + { WM_NCACTIVATE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { HCBT_SETFOCUS, hook }, > + { WM_KILLFOCUS, sent|defwinproc }, /* in the 2nd MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 0 },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 1 }, /* in MDI client */ > { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_SETFOCUS, sent },/* in the MDI client */ > - { WM_SETVISIBLE, hook }, > + { HCBT_SETFOCUS, hook }, > { WM_KILLFOCUS, sent },/* in the MDI client */ > - { WM_SETFOCUS, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 0 }, /* in MDI client */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > + { WM_SETFOCUS, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc },/* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, /* in the 1st MDI child */ > { 0 } > }; > Sorry! It falls in my Windows XP SP2 with: msg.c:3267:expected 0009 - actual 0009 msg.c:3267:expected 0008 - actual 0008 msg.c:3267:expected 0281 - actual 0007 msg.c:3267: Test failed: Child did not switch correctly: the msg 0x0281 was expected, but got msg 0x0007 instead msg.c:3268:end of test for switch maximized MDI children -- Best regards Anatoly Lyutin.

2 2

Re: widl [2/6]: Fix conformant array test failures
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This patch gets conformant arrays working in the tests. Currently, only > the address of some conformant arrays are being marshalled, and this wasn't > showing up in the tests because some storage was static. This patch fixes > the problem by writing pointers to conformant array types in the format > string. This also requires handling field pointer conformances, and > expression evaluation routines that expect the containing structure of a > conformant array at the top of the stack, rather than the conformant array > itself. With this patch, the tests still pass, but correctly this time. It breaks the ole32 tests: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c && touch moniker.ok moniker.c:897: Test failed: IRunningObjectTable_EnumRunning hr=800703e6 wine: Unhandled page fault on read access to 0x00000000 at address 0x60527ff6 (thread 0010), starting debugger... WineDbg starting on pid 000f Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x60527ff6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60527ff6 ESP:0033fa90 EBP:0033fe58 EFLAGS:00010206( - 00 - RIP1) EAX:0033fe30 EBX:6054601c ECX:00000000 EDX:00000000 ESI:800703e6 EDI:6053e4ec Stack dump: 0x0033fa90: 00000000 6053e498 800703e6 60542308 0x0033faa0: 0033fe34 00000100 00000000 00000000 0x0033fab0: 60547478 60547474 6053cdc8 0033fe48 0x0033fac0: 0033fe44 0033fe40 0033fe38 0033fe20 0x0033fad0: 6053d190 60542308 0033fe14 6053e720 0x0033fae0: 6053e2dc 60539d74 6053e154 60539de8 Backtrace: =>1 0x60527ff6 func_moniker+0x15f6() [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test (0x0033fe58) 2 0x60538df8 run_test+0x128(name=0x1103ce) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:389] in ole32_test (0x0033fea8) 3 0x6053948d main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:437] in ole32_test (0x0033fed8) 4 0x6053955b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0033ff08) 5 0x7b87446e start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 6 0x600289a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x60527ff6 func_moniker+0x15f6 [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test: movl 0x0(%edx),%ecx 898 hr = IEnumMoniker_QueryInterface(spEM1, &IID_IUnknown, (void*) &lpEM1); Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wtsapi32: add stub for WTSRegisterSessionNotification
by Louis. Lenders Sept. 24, 2007

Sept. 24, 2007

Anything wrong with these simple stubs? http://www.winehq.org/pipermail/wine-patches/2007-September/043944.html and http://www.winehq.org/pipermail/wine-patches/2007-September/043945.html ? --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.

1 0

Re: mlang: fix memory leaks in error path (found by Smatch).
by Tijl Coosemans Sept. 24, 2007

Sept. 24, 2007

On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: > ConvertINetString leaks some heap memory in an error path. 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 path (found by Smatch). > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index eb14ad0..c6274c5 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( > pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); > if (hr != S_OK) > - return hr; > + goto cleanup; > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, &cDstSizeW, pDstStr, pcDstSize); > +cleanup: > HeapFree(GetProcessHeap(), 0, pDstStrW); > return hr; > } This is a bikeshed issue really, but I wonder what Wine's policy on gotos like this is. Imo, it's better to add the HeapFree call to the if block and let the compiler work it out.

3 2

Would like to contribute to wine
by Maciej Kowalczyk Sept. 24, 2007

Sept. 24, 2007

Hi all, I'm looking for subject for my Master's thesis. It might be interesting to do something useful for Wine. On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress. I think it is doable because Windows 2000 and later printer drivers are work in user-space. In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS. Or maybe you have other ideas? Best regards, Maciej Kowalczyk

6 8

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

Re: [1/5] winex11: Load the XComposite extension when available
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > A set of patches to replace the scissors hack with offscreen rendering and > compositing. Step one, look for and load the XComposite extension libs. > > ------------------------------------------------------------------------ > > +int usexcomposite = 1; It should be off by default until users will have enough time to test if it's working properly. Vitaliy.

2 1

Re: shdocvw: Added WebBrowser::FullScreen property implementation.
by Reece Dunn Sept. 23, 2007

Sept. 23, 2007

On 23/09/2007, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/shdocvw/shdocvw.h | 1 + > dlls/shdocvw/tests/webbrowser.c | 23 +++++++++++++++++++++++ > dlls/shdocvw/webbrowser.c | 15 +++++++++++---- > 3 files changed, 35 insertions(+), 4 deletions(-) > + hres = IWebBrowser2_get_FullScreen(wb, &b); > + ok(hres == S_OK, "get_FullScreen failed: %08x\n", hres); > + ok(b == VARIANT_TRUE, "b=%x\n", b); > + > + hres = IWebBrowser2_put_FullScreen(wb, VARIANT_FALSE); > + ok(hres == S_OK, "put_FullScreen failed: %08x\n", hres); > + > IWebBrowser2_Release(wb); This last call to put_FullScreen is missing a get_FullScreen check. Everything else looks ok. - Reece

1 0

Re: [OT] Freemail Terms Of Use [was: Wine autorunner]
by Reece Dunn Sept. 23, 2007

Sept. 23, 2007

On 23/09/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > _________________________________________________________________ > > Connect to the next generation of MSN Messenger > > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= > >wlmailtagline > This is OT regarding this patch, but most people use freemailers, including > hotmail / msn. Some service providers tried to establish some > all-your-copyright-belong-to-us terms of service. Should we take care about > that in any way? Either by making sure that patches aren't sent from such > services, or to make sure that such conditions do not hold up in court? > > I am using gmx myself, and I haven't checked the TOS for changes since years, > and I only gave them a 5 secound look when signing up, so I should start with > checking that myself(I send most patches from my CW address though) Reading the current GoogleMail terms of usage, there is this: "Your Intellectual Property Rights. Google does not claim any ownership in any of the content, including any text, data, information, images, photographs, music, sound, video, or other material, that you upload, transmit or store in your Google Mail account. We will not use any of your content for any purpose except to provide you with the Service." so there is no problem there. Also, the hotmail legal statement has this: "8. Your Materials. You may be able to submit materials for use in connection with the service. Except for material that we license to you, we do not claim ownership of the materials you post or otherwise provide to us related to the service (called a "submission"). However, by posting or otherwise providing your submission, you are granting to the public free permission to: * use, copy, distribute, display, publish and modify your submission, each in connection with the service; * publish your name in connection with your submission; and * grant these permissions to other persons. This section only applies to legally permissible content and only to the extent that use and publishing of the legally permissible content does not breach the law. We will not pay you for your submission. We may refuse to publish, and may remove your submission from the service at any time. For every submission you make, you must have all rights necessary for you to grant the permissions in this section." So you should also be fine there as well, although I do find it interesting that according to this (if I have read it correctly), anything that you send via hotmail is freely usable by the public! - Reece

1 0

Re: Wine autorunner
by Stefan Dösinger Sept. 23, 2007

Sept. 23, 2007

Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. > It will auto-detect the CD drive if not specified on the command line, > auto-detect the mount point, and attempt to mount it if it i not already > mounted. Shouldn't this be implemented in the gnome / kde autorun support? Perhaps in the form of registering a new autorun "mimetype" which tells gnome/kde about autorun.inf files, and how to use them? _________________________________________________________________ > Connect to the next generation of MSN Messenger > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= >wlmailtagline This is OT regarding this patch, but most people use freemailers, including hotmail / msn. Some service providers tried to establish some all-your-copyright-belong-to-us terms of service. Should we take care about that in any way? Either by making sure that patches aren't sent from such services, or to make sure that such conditions do not hold up in court? I am using gmx myself, and I haven't checked the TOS for changes since years, and I only gave them a 5 secound look when signing up, so I should start with checking that myself(I send most patches from my CW address though)

2 1

Re: Wine autorunner
by Kai Blin Sept. 23, 2007

Sept. 23, 2007

On Sunday 23 September 2007 01:42:46 Computer Dude wrote: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. You need to provide your real name for your patch to be considered at all. Wine will not accept anonymous patches. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0