November 2009 - Wine-devel - list.winehq.org

today's git broke winetricks gecko :-(
by Dan Kegel 13 Nov '09

13 Nov '09

Hi Jacek, as of today, "winetricks gecko" triggers the download dialog box :-( Presumably this was caused by http://www.winehq.org/pipermail/wine-cvs/2009-November/061489.html Even if I rearrange the script so there are no invocations of wine before unpacking gecko, it still puts up the dialog box when I run regedit to tell wine about the gecko I unpacked! Got any suggestions? - Dan

6 19

Re: (try 2) user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().
by Rob Shearman 13 Nov '09

13 Nov '09

2009/11/12 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this patch adds a check for PTITLEBARINFO in GetTitleBarInfo() to avoid a > crash. This fixes bug 20249 . > > Try 2 improvement: > - do not print the null pointer, it's useless > > Cheers > Rico > > --- > dlls/user32/nonclient.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) You could easily add a testcase for this behaviour. -- Rob Shearman

2 1

Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY
by Nikolay Sivov 13 Nov '09

13 Nov '09

On 11/13/09, Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > Hi, > > There is a problem to get edit control text after It has processed > WM_DESTROY > message. Perhaps, problem with EDITSTATE structure what contain this text. > WM_DESTROY cause destroying this structure. This is currently a place where control releases its data, and that's fine in that sense. > > Is it possible to solve this problem properly without hacks? > Yes, if destruction itself is made on WM_NCDESTROY for example, or even DestroyWindow knows Edit class and handles its specific data releasing internally. > -- > Best regards, > Ilya Shpigor. >

1 0

Re: [try 3] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList
by Alexandre Julliard 13 Nov '09

13 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; It doesn't make sense to check the interface pointer, it can't be NULL. Also please don't resend the full series once again, when things don't get committed on the first try you need to proceed in smaller steps. -- Alexandre Julliard julliard(a)winehq.org

1 0

What to do when un-nominating bugs for 1.2
by Dan Kegel 12 Nov '09

12 Nov '09

In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? The only time one should simply remove the 1.2 target is if we decide the bug really isn't even a candidate for 1.4 (or was nominated for 1.2 in error).

4 4

Re: user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().
by Paul Vriens 12 Nov '09

12 Nov '09

On 11/12/2009 07:43 PM, Rico Schüller wrote: > + if(!tbi) { > + TRACE("Invalid TITLEBARINFO: %p\n", tbi); Hi Rico, So your printing the NULL pointer? -- Cheers, Paul.

2 1

Re: comctl32/tests: Move message testing helpers to header
by Nikolay Sivov 12 Nov '09

12 Nov '09

Ignore this one, it's a old patch which is wrong but wants to live so much that I send it accidentally. Forget about it.

1 0

Question about GetTokenInformation and memory leaks
by Dan Kegel 12 Nov '09

12 Nov '09

I've never used the security apis, so I'm pretty unfamiliar with them. Valgrinding chromium's sandbox_unittests.exe shows the leak 16 bytes in 1 blocks are definitely lost in loss record 123 of 728 at RtlAllocateHeap (heap.c:1423) by RtlAllocateAndInitializeSid (sec.c:156) by NtQueryInformationToken (nt.c:379) by GetTokenInformation (security.c:676) by ATL::CAccessToken::GetInfoConvert<ATL::CSid,_TOKEN_PRIMARY_GROUP> (atlsecurity.h:754) by ATL::CAccessToken::GetPrimaryGroup (atlsecurity.inl:3623) by sandbox::RestrictedTokenTest_CustomInit_Test::TestBody (restricted_token_unittest.cc:92) The test in question is on line 92 of http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/restricted_toke… Can someone familiar with this stuff have a look? I suspect it's a problem with the test, but can't figure out what's going on. I would have thought the destructors for ATL::CAccessToken and ATL::CSid would have freed everything. (I think the code leaks token_handle, but fixing that doesn't get rid of the reported leak.) - Dan

3 4

Re: [try 2] [PATCH 01/12] comctl32: Add basic structure for IImageList interface
by Alexandre Julliard 12 Nov '09

12 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2926,10 +2927,295 @@ ImageList_SetColorTable (HIMAGELIST himl, UINT uStartIndex, UINT cEntries, CONST > HRESULT WINAPI > ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID riid, void **ppv) > { > - FIXME("STUB: %s %p %s %p\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%s,%p,%s,%p)\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > + > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; You should be checking the clsid here. The iid is checked in QueryInterface. > @@ -2948,6 +3234,38 @@ ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID r > HRESULT WINAPI > HIMAGELIST_QueryInterface (HIMAGELIST himl, REFIID riid, void **ppv) > { > - FIXME("STUB: %p %s %p\n", himl, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%p,%s,%p)\n", himl, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + /* TODO: IID_IImageList2 support */ > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; This one is redundant too. > @@ -30,6 +30,9 @@ > /* the ones with offsets at the end are the same as in Windows */ > struct _IMAGELIST > { > + const struct IImageListVtbl *lpVtbl;/* IImageList vtable */ > + LONG ref; /* reference count */ > + > DWORD magic; /* 00: 'SAMX' */ > INT cCurImage; /* 04: ImageCount */ > INT cMaxImage; /* 08: maximages */ Please update the comment since the offsets no longer match Windows. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/9] avrt: Add stub for Av(Set, Revert)MMThreadCharacteristics
by Alexandre Julliard 12 Nov '09

12 Nov '09

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > +HANDLE WINAPI AvSetMmThreadCharacteristicsW(LPCWSTR TaskName, LPDWORD TaskIndex) > +{ > + FIXME("(%s,%p): stub\n", debugstr_w(TaskName), TaskIndex); > + > + if (!TaskName) > + { > + SetLastError(ERROR_INVALID_TASK_NAME); > + return NULL; > + } > + if (!TaskIndex) > + { > + SetLastError(ERROR_INVALID_HANDLE); > + return NULL; > + } > + return (HANDLE)(LONG_PTR)-1; -1 is not a good choice for a valid handle value. -- Alexandre Julliard julliard(a)winehq.org

1 0