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

Re: [PATCH] dsound: Use event based threads

by Maarten Lankhorst

Op 21-11-12 19:16, Maarten Lankhorst schreef: > Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)ubuntu.com> > Bump, anything wrong with this patch?

Nov. 29, 2012

Re: We're in at FOSDEM!

by Scott Ritchie

On 11/12/12 11:59 AM, Jeremy White wrote: >> We should stay in the same hotel if possible to ease gathering. >> Did someone already choose one? Could You make a special arrangement again (like in Paris, IIRC)? > > No, we haven't yet picked a hotel. I was poking around a bit; looks > like it's not obvious. I see that other projects have varying > strategies for handling this. > > Anyone feeling like a travel planner and want to volunteer for that job? > Or anyone know Brussels and/or FOSDEM such that they can suggest good > strategies? > > Cheers, > > Jeremy > > > We should make a decision about Friday/Sunday (or both) soonish, as it will affect how we book our flights.

Nov. 29, 2012

Re: wshom.ocx: Properly update typeinfo refcount

by Nikolay Sivov

On 11/28/2012 18:19, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> On 11/28/2012 17:43, Alexandre Julliard wrote: >>> Nikolay Sivov <nsivov(a)codeweavers.com> writes: >>> >>>> @@ -137,8 +137,13 @@ static HRESULT WINAPI WshCollection_GetTypeInfoCount(IWshCollection *iface, UINT >>>> static HRESULT WINAPI WshCollection_GetTypeInfo(IWshCollection *iface, UINT iTInfo, LCID lcid, ITypeInfo **ppTInfo) >>>> { >>>> WshCollection *This = impl_from_IWshCollection(iface); >>>> + HRESULT hr; >>>> + >>>> TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo); >>>> - return get_typeinfo(IWshCollection_tid, ppTInfo); >>>> + >>>> + hr = get_typeinfo(IWshCollection_tid, ppTInfo); >>>> + ITypeInfo_AddRef(*ppTInfo); >>>> + return hr; >>> You'd need to check for error first, but the AddRef should really be in >>> get_typeinfo(). >> I agree about error part. The reason why AddRef shouldn't be in >> get_typeinfo() is to avoid pointless AddRef/Release when pointer does >> not go out, and the only case when it's returned to caller is this >> GetTypeInfo() method. > Internal functions should follow COM conventions too, otherwise we'll > constantly run into reference counting bugs. AddRef is cheap. Okay, will do that. Does it mean you want a similar change for mshtml/msxml3 too? For msxml3 it means that http://source.winehq.org/git/wine.git/commitdiff/6e566ce6c24186174ab9c5370a… should be reverted for example.

Nov. 28, 2012

Re: wshom.ocx: Properly update typeinfo refcount

by Nikolay Sivov

On 11/28/2012 17:43, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> @@ -137,8 +137,13 @@ static HRESULT WINAPI WshCollection_GetTypeInfoCount(IWshCollection *iface, UINT >> static HRESULT WINAPI WshCollection_GetTypeInfo(IWshCollection *iface, UINT iTInfo, LCID lcid, ITypeInfo **ppTInfo) >> { >> WshCollection *This = impl_from_IWshCollection(iface); >> + HRESULT hr; >> + >> TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo); >> - return get_typeinfo(IWshCollection_tid, ppTInfo); >> + >> + hr = get_typeinfo(IWshCollection_tid, ppTInfo); >> + ITypeInfo_AddRef(*ppTInfo); >> + return hr; > You'd need to check for error first, but the AddRef should really be in > get_typeinfo(). I agree about error part. The reason why AddRef shouldn't be in get_typeinfo() is to avoid pointless AddRef/Release when pointer does not go out, and the only case when it's returned to caller is this GetTypeInfo() method.

Nov. 28, 2012

Re: wshom.ocx: Properly update typeinfo refcount

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Okay, will do that. Does it mean you want a similar change for > mshtml/msxml3 too? For msxml3 it means that > http://source.winehq.org/git/wine.git/commitdiff/6e566ce6c24186174ab9c5370a… > should be reverted for example. Yes, that should most likely be reverted. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2012

Re: wshom.ocx: Properly update typeinfo refcount

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > On 11/28/2012 17:43, Alexandre Julliard wrote: >> Nikolay Sivov <nsivov(a)codeweavers.com> writes: >> >>> @@ -137,8 +137,13 @@ static HRESULT WINAPI WshCollection_GetTypeInfoCount(IWshCollection *iface, UINT >>> static HRESULT WINAPI WshCollection_GetTypeInfo(IWshCollection *iface, UINT iTInfo, LCID lcid, ITypeInfo **ppTInfo) >>> { >>> WshCollection *This = impl_from_IWshCollection(iface); >>> + HRESULT hr; >>> + >>> TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo); >>> - return get_typeinfo(IWshCollection_tid, ppTInfo); >>> + >>> + hr = get_typeinfo(IWshCollection_tid, ppTInfo); >>> + ITypeInfo_AddRef(*ppTInfo); >>> + return hr; >> You'd need to check for error first, but the AddRef should really be in >> get_typeinfo(). > I agree about error part. The reason why AddRef shouldn't be in > get_typeinfo() is to avoid pointless AddRef/Release when pointer does > not go out, and the only case when it's returned to caller is this > GetTypeInfo() method. Internal functions should follow COM conventions too, otherwise we'll constantly run into reference counting bugs. AddRef is cheap. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2012

Re: wshom.ocx: Properly update typeinfo refcount

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -137,8 +137,13 @@ static HRESULT WINAPI WshCollection_GetTypeInfoCount(IWshCollection *iface, UINT > static HRESULT WINAPI WshCollection_GetTypeInfo(IWshCollection *iface, UINT iTInfo, LCID lcid, ITypeInfo **ppTInfo) > { > WshCollection *This = impl_from_IWshCollection(iface); > + HRESULT hr; > + > TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo); > - return get_typeinfo(IWshCollection_tid, ppTInfo); > + > + hr = get_typeinfo(IWshCollection_tid, ppTInfo); > + ITypeInfo_AddRef(*ppTInfo); > + return hr; You'd need to check for error first, but the AddRef should really be in get_typeinfo(). -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2012

Re: Wine Gecko versioning

by Nikolay Sivov

On 11/27/2012 17:26, Rosanne DiMesio wrote: > On Tue, 27 Nov 2012 13:32:02 +0100 > Jacek Caban <jacek(a)codeweavers.com> wrote: > >> The idea is that Wine Gecko version could be just something based on >> other versions, that are more informative. >> > Users don't care what version of Firefox the latest gecko is based on; most don't even realize it is based on Firefox. What does often confuse users, and which your suggested scheme doesn't address, is keeping track of which version of Wine uses which version of wine-gecko. It's described here http://wiki.winehq.org/Gecko. I guess failure message loading gecko (in load_gecko()) could be improved adding GECKO_VERSION to it so user clearly see what version he needs to have if it's somehow not downloaded already.

Nov. 27, 2012

Re: Wine Gecko versioning

by Rosanne DiMesio

On Tue, 27 Nov 2012 18:33:20 +0300 Nikolay Sivov <bunglehead(a)gmail.com> wrote: > It's described here http://wiki.winehq.org/Gecko. I guess failure > message loading gecko (in load_gecko()) could be improved adding > GECKO_VERSION to it so user clearly see what version he needs to have if > it's somehow not downloaded already. > I know where the information is; in fact, I had to correct that page myself once because the information originally posted was wrong. Adding the version needed to the error message would definitely be helpful. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Nov. 27, 2012

Re: Wine Gecko versioning

by Jacek Caban

On 11/27/12 16:33, Nikolay Sivov wrote: > On 11/27/2012 17:26, Rosanne DiMesio wrote: >> On Tue, 27 Nov 2012 13:32:02 +0100 >> Jacek Caban <jacek(a)codeweavers.com> wrote: >> >>> The idea is that Wine Gecko version could be just something based on >>> other versions, that are more informative. >>> >> Users don't care what version of Firefox the latest gecko is based >> on; most don't even realize it is based on Firefox. What does often >> confuse users, and which your suggested scheme doesn't address, is >> keeping track of which version of Wine uses which version of wine-gecko. As Nikolay said, we have a Wiki page for that. It's not something we can improve by different Gecko versioning. > It's described here http://wiki.winehq.org/Gecko. I guess failure > message loading gecko (in load_gecko()) could be improved adding > GECKO_VERSION to it so user clearly see what version he needs to have > if it's somehow not downloaded already. Sounds like a good idea, although we'll probably want to fix it by including version information in Gecko downloader. Thanks, Jacek

Nov. 27, 2012