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

Re: [PATCH 1/3] shell32: Add IQueryInfo in ShellFolder2_GetUIObjectOf [try 2]
by Nikolay Sivov May 20, 2012

May 20, 2012

On 5/20/2012 18:47, Detlef Riekenberg wrote: > +HRESULT IQueryInfo_Constructor(LPCITEMIDLIST root, LPCITEMIDLIST item, void ** ppvOut) > +{ > + IQueryInfoImpl *qi = HeapAlloc(GetProcessHeap(), 0, sizeof(IQueryInfoImpl)); > + LPITEMIDLIST pidl = ILCombine(root, item); > + > + if (!pidl || !qi) { > + SHFree(pidl); > + HeapFree(GetProcessHeap(), 0, qi); > + return E_OUTOFMEMORY; > + } > + > + qi->IQueryInfo_iface.lpVtbl =&IQueryInfo_vtbl; > + qi->ref = 1; > + qi->pidl = ILClone(pidl); > + > + SHFree(pidl); I don't see a reason to ILClone() here. You could just store ILCombine() result.

1 0

Re: dsound: Fixed compilation error caused by 942f2ce7
by Jacek Caban May 19, 2012

May 19, 2012

Hi Alexander, On 5/19/12 3:35 PM, Alexander E. Patrakov wrote: > There is no dummy union u anymore. > This doesn't seem right. They are still present, just generated by widl. Jacek

2 2

re: [appdb] Applications working flawlessly using patched wine should be rated Gold
by Dan Kegel May 18, 2012

May 18, 2012

Frédéric Delanoy wrote: -Application works flawlessly with some DLL overrides, other settings or third party software. +Application works flawlessly with some DLL overrides, some patches applied, other settings or third party software. Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL. - Dan

7 13

Re: [1/2] comctl32/tests: Added tests for treeview right mouse click handling (try 3)
by Marvin May 18, 2012

May 18, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18480 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === Timeout

1 0

Re: [PATCH 1/5] programs: First version of the joystick testing tool. Just lists connected joysticks.
by Alexandre Julliard May 18, 2012

May 18, 2012

Lucas Fialho Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > > --- > configure.ac | 1 + > programs/joystick/Makefile.in | 17 +++++++ > programs/joystick/main.c | 102 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 120 insertions(+) > create mode 100644 programs/joystick/Makefile.in > create mode 100644 programs/joystick/main.c I don't think it makes sense to add a command-line application for this. If there are really things that the user needs to configure, it should be a control panel. But ideally we should retrieve the settings from the Unix environment. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: quartz: COM cleanup for Parser_OutputPin
by Michael Stefaniuc May 18, 2012

May 18, 2012

Hello Aric, On 05/18/2012 04:27 PM, Aric Stewart wrote: > diff --git a/dlls/quartz/avisplit.c b/dlls/quartz/avisplit.c > index 5027e90..bac1b24 100644 > --- a/dlls/quartz/avisplit.c > +++ b/dlls/quartz/avisplit.c > @@ -288,7 +288,7 @@ static HRESULT AVISplitter_next_request(AVISplitterImpl *This, DWORD streamnumbe > > static HRESULT AVISplitter_Receive(AVISplitterImpl *This, IMediaSample *sample, DWORD streamnumber) > { > - Parser_OutputPin *pin = (Parser_OutputPin *)This->Parser.ppPins[1+streamnumber]; > + Parser_OutputPin *pin = impl_Parser_OutputPin_from_IPin(This->Parser.ppPins[1+streamnumber]); this isn't right. impl_from_... should be used only from methods of the respective implementation. You can either: - Make This->Parser.ppPins an array of Parser_OutputPin instead of IPin - Or if you need to support application provided IPin then you'll need an unsafe_impl_from_... > HRESULT hr; > LONGLONG start, stop, rtstart, rtstop; > StreamData *stream = &This->streams[streamnumber]; bye michael

2 1

Logging issue ?
by GOUJON Alexandre May 18, 2012

May 18, 2012

Hi, To understand why a game does not work with the disc while it does with the ISO (created from the same disc), I made a log with +tid,+relay,+volume in both cases and noticed : - some lines (call or ret) are not printed / missing - some lines are half-printed and joined with the following I know sometimes a trailing \n is missing in TRACE() so the output is uncertain. But that doesn't seem to be the case here. Maybe it's not thread safe or something like that ? I tried using taskset 1 wine .. to force using one core but no luck. Here a small part of my log (order not modified, I just remove lines from other threads): 0030:Call KERNEL32.GetVolumeInformationA(09732288 "D:",097321ec,0000007f,00000000,00000000,097321d8,00000000,00000000) ret=0057b045 0030:trace:volume:GetVolumeInformationW L"\\??\\D:\\": found fs type 50009:Call wined3d.wined3d_mutex_unlock() ret=7ed6e3a6 0030:Ret KERNEL32.CreateFileA() retval=000001f4 ret=00c8b5ab 0030:Call KERNEL32.DeviceIoControl(000001f4,00041018,00000000,00000000,09732190,00000008,097321a4,00000000) ret=00c8b64a The game calls GetVolumeInformationA .. the trace is mixed with output of another thread .. I guess the game open the device (no call line) .. and then do some ioctl. No trace of how the game opened the device.. I can do several logs and try to compare each other to have a complete puzzle but that's not very handy. Any thought ? idea ? advice ? (I'm using packaged wine on x86_64) Thanks

2 1

Fwd: Re: Logging issue ?
by GOUJON Alexandre May 18, 2012

May 18, 2012

Also replying to wine-devel -------- Original Message -------- Subject: Re: Logging issue ? Date: Fri, 18 May 2012 16:52:34 +0200 From: GOUJON Alexandre <ale.goujon(a)gmail.com> To: Nikolay Sivov <bunglehead(a)gmail.com> On 05/18/2012 05:31 PM, Nikolay Sivov wrote: > On 5/18/2012 17:23, GOUJON Alexandre wrote: >> Any thought ? idea ? advice ? > I believe there was a discussion about that in the past, It usually > helps to use a ">>" redirect that appends to log file instead of > replacing its contents. But you'll obviously need to clean a log file > before starting anything Using>> instead of> seems to work. It's weird but if it works... Thanks for the advice !

1 0

Re: [PATCH 3/4] shell32: Add IQueryInfo to more shellfolder
by Nikolay Sivov May 18, 2012

May 18, 2012

On 5/18/2012 14:06, Detlef Riekenberg wrote: > + } else if (IsEqualIID(riid,&IID_IQueryInfo)&& (cidl == 1)) { > + pidl = ILCombine (This->pidlRoot, apidl[0]); > + pObj = (IUnknown *) IQueryInfo_Constructor (pidl); > + SHFree (pidl); > + hr = S_OK; > } else { Patch doesn't have a cast here, and looks really redundant. If you really need that it's better to make IQueryInfo_Constructor look more like class factory call - with HRESULT and void** parameter. Also it looks like you always need to combine pidls and cleanup after that, I think it's better to combine them in constructor and keep result in QueryInfo impl. (instead of making a clone). So constructor could look like "HRESULT constructor(root, pidl, pObj)".

1 0

Re: [PATCH 1/4] shell32: Add IQueryInfo in ShellFolder2_GetUIObjectOf
by Nikolay Sivov May 18, 2012

May 18, 2012

On 5/18/2012 14:06, Detlef Riekenberg wrote: > + if (ppv == NULL) > + return E_POINTER; This is usually redundant. > + > + if (IsEqualGUID(&IID_IUnknown, riid) || > + IsEqualGUID(&IID_IQueryInfo, riid)) { > + *ppv =&This->IQueryInfo_iface; > + IUnknown_AddRef((IUnknown*)*ppv); > + TRACE("returning IQueryInfo: %p\n", *ppv); > + return S_OK; > + } Instead of using IUnknown for some reason a clean way could be to call IQueryInfo_AddRef(iface). Trace is not needed here - you have a trace on top of that and FIXME trace on a failure, so you'll know. > + > + *ppv = NULL; > + FIXME("(%p)->(%s %p) interface not supported\n", This, debugstr_guid(riid), ppv); > + return E_NOINTERFACE; > +} > +IQueryInfo *IQueryInfo_Constructor(LPCITEMIDLIST pidl) > +{ > + IQueryInfoImpl *qi; > + > + TRACE("(%p)\n", pidl); > + > + qi = HeapAlloc(GetProcessHeap(), 0, sizeof(IQueryInfoImpl)); > + qi->IQueryInfo_iface.lpVtbl =&IQueryInfo_vtbl; > + qi->ref=1; > + qi->pidl=ILClone(pidl); > + > + TRACE("==> %p (pidl: %p)\n", qi, qi->pidl); > + return&qi->IQueryInfo_iface; > +} This doesn't handle HeaoAlloc() or ILClone failures.

1 0