June 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Aaryaman Vasishta

About the refcount of the depth surface after render target is destroyed: How about a simple NULL check for lpvtbl? On Fri, Jun 26, 2015 at 5:32 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > > > On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger < > stefandoesinger(a)gmail.com> wrote: > >> Minor issue: I don't think there's a reason to destroy and recreate the >> surface. >> > The other way afaik is to QI surface version >= 3 and then call > SetSurfaceDesc. This seemed easier to do so. Is there some other way? > > > + IDirectDrawSurface_Release(d3drm_ds); >> > + IDirectDrawSurface_Release(d3drm_surface); >> > + IDirectDrawSurface_Release(ds); >> What happens to the depth buffer here? Does it remain attached? >> > > At this point (after releasing ds) the refcounts of both ds and render > target (i.e. surface) become 1. >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? Most likely you should not be sharing them. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Nikolay Sivov

On 06/26/2015 03:22 PM, Aric Stewart wrote: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? So just to clarify, is this the only solution to have internal structures? I mean do you need them because of some undocumented interfaces or because the way hid/hidclass are used differs from native architecture? > > -aric > > On 6/26/15 1:32 AM, Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> --- /dev/null >>> +++ b/include/wine/hid.h >>> @@ -0,0 +1,80 @@ >>> +/* >>> + * Wine internal HID structures >>> + * >> >> You shouldn't need a global header for internal structures. >> > >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Michael Stefaniuc

Aric, On 06/26/2015 02:22 PM, Aric Stewart wrote: > These internal structures are shared between hid.dll and the forthcoming hidclass.sys > > Should I define them internally at this point and have a patch later that moves them to the global header? my crystal ball tells me that the answer will be to just have that internal header and copy it to hidclass.sys E.g. I have 8 copies of dmobject.[ch] atm bye michael > > -aric > > On 6/26/15 1:32 AM, Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> --- /dev/null >>> +++ b/include/wine/hid.h >>> @@ -0,0 +1,80 @@ >>> +/* >>> + * Wine internal HID structures >>> + * >> >> You shouldn't need a global header for internal structures. >> >

June 26, 2015

Re: [4/14]hid: Implement HidP_GetCaps

by Aric Stewart

These internal structures are shared between hid.dll and the forthcoming hidclass.sys Should I define them internally at this point and have a patch later that moves them to the global header? -aric On 6/26/15 1:32 AM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> --- /dev/null >> +++ b/include/wine/hid.h >> @@ -0,0 +1,80 @@ >> +/* >> + * Wine internal HID structures >> + * > > You shouldn't need a global header for internal structures. >

June 26, 2015

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

by Aaryaman Vasishta

On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Minor issue: I don't think there's a reason to destroy and recreate the > surface. > The other way afaik is to QI surface version >= 3 and then call SetSurfaceDesc. This seemed easier to do so. Is there some other way? > + IDirectDrawSurface_Release(d3drm_ds); > > + IDirectDrawSurface_Release(d3drm_surface); > > + IDirectDrawSurface_Release(ds); > What happens to the depth buffer here? Does it remain attached? > At this point (after releasing ds) the refcounts of both ds and render target (i.e. surface) become 1.

June 26, 2015

Re: [PATCH 3/4] dmband: Remove the extraneous IUnknown from DMBandTrack

by Michael Stefaniuc

On 06/26/2015 12:39 PM, Jacek Caban wrote: > Hi Michael, > > On 06/26/15 00:18, Michael Stefaniuc wrote: >> @@ -97,22 +41,47 @@ static inline IDirectMusicBandTrack *impl_from_IDirectMusicTrack8(IDirectMusicTr >> } >> >> static HRESULT WINAPI IDirectMusicTrack8Impl_QueryInterface(IDirectMusicTrack8 *iface, REFIID riid, >> - void **ppobj) >> + void **ret_iface) >> { >> IDirectMusicBandTrack *This = impl_from_IDirectMusicTrack8(iface); >> - return IUnknown_QueryInterface ((LPUNKNOWN)&This->UnknownVtbl, riid, ppobj); >> + >> + if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IDirectMusicTrack) || >> + IsEqualIID(riid, &IID_IDirectMusicTrack8)) >> + *ret_iface = iface; >> + else if (IsEqualIID(riid, &IID_IPersistStream)) >> + *ret_iface = &This->PersistStreamVtbl; >> + else { >> + WARN("(%p, %s, %p): not found\n", This, debugstr_dmguid(riid), ret_iface); >> + return E_NOINTERFACE; >> + } > > The patch is obviously fine and the problem exists in current code, but > QI is supposed to set output interface on error and such assumption is > common for callers. It would be nice to fix that when you rewrite QI ;) Thanks Jacek, that was just a copy and paste fail on my site as I copied it from band.c and there I did it correctly. bye michael

June 26, 2015

Re: [PATCH 3/4] dmband: Remove the extraneous IUnknown from DMBandTrack

by Jacek Caban

Hi Michael, On 06/26/15 00:18, Michael Stefaniuc wrote: > @@ -97,22 +41,47 @@ static inline IDirectMusicBandTrack *impl_from_IDirectMusicTrack8(IDirectMusicTr > } > > static HRESULT WINAPI IDirectMusicTrack8Impl_QueryInterface(IDirectMusicTrack8 *iface, REFIID riid, > - void **ppobj) > + void **ret_iface) > { > IDirectMusicBandTrack *This = impl_from_IDirectMusicTrack8(iface); > - return IUnknown_QueryInterface ((LPUNKNOWN)&This->UnknownVtbl, riid, ppobj); > + > + if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, &IID_IDirectMusicTrack) || > + IsEqualIID(riid, &IID_IDirectMusicTrack8)) > + *ret_iface = iface; > + else if (IsEqualIID(riid, &IID_IPersistStream)) > + *ret_iface = &This->PersistStreamVtbl; > + else { > + WARN("(%p, %s, %p): not found\n", This, debugstr_dmguid(riid), ret_iface); > + return E_NOINTERFACE; > + } The patch is obviously fine and the problem exists in current code, but QI is supposed to set output interface on error and such assumption is common for callers. It would be nice to fix that when you rewrite QI ;) Cheers, Jacek

June 26, 2015

Re: [PATCH 2/2] msvcp90: Copy name in _Getctype (Valgrind) (try2)

by Piotr Caban

On 06/24/15 16:46, Daniel Lehman wrote: > + name = ___lc_locale_name_func()[LC_COLLATE]; > + size = wcslen(name)+1; > + ret->name = malloc(size*sizeof(*name)); > + if (!ret->name) throw_exception(EXCEPTION_BAD_ALLOC, NULL); > + memcpy(ret->name, name, size*sizeof(*name)); This will not work if ___lc_locale_name_func()[LC_COLLATE] is NULL. Thanks, Piotr

June 26, 2015

Re: wine CPU usage and CreateWaitableTimer

by Nikolay Sivov

On 06/25/2015 10:47 PM, andrea wrote: > On 07/06/15 19:08, Sebastian Lackner wrote: >> Hello andrea, >> >> good catch, its actually a bug in SystemClockAdviseThread. A patch like: >> >> --- snip --- >> diff --git a/dlls/quartz/systemclock.c b/dlls/quartz/systemclock.c >> index 043299b..ac41a49 100644 >> --- a/dlls/quartz/systemclock.c >> +++ b/dlls/quartz/systemclock.c >> @@ -127,6 +127,7 @@ static DWORD WINAPI SystemClockAdviseThread(LPVOID >> lpParam) { >> it = nextit; >> } >> if (NULL != it) timeOut = (DWORD) ((it->rtBaseTime + >> it->rtIntervalTime) - curTime) / (REFERENCE_TIME)10000; >> + else timeOut = INFINITE; >> >> /** Now Periodics Advice: semi sorted list (sort cannot be used) */ >> for (it = This->pPeriodicAdvise; NULL != it; it = it->next) { >> --- snip --- >> >> Seems to be sufficient to fix it. I will review the code for other >> errors one more time, >> and then submit the patch. >> >> Regarding your second question, the best timer (when using for events) is >> CreateWaitableTimer in my opinion. All other timers need separate >> threads, and need an >> additional wineserver call for event handling. >> >> Regards, >> Sebastian > > Did you manage to check if the patch you proposed is the good one? > This particular patch is already in wine, http://source.winehq.org/git/wine.git/commit/b513e07c55504f623baf8d838d00ac….

June 26, 2015