Alexandros Dermenakis wrote:
Hi all,
I studied the wine developer's guide and went a bit through the code. I would
like a suggestion, a bug to start understanding better the structure of wine
and familiarize myself with it in order to be able to contribute more in the
future.
thank you
> I studied the wine developer's guide and went a bit through the code. I would
> like a suggestion, a bug to start understanding better the structure of wine
> and familiarize myself with it in order to be able to contribute more in the
> future.
Often, picking an application that you yourself ru
Hi all,
I studied the wine developer's guide and went a bit through the code. I would
like a suggestion, a bug to start understanding better the structure of wine
and familiarize myself with it in order to be able to contribute more in the
future.
thank you
Hi Detlef,
> When reading the log in the bug, the WSAAsyncGetHostByName16 is the
> indicator for an 16bit app.
Right you are. I ignored that, but clearly I was mistaken.
> Attached is my diff from last year for that code.
The changes you made to getsockopt16 and setsockopt16 look correct.
The
On Do, 2009-08-20 at 18:22 +0200, Alexandre Julliard wrote:
> Juan Lang writes:
>
> >> There can be several other ways to handle this, it needs test cases to
> >> determine which way Windows is using.
> >
> > Sorry for my lack of imagination: could you suggest at least one
> > other way so I can
On Do, 2009-08-20 at 17:58 +0200, Alexandre Julliard wrote:
> Juan Lang writes:
>
> > @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> > TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
> >s, level, optname, optval, *optlen);
> >
> > +/*
2009/8/20 Philipp A. :
> what do you mean with “clean it up”? i don’t see anything not-clean about
> it.
> and why is it nonfunctional in your opinion?
> and for testing: that’s what svn-versions are for, aren’t they?
>
> 2009/8/20 James McKenzie
>>
>> Philipp A. wrote:
>> >>> Well bug 8555 (http:
> Well, i think, they don't like working apps.
> What on earth can i do to make somebody stop by and put the damn patch
> into the svn?
You can keep yelling on this list, and tell us how busy you are. We
care. Really and truly we do.
--Juan
what do you mean with “clean it up”? i don’t see anything not-clean about
it.
and why is it nonfunctional in your opinion?
and for testing: that’s what svn-versions are for, aren’t they?
2009/8/20 James McKenzie
> Philipp A. wrote:
> >>> Well bug 8555 (http://bugs.winehq.org/show_bug.cgi?id=8555
Juan Lang writes:
>> There can be several other ways to handle this, it needs test cases to
>> determine which way Windows is using.
>
> Sorry for my lack of imagination: could you suggest at least one
> other way so I can make sure the tests are representative?
It may check for just 0x
> There can be several other ways to handle this, it needs test cases to
> determine which way Windows is using.
Sorry for my lack of imagination: could you suggest at least one
other way so I can make sure the tests are representative?
Thanks,
--Juan
Juan Lang writes:
> @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
>s, level, optname, optval, *optlen);
>
> +/* Some apps sign-extend the level, so mask off the higher-order bits */
> +
Tony Wasserka writes:
> + *
> + * Used by IWICStream_InitializeFromMemory
> + * This interface is windowscodecs private only which
> + * is why we don't need to implement QueryInterface and AddRef
Don't do that, implement it properly even if that code is not used at
this point.
--
Alexandre Ju
Alexandre Julliard wrote:
Jacek Caban writes:
I just feel that it's better to have a wrapper to avoid explicit casts
in the code and have vtbl logic separated from other code. I usually
use macros, but I know you don't like it, so I used an inline function
here.
For secondary vtbls t
Jacek Caban writes:
> I just feel that it's better to have a wrapper to avoid explicit casts
> in the code and have vtbl logic separated from other code. I usually
> use macros, but I know you don't like it, so I used an inline function
> here.
For secondary vtbls that's definitely a good idea (
Hi,
I wanted to send a mail to the list and basically state what the
status of all this is and what my plans are for the future.
For those unfamiliar with what i was doing, I was trying to enable
using gstreamer elements as directshow filter to expand the quartz
functionality available. At the s
Alexandre Julliard wrote:
Jacek Caban writes:
@@ -84,6 +83,13 @@ static inline xmlnode *impl_from_IXMLDOMNode( IXMLDOMNode
*iface )
return (xmlnode *)((char*)iface - FIELD_OFFSET(xmlnode, lpVtbl));
}
+static inline IXMLDOMNode *_IXMLDOMNode_(xmlnode *This)
+{
+return (IXMLDOMN
2009/8/20 Aric Stewart :
> That is what I am worried about. I am willing to believe that direct show
> uses the acm drivers to decode the audio. I have not found anything to prove
> that yet but it is my gut feeling.
>
Well, there's dlls/quartz/acmwrapper.c. That won't necessarily be used
depending
That is what I am worried about. I am willing to believe that direct
show uses the acm drivers to decode the audio. I have not found anything
to prove that yet but it is my gut feeling.
-aric
Henri Verbeet wrote:
2009/8/20 Roderick Colenbrander :
If you are considering to write an additional
2009/8/20 Roderick Colenbrander :
> If you are considering to write an additional backend, I would advise
> to add a fallback path to directshow.
Wouldn't that potentially create a cyclic dependency?
Jacek Caban writes:
> @@ -84,6 +83,13 @@ static inline xmlnode *impl_from_IXMLDOMNode( IXMLDOMNode
> *iface )
> return (xmlnode *)((char*)iface - FIELD_OFFSET(xmlnode, lpVtbl));
> }
>
> +static inline IXMLDOMNode *_IXMLDOMNode_(xmlnode *This)
> +{
> +return (IXMLDOMNode*)&This->lpVtb
If you are considering to write an additional backend, I would advise
to add a fallback path to directshow. When the gstreamer code enters
mp3 can then easily be added. If directshow for gstreamer isn't
around, just use libmpg123 or use libmpg123 by default and directshow
as a fallback.
Roderick
A quick license check does show that libmad is indeed GPL which means we
cannot use it in WINE at all.
-aric
Aric Stewart wrote:
I am looking into libmad, their programming APIs are completely
undocumented so not sure how it works yet. But really it should be easy
to add it to the frameworks
Hi Alistair,
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
msxml3: Add IDispatchEx support to IXMLDOMElement
+else if( IsEqualGUID( riid, &IID_IDispatch ) ||
+ IsEqualGUID( riid, &IID_IDispatchEx ) )
+{
+xmlnode *node = impl_from_IXMLDOMNode( This->node );
+
+
I am looking into libmad, their programming APIs are completely
undocumented so not sure how it works yet. But really it should be easy
to add it to the frameworks as well so that either libmpg123 or libmad
would be able to be used.
But i see this as an addition onto the libmpg123 work instea
2009/8/20 :
> Hi,
>
> This fixes bug #11167. It depends on my previous patch.
>
> One unclear issue about glHint() is the scope.
> What textures does it affect? When?
>
> An alternative would be, as Stefan Dösinger puts it: "just check if
> the app ever sets two contradicting filter types" but I d
26 matches
Mail list logo