Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend)
On 2/15/11 9:26 AM, Alistair Leslie-Hughes wrote:
Hi Jacek,
On 14/02/2011 9:48 PM, Jacek Caban wrote:
On 2/14/11 10:03 AM, Alistair Leslie-Hughes wrote:
Changelog:
mshtml: Ignore IActiveScript interface for IXMLHTTPRequest
mshtml?
+ else if ( IsEqualGUID( riid,IID_IActiveScript))
+ {
+ TRACE((%p)-(IID_IActiveScript %p) returning NULL\n, This,
ppvObject);
+ *ppvObject = NULL;
+ return E_NOINTERFACE;
+ }
else
{
FIXME(Unsupported interface %s\n, debugstr_guid(riid));
As discussed on wine-devel, please just change the later FIXME to TRACE
instead.
By just changing the FIXME to a TRACE would hide this fact that
IObjectWithSite and IObjectSafety need to be implemented at some
point. Only with msxml tracing would be see this fact, which would
lead to hard to pin point errors.
We need to just ignore two know interfaces IActiveScript and IDispatchEx.
Not really. For example, you will find need for silencing
IID_IDispatchJS pseudo-interface and its native jscript equivalent once
it will be actually usefull for scripts. These are not interfaces apps
query for and they are trivial to find once you know you're dealing with
scripting. And please don't tell me that expecting enabling tracing for
debugged DLL is something making debugging hard.
If we are going to stop silencing interfaces, Should be just remove
the ones already in webbrowser(shdocvw)? No, We do this so other
developers can see that these interfaces are not supported and so they
don't need to waste there time researching them. We silence
interfaces like the above in other places, so why no here?
Each case is different and you need to consider what having this FIXME
is gaining us. XMLHTTPRequest object has one interfaces interesting for
apps and some more needed by stuff like scripting or security manager
that are easy to find missing and obvious to expect. Objects like
WebBrowser control have tons of interfaces that app may query for and in
its case, the FIXME has proven to be useful.
Jacek
Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend)
Hi Jacek, -- From: Jacek Caban ja...@codeweavers.com Sent: Wednesday, February 16, 2011 8:44 PM To: Alistair Leslie-Hughes leslie_alist...@hotmail.com Cc: Wine Devel wine-devel@winehq.org Subject: Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend) We need to just ignore two know interfaces IActiveScript and IDispatchEx. Not really. For example, you will find need for silencing IID_IDispatchJS pseudo-interface and its native jscript equivalent once it will be actually usefull for scripts. These are not interfaces apps query for and they are trivial to find once you know you're dealing with scripting. And please don't tell me that expecting enabling tracing for debugged DLL is something making debugging hard. No debugging isn't that hard. I was testing with a web page and these interfaces are repeated in the trace a lot, and it's easier to deal with a name instead of a GUID. If we are going to stop silencing interfaces, Should be just remove the ones already in webbrowser(shdocvw)? No, We do this so other developers can see that these interfaces are not supported and so they don't need to waste there time researching them. We silence interfaces like the above in other places, so why no here? Each case is different and you need to consider what having this FIXME is gaining us. XMLHTTPRequest object has one interfaces interesting for apps and some more needed by stuff like scripting or security manager that are easy to find missing and obvious to expect. Objects like WebBrowser control have tons of interfaces that app may query for and in its case, the FIXME has proven to be useful. I've sent a patch that lists the known noisy interfaces, and changes the FIXME to a WARN. Best Regards Alistair Leslie-Hughes
wine64 issues in dlls/msvcr90/tests/msvcr90.c
As of a few days ago, I'm seeing the following errors when building wine64 with gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 dlls/msvcr90/tests/msvcr90.c:137:14: warning: 'do_call_func1' defined but not used dlls/msvcr90/tests/msvcr90.c:147:14: warning: 'do_call_func2' defined but not used dlls/msvcr90/tests/msvcr90.c: Assembler messages: dlls/msvcr90/tests/msvcr90.c:150: Error: invalid instruction suffix for `push' When building wine32, there seem to be no problems. Is anyone else seeing this when building wine64?
Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]
Gerald Pfeifer ger...@pfeifer.com writes: This is the first hunk of a patch a few days ago; testbot.winehq.org thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291 You don't need casts. If the variable has the wrong type you can change that. -- Alexandre Julliard julli...@winehq.org
Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)
Nikolay Sivov nsi...@codeweavers.com writes:
@@ -381,9 +386,40 @@ static HRESULT WINAPI xslprocessor_Invoke(
static HRESULT WINAPI xslprocessor_put_input( IXSLProcessor *iface, VARIANT
input )
{
xslprocessor *This = impl_from_IXSLProcessor( iface );
+IXMLDOMNode *input_node;
+HRESULT hr;
-FIXME((%p): stub\n, This);
-return E_NOTIMPL;
+TRACE((%p)-(%s)\n, This, debugstr_variant(input));
+
+/* try IXMLDOMNode directly first */
+if (V_VT(input) == VT_UNKNOWN)
+hr = IUnknown_QueryInterface(V_UNKNOWN(input), IID_IXMLDOMNode,
(void**)input_node);
+else if (V_VT(input) == VT_DISPATCH)
+hr = IDispatch_QueryInterface(V_DISPATCH(input), IID_IXMLDOMNode,
(void**)input_node);
+
+if (hr != S_OK)
You need to handle the default case somehow.
--
Alexandre Julliard
julli...@winehq.org
Re: gameux/gamestatistics.c: Make sure each VARIANT is cleared after use (valgrind)
Joris Huizer joris_hui...@yahoo.com writes:
@@ -511,24 +511,27 @@ static HRESULT GAMEUX_loadStatisticsFromFile(struct
GAMEUX_STATS *data)
if(SUCCEEDED(hr))
{
-hr = IXMLDOMElement_getAttribute(categoryElement,
bstrIndex, vValue);
-if( hr == S_OK V_VT(vValue) != VT_BSTR)
+VARIANT categoryIndex, categoryName;
+hr = IXMLDOMElement_getAttribute(categoryElement,
bstrIndex, categoryIndex);
+if( hr == S_OK V_VT(categoryIndex) != VT_BSTR)
hr = E_FAIL;
if(SUCCEEDED(hr))
{
-i = StrToIntW(V_BSTR(vValue));
-hr = IXMLDOMElement_getAttribute(categoryElement,
bstrName, vValue);
-if( hr == S_OK V_VT(vValue) != VT_BSTR)
+i = StrToIntW(V_BSTR(categoryIndex));
+hr = IXMLDOMElement_getAttribute(categoryElement,
bstrName, categoryName);
+if( hr == S_OK V_VT(categoryName) != VT_BSTR)
hr = E_FAIL;
}
+VariantClear(categoryIndex);
You should only clear it when it has been successfully set.
--
Alexandre Julliard
julli...@winehq.org
Re: winmm: Simplify MCI_DumpCommandTable a bit. (RETRY)
Gerald Pfeifer ger...@pfeifer.com writes: Ping. Any objection to this, given that this has not been used for quite a while? The variable is here for documentation, you don't want to remove it. You can comment it out if it's not used. -- Alexandre Julliard julli...@winehq.org
Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)
Hello,
I think I found a (possible) little issue in the patch:
If one would pass a VARIANT of incorrect type to the xslprocessor_put_input()
function (say type BSTR), the first type checks fail and leave hr
uninitialised; in case it happened to have the value S_OK the other if block is
skipped - assigning the uninitialised input_node;
static HRESULT WINAPI xslprocessor_put_input( IXSLProcessor *iface, VARIANT
input )
{
xslprocessor *This = impl_from_IXSLProcessor( iface );
+IXMLDOMNode *input_node;
+HRESULT hr;
(assume hr happens to be S_OK)
-FIXME((%p): stub\n, This);
-return E_NOTIMPL;
+TRACE((%p)-(%s)\n, This, debugstr_variant(input));
+
+/* try IXMLDOMNode directly first */
+if (V_VT(input) == VT_UNKNOWN)
+hr = IUnknown_QueryInterface(V_UNKNOWN(input), IID_IXMLDOMNode,
(void**)input_node);
+else if (V_VT(input) == VT_DISPATCH)
+hr = IDispatch_QueryInterface(V_DISPATCH(input), IID_IXMLDOMNode,
(void**)input_node);
(both false)
+
+if (hr != S_OK)
+{
//...
+}
(skipped)
+
+if (hr == S_OK)
+{
+if (This-input) IXMLDOMNode_Release(This-input);
+This-input = input_node;
+}
(executed, assigning garbage to This-input)
+
+return hr;
}
HTH,
Joris
Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)
On 2/16/2011 16:19, Alexandre Julliard wrote:
Nikolay Sivovnsi...@codeweavers.com writes:
@@ -381,9 +386,40 @@ static HRESULT WINAPI xslprocessor_Invoke(
static HRESULT WINAPI xslprocessor_put_input( IXSLProcessor *iface, VARIANT
input )
{
xslprocessor *This = impl_from_IXSLProcessor( iface );
+IXMLDOMNode *input_node;
+HRESULT hr;
-FIXME((%p): stub\n, This);
-return E_NOTIMPL;
+TRACE((%p)-(%s)\n, This, debugstr_variant(input));
+
+/* try IXMLDOMNode directly first */
+if (V_VT(input) == VT_UNKNOWN)
+hr = IUnknown_QueryInterface(V_UNKNOWN(input),IID_IXMLDOMNode,
(void**)input_node);
+else if (V_VT(input) == VT_DISPATCH)
+hr = IDispatch_QueryInterface(V_DISPATCH(input),IID_IXMLDOMNode,
(void**)input_node);
+
+if (hr != S_OK)
You need to handle the default case somehow.
Default case is to load a document from a passed variant. If you mean
uninitialized hr, I'll fix that in next try.
Somewhat barebones patch to implement D3DXCreateRenderToSurface for bug 24899, how much more needs to be implemented?
Dear All:
Looking at d3dx9 bugs, bug 24899 requires D3DXCreateRenderToSurface.
This, somewhat barebones, patch, implements core functionality of
D3DXCreateRenderToSurface, along with a barebones ID3DXRenderToSurface
implementation.
I was wondering, in order to get this patch accepted into the wine
code base, how much more of ID3DXRenderToSurface needs to be
implemented?
Thank you
Misha
From 9fcf342ea2a08e57a8de2da0e566a2b182f160d4 Mon Sep 17 00:00:00 2001
From: Misha Koshelev misha...@gmail.com
Date: Wed, 16 Feb 2011 10:58:00 -0500
Subject: d3dx9: Implement barebones D3DXCreateRenderToSurface for bug 24899
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/d3dx9_36/core.c| 158 +++
dlls/d3dx9_36/d3dx9_36.spec |2 +-
dlls/d3dx9_36/tests/core.c | 87
3 files changed, 246 insertions(+), 1 deletions(-)
diff --git a/dlls/d3dx9_36/core.c b/dlls/d3dx9_36/core.c
index 6990fbd..7e7ca07 100644
--- a/dlls/d3dx9_36/core.c
+++ b/dlls/d3dx9_36/core.c
@@ -130,3 +130,161 @@ HRESULT WINAPI D3DXCreateBuffer(DWORD NumBytes,
LPD3DXBUFFER* ppBuffer)
*ppBuffer = object-ID3DXBuffer_iface;
return D3D_OK;
}
+
+typedef struct ID3DXRenderToSurfaceImpl
+{
+ID3DXRenderToSurface ID3DXRenderToSurface_iface;
+LONG ref;
+
+D3DXRTS_DESC desc;
+LPDIRECT3DDEVICE9 device;
+} ID3DXRenderToSurfaceImpl;
+
+static inline ID3DXRenderToSurfaceImpl
*impl_from_ID3DXRenderToSurface(ID3DXRenderToSurface *iface)
+{
+return CONTAINING_RECORD(iface, ID3DXRenderToSurfaceImpl,
ID3DXRenderToSurface_iface);
+}
+
+static HRESULT WINAPI
ID3DXRenderToSurfaceImpl_QueryInterface(ID3DXRenderToSurface *iface, REFIID
riid, void **ppobj)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+if (IsEqualGUID(riid, IID_IUnknown)
+|| IsEqualGUID(riid, IID_ID3DXRenderToSurface))
+{
+IUnknown_AddRef(iface);
+*ppobj = This;
+return D3D_OK;
+}
+
+WARN((%p)-(%s,%p),not found\n,This,debugstr_guid(riid),ppobj);
+return E_NOINTERFACE;
+}
+
+static ULONG WINAPI ID3DXRenderToSurfaceImpl_AddRef(ID3DXRenderToSurface
*iface)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+ULONG ref = InterlockedIncrement(This-ref);
+
+TRACE((%p): AddRef from %d\n, This, ref - 1);
+
+return ref;
+}
+
+static ULONG WINAPI ID3DXRenderToSurfaceImpl_Release(ID3DXRenderToSurface
*iface)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+ULONG ref = InterlockedDecrement(This-ref);
+
+TRACE((%p): ReleaseRef to %d\n, This, ref);
+
+if (ref == 0)
+{
+HeapFree(GetProcessHeap(), 0, This);
+}
+return ref;
+}
+
+static HRESULT WINAPI ID3DXRenderToSurfaceImpl_BeginScene(ID3DXRenderToSurface
*iface, LPDIRECT3DSURFACE9 surface, const D3DVIEWPORT9 *viewport)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+FIXME((%p)-(%p, %p): stub\n, This, surface, viewport);
+
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI ID3DXRenderToSurfaceImpl_EndScene(ID3DXRenderToSurface
*iface, DWORD mipfilter)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+FIXME((%p)-(%u): stub\n, This, mipfilter);
+
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI ID3DXRenderToSurfaceImpl_GetDesc(ID3DXRenderToSurface
*iface, D3DXRTS_DESC *parameters)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+TRACE((%p)-(%p)\n, This, parameters);
+
+if (parameters == NULL) return D3DERR_INVALIDCALL;
+*parameters = This-desc;
+
+return D3D_OK;
+}
+
+static HRESULT WINAPI ID3DXRenderToSurfaceImpl_GetDevice(ID3DXRenderToSurface
*iface, LPDIRECT3DDEVICE9 *device)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+TRACE((%p)-(%p)\n, This, device);
+
+if (device == NULL) return D3DERR_INVALIDCALL;
+*device = This-device;
+IDirect3DDevice9_AddRef(This-device);
+
+return D3D_OK;
+}
+
+static HRESULT WINAPI
ID3DXRenderToSurfaceImpl_OnLostDevice(ID3DXRenderToSurface *iface)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+FIXME((%p): stub\n, This);
+
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI
ID3DXRenderToSurfaceImpl_OnResetDevice(ID3DXRenderToSurface *iface)
+{
+ID3DXRenderToSurfaceImpl *This = impl_from_ID3DXRenderToSurface(iface);
+
+FIXME((%p): stub\n, This);
+
+return E_NOTIMPL;
+}
+
+const ID3DXRenderToSurfaceVtbl D3DXRenderToSurface_Vtbl =
+{
+ID3DXRenderToSurfaceImpl_QueryInterface,
+ID3DXRenderToSurfaceImpl_AddRef,
+ID3DXRenderToSurfaceImpl_Release,
+ID3DXRenderToSurfaceImpl_GetDevice,
+ID3DXRenderToSurfaceImpl_GetDesc,
+ID3DXRenderToSurfaceImpl_BeginScene,
+ID3DXRenderToSurfaceImpl_EndScene,
+ID3DXRenderToSurfaceImpl_OnLostDevice,
+
Re: wintrust/tests: Fix a leak (valgrind)
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=9309 Your paranoid android. === W2K8SE (32 bit softpub) === softpub.c:742: Test failed: expected TRUST_E_NOSIGNATURE or CRYPT_E_FILE_ERROR, got 80092003
Re: Anyone using Wine D3D under Parallels?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.02.2011 um 02:24 schrieb Misha Koshelev: What would you recommend using? Do you mean MacOS itself in this specific instance, or was that a general comment (i.e., use Fedora not Ubuntu). I am nowadays mostly using Linux for development, but I also have my Wine development stuff also set up on OSX, and it is working okish. Some things are better(e.g. the GL profiler is cool, if it works), some things are troublesome(e.g. it is generally slower, some newer extensions are missing). I'd prefer MacOS over Linux in a VM. Linux vs MacOS directly on the hardware is a matter of taste and where you feel at home. The advantage of Linux is that if you have a situation where something behaves oddly there are more people who know your platform. On the other hand, Wine could certainly use more Mac devs. My Linux is installed on a USB disk with an EFI bootloader so I can comfortably boot it on OSX by holding down the Alt key. However, the reason for that are other machines, not the macbook.(switch work environment quickly without maintaining 5 installations), Stefan PS: I don't intend to interpret Henri's words, this mail is meant as a general MacOS+Wine development experience report. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNXDsKAAoJEN0/YqbEcdMwoVcQAIKbvZBiBeRdcMnh2mfmqaMo cJQcwn3aC8QKD5Bc+nZ+fubQhMZfx2nyPuCTxWQ5jVP4IPjL0oDkbbpbPLQIqoXj IGDabouv7cEbvT0IZkS5FE2rpHe2vgrVUjEPnWGXLTPt0O//uDn+AVozaWwEdw8l 9OeuXQPv0pVA6F1jj4dAI5dODNcr9ShOhV1zrZfR7Y7rtWBxomnUgg0ExLjbkr7c x7ooq62GxeDcDw5qZY5gUVz/1N8nBRQUpUXUClTfdBfo1011kiFgUn9Copgr5lcT S3qazUBTbs2T4PsmQW8yJMxmaBn4m8OfiOkSHNnfZXPZ6T8ZifJBg0XhK3eNZ0Gm SWCYLs0eL35mOed4++VLEvCiOz69ZPi9WLhdv2ocO4OWehYhqQu3YKMXb98oHsJD vZFS6tMEpPEgWV+69lFzHe3oBUKLa48oljfEfLqrPAtU4Ak0eGT3QVSaTK0bw8dV AMgXMCQl3+hYheVxMYhYzASFs7FKo69F2CuQdMxo+1Ek5VsOYURoe14YdT8nTbgi j/AAMZhCSNuk67NVAH7xBhK8XXog0UD+MZeumH0IJyeLW64PfH+S06DG031GqvLO DTEd2u4FWbeNhfK1C85um5c9lzXcUIIP5tGwhhKeHwnURkE7nWgFZ0tsYt4oErwM bbs1jDqkJn6GVDR/eURS =zjQd -END PGP SIGNATURE-
Re: Anyone using Wine D3D under Parallels?
On Wed, Feb 16, 2011 at 4:00 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.02.2011 um 02:24 schrieb Misha Koshelev: What would you recommend using? Do you mean MacOS itself in this specific instance, or was that a general comment (i.e., use Fedora not Ubuntu). I am nowadays mostly using Linux for development, but I also have my Wine development stuff also set up on OSX, and it is working okish. Some things are better(e.g. the GL profiler is cool, if it works), some things are troublesome(e.g. it is generally slower, some newer extensions are missing). I'd prefer MacOS over Linux in a VM. Linux vs MacOS directly on the hardware is a matter of taste and where you feel at home. The advantage of Linux is that if you have a situation where something behaves oddly there are more people who know your platform. On the other hand, Wine could certainly use more Mac devs. My Linux is installed on a USB disk with an EFI bootloader so I can comfortably boot it on OSX by holding down the Alt key. However, the reason for that are other machines, not the macbook.(switch work environment quickly without maintaining 5 installations), Stefan PS: I don't intend to interpret Henri's words, this mail is meant as a general MacOS+Wine development experience report. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNXDsKAAoJEN0/YqbEcdMwoVcQAIKbvZBiBeRdcMnh2mfmqaMo cJQcwn3aC8QKD5Bc+nZ+fubQhMZfx2nyPuCTxWQ5jVP4IPjL0oDkbbpbPLQIqoXj IGDabouv7cEbvT0IZkS5FE2rpHe2vgrVUjEPnWGXLTPt0O//uDn+AVozaWwEdw8l 9OeuXQPv0pVA6F1jj4dAI5dODNcr9ShOhV1zrZfR7Y7rtWBxomnUgg0ExLjbkr7c x7ooq62GxeDcDw5qZY5gUVz/1N8nBRQUpUXUClTfdBfo1011kiFgUn9Copgr5lcT S3qazUBTbs2T4PsmQW8yJMxmaBn4m8OfiOkSHNnfZXPZ6T8ZifJBg0XhK3eNZ0Gm SWCYLs0eL35mOed4++VLEvCiOz69ZPi9WLhdv2ocO4OWehYhqQu3YKMXb98oHsJD vZFS6tMEpPEgWV+69lFzHe3oBUKLa48oljfEfLqrPAtU4Ak0eGT3QVSaTK0bw8dV AMgXMCQl3+hYheVxMYhYzASFs7FKo69F2CuQdMxo+1Ek5VsOYURoe14YdT8nTbgi j/AAMZhCSNuk67NVAH7xBhK8XXog0UD+MZeumH0IJyeLW64PfH+S06DG031GqvLO DTEd2u4FWbeNhfK1C85um5c9lzXcUIIP5tGwhhKeHwnURkE7nWgFZ0tsYt4oErwM bbs1jDqkJn6GVDR/eURS =zjQd -END PGP SIGNATURE- Stefan, Thanks a lot for your info! Just out of curiosity - how did you build wine git on Mac OS X? There is the simple way that I gleaned from several sources, namely: ./configure CPPFLAGS='-I/usr/X11/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib' make sudo make install and then, to use: DYLD_FALLBACK_LIBRARY_PATH=/usr/X11/lib:/usr/lib wine ... However, this seems to be missing quite a few libraries (libjpeg). I tried to look at the MacPorts build commands by doing: sudo port -d install wine-devel and then copying the ./configure command: ./configure --prefix=/opt/local --without-alsa --without-audioio --without-capi --with-cms --with-coreaudio --with-cups --with-curses --without-esd --with-fontconfig --with-freetype --without-gphoto --with-glu --with-gnutls --without-gsm --without-hal --without-jack --with-jpeg --without-ldap --without-mpg123 --without-nas --without-openal --with-opengl --with-openssl --without-oss --with-png --with-pthread --without-sane --with-tiff --without-v4l --with-xcomposite --with-xcursor --with-xinerama --with-xinput --with-xml --with-xrandr --with-xrender --with-xshape --with-xshm --with-xslt --with-xxf86vm --with-x --x-include=/opt/local/include --x-lib=/opt/local/lib --verbose but the build is failing to find the MacPorts libraries. Any suggestions much appreciated. Thank you Misha
Re: [PATCH] Implement software DXT1 compression
I haven't investigated very closely, but my impression is that you want to use libsquish. I'm not sure if it has C bindings, or if the API is entirely right for what we need, but maybe they accept patches. Yes, there are bindings, but wouldn't this pose the same legal problems as libtxc_dxtn?
Re: comctl32/tests: make sure to use return values (LLVM/Clang) (1/6)
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=9336 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W2KPROSP4 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === WXPPROSP3 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W2K3R2SESP2 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === WVISTAADM (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W2K8SE (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W7PRO (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W7PROX64 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W7PROX64 (64 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2
Re: comctl32/tests: make sure to use return values (LLVM/Clang) (1/6)
On Wed, Feb 16, 2011 at 18:39, Marvin test...@testbot.winehq.org wrote: 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=9336 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W2KPROSP4 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === WXPPROSP3 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W2K3R2SESP2 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === WVISTAADM (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W2K8SE (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 14) listview.c:3764: Test failed: Expected 1, got 2 === W7PRO (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W7PROX64 (32 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 === W7PROX64 (64 bit listview) === listview.c:3054: Test failed: Horizontal spacing inconsistent (200 != 16) listview.c:3764: Test failed: Expected 1, got 2 Hm. Ignore for now please. -- -Austin
Re: comctl32/tests: make sure to use return values (LLVM/Clang) (try 2)
Austin English austinengl...@gmail.com wrote: +r = SendMessage(hwnd, LVM_SETICONSPACING, 0, MAKELONG(100,50)); +ok(r, failed\n); Please use a more informative failure message. r = SendMessage(hwnd, WM_NOTIFYFORMAT, 0, NF_QUERY); +todo_wine expect(2, r); 2 is NFR_UNICODE. -- Dmitry.
