February 2011 - Wine-Devel - list.winehq.org

Re: Anyone using Wine D3D under Parallels?

by Misha Koshelev

For future reference, here is how I was able to quickly compile wine's git version with all the libraries helpfully installed by MacPorts. sudo port install wine-devel When this is finished, go to the Wine GIT folder, and do: ./configure CPPFLAGS='-I/usr/X11/include -I/opt/local/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib -L/opt/local/lib' make && sudo make install Finally, edit your ~/.profile, and add the following line: export DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib:/opt/local/lib" Thank you. Hope this helps someone else. Misha

Feb. 17, 2011

Re: mshtml: Implement IHTMLAnchorElement_put_href

by Jacek Caban

Hi Alistair, On 2/17/11 10:45 AM, Alistair Leslie-Hughes wrote: > + IHTMLAnchorElement *anchor = _get_anchor_iface(line, unk); > + BSTR str; > + HRESULT hres; > + > + str = a2bstr(exhref); > + hres = IHTMLAnchorElement_put_href(anchor, str); > + ok_(__FILE__,line)(hres == S_OK, "get_href failed: %08x\n", hres); > + > + _test_disp_value(line, unk, exhref); You leak str here. Jacek

Feb. 17, 2011

Re: ntdll/signal_arm.c: Implement segv_handler

by Dmitry Timoshkov

chris.nousco(a)gmail.com wrote: > From: JinSung Kang <chris.nousco(a)gmail.com> > > Improve that segv_handler function check page_fault and setting up exception handler. > It is possbible whether read fault or write fault. It looks like the formatting of your patches is messed up because of using a non-standard tab size (4?). -- Dmitry.

Feb. 17, 2011

Re: comctl32/tests: make sure to use return values (LLVM/Clang) (try 2)

by Dmitry Timoshkov

Austin English <austinenglish(a)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.

Feb. 17, 2011

Re: comctl32/tests: make sure to use return values (LLVM/Clang) (1/6)

by Austin English

On Wed, Feb 16, 2011 at 18:39, Marvin <testbot(a)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

Feb. 17, 2011

Re: comctl32/tests: make sure to use return values (LLVM/Clang) (1/6)

by Marvin

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

Feb. 17, 2011

Re: [PATCH] Implement software DXT1 compression

by alberto＠mattea.info

>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?

Feb. 16, 2011

Re: Anyone using Wine D3D under Parallels?

by Misha Koshelev

On Wed, Feb 16, 2011 at 4:00 PM, Stefan Dösinger <stefandoesinger(a)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

Feb. 16, 2011

Re: Anyone using Wine D3D under Parallels?

by Stefan Dösinger

-----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-----

Feb. 16, 2011

Re: wintrust/tests: Fix a leak (valgrind)

by Marvin

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

Feb. 16, 2011

Somewhat barebones patch to implement D3DXCreateRenderToSurface for bug 24899, how much more needs to be implemented?

by Misha Koshelev

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

Feb. 16, 2011

Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)

by Nikolay Sivov

On 2/16/2011 16:19, Alexandre Julliard wrote: > Nikolay Sivov<nsivov(a)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.

Feb. 16, 2011

Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)

by Joris Huizer

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

Feb. 16, 2011

Re: gameux/gamestatistics.c: Make sure each VARIANT is cleared after use (valgrind)

by Alexandre Julliard

Joris Huizer <joris_huizer(a)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 julliard(a)winehq.org

Feb. 16, 2011

Re: [1/3] msxml3/xsl: Basic put_input() method for IXSLProcessor (try2)

by Alexandre Julliard

Nikolay Sivov <nsivov(a)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 julliard(a)winehq.org

Feb. 16, 2011

Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]

by Alexandre Julliard

Gerald Pfeifer <gerald(a)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 julliard(a)winehq.org

Feb. 16, 2011

Re: winmm: Simplify MCI_DumpCommandTable a bit. (RETRY)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)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 julliard(a)winehq.org

Feb. 16, 2011

wine64 issues in dlls/msvcr90/tests/msvcr90.c

by Peter Urbanec

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?

Feb. 16, 2011

Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend)

by Alistair Leslie-Hughes

Hi Jacek, -------------------------------------------------- From: "Jacek Caban" <jacek(a)codeweavers.com> Sent: Wednesday, February 16, 2011 8:44 PM To: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Cc: "Wine Devel" <wine-devel(a)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

Feb. 16, 2011

Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend)

by Jacek Caban

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

Feb. 16, 2011

Re: comctl32/tests: Add casts to avoid two comparisons of different int types.

by Gerald Pfeifer

On Sun, 13 Feb 2011, Janne Hakonen wrote: > Actually, now with your change you are comparing ULONG_PTR to ULONG. > With 64 bit binary the left side of comparison is a 64 bit pointer and > right side is 32 bit value. Thanks, Janne. I have adjusted, tested and resubmitted the first hunk of the patch now. And this is now the second hunk, also approved by Marvin: https://testbot.winehq.org/JobDetails.pl?Key=9292 Gerald ChangeLog: comctl32/tests: Add another cast to avoid comparison of different int types. diff --git a/dlls/comctl32/tests/tab.c b/dlls/comctl32/tests/tab.c index 4c464e6..14c7b59 100644 --- a/dlls/comctl32/tests/tab.c +++ b/dlls/comctl32/tests/tab.c @@ -1327,7 +1327,7 @@ static void test_TCS_OWNERDRAWFIXED(HWND parent_wnd) ShowWindow(hTab, SW_SHOW); RedrawWindow(hTab, NULL, 0, RDW_UPDATENOW); - ok(*(ULONG_PTR*)g_drawitem.itemData == lparam, "got %lx, expected %lx\n", g_drawitem.itemData, lparam); + ok(*(ULONG_PTR*)g_drawitem.itemData == (ULONG_PTR)lparam, "got %lx, expected %lx\n", g_drawitem.itemData, lparam); DestroyWindow(hTab);

Feb. 16, 2011

Re: Anyone using Wine D3D under Parallels?

by Misha Koshelev

On Tue, Feb 15, 2011 at 6:50 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 15 February 2011 21:37, Misha Koshelev <misha680(a)gmail.com> wrote: >> and noticed that although glxinfo reports: >> misha(a)ubuntu:~/.wine/drive_c/Program Files/Tag$ glxinfo | grep -i render >> direct rendering: Yes >> OpenGL renderer string: Parallels using NVIDIA GeForce GT 330M OpenGL Engine >> > Is that a 32-bit or 64-bit Ubuntu? 64-bit. > The 32-bit drivers on 64-bit Ubuntu > have a tendency to be broken, although in this case that would > probably be Parallels' responsibility and not Ubuntu's. Two general > points though: > - Don't use Ubuntu for serious development. 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). > - Don't use VMs for GL/D3D development, unless you can fix the > drivers yourself. Thank you. Duly noted. > > I'm sure it's all kinds of fun to make it work, but it's not very > productive, and you end up with a somewhat questionable configuration > for testing. > Misha p.s. As a note I've actually had similar results in my testing with Mac OS vs VMs. In fact, there are some bugs I was _only_ able to reproduce in the VM (I got an error about a mode not being available within the Mac OS version).

Feb. 16, 2011

Re: [PATCH] Implement software DXT1 compression

by Henri Verbeet

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.

Feb. 16, 2011

Re: Anyone using Wine D3D under Parallels?

by Henri Verbeet

On 15 February 2011 21:37, Misha Koshelev <misha680(a)gmail.com> wrote: > and noticed that although glxinfo reports: > misha(a)ubuntu:~/.wine/drive_c/Program Files/Tag$ glxinfo | grep -i render > direct rendering: Yes > OpenGL renderer string: Parallels using NVIDIA GeForce GT 330M OpenGL Engine > Is that a 32-bit or 64-bit Ubuntu? The 32-bit drivers on 64-bit Ubuntu have a tendency to be broken, although in this case that would probably be Parallels' responsibility and not Ubuntu's. Two general points though: - Don't use Ubuntu for serious development. - Don't use VMs for GL/D3D development, unless you can fix the drivers yourself. I'm sure it's all kinds of fun to make it work, but it's not very productive, and you end up with a somewhat questionable configuration for testing.

Feb. 15, 2011

valgrind results - now with better debug info

by Austin English

Howdy all, I've added a few more suppressions, and after a suggestion by Nikolay, added some debugging symbols: austin(a)debian:~/src/winezeug/valgrind$ dpkg -l | grep dbg ii cups-dbg 1.4.5-2 Common UNIX Printing System(tm) - debugging symbols ii libc6-dbg 2.11.2-11 Embedded GNU C Library: detached debugging symbols ii libgsm1-dbg 1.0.13-3 Shared libraries for GSM speech compressor (debug symbols) ii libsane-dbg 1.0.21-9 API development library for scanners [debug symbols] ii libsane-extras-dbg 1.0.21.2 API library for scanners -- extra backends [debug symbols] ii libxml2-dbg 2.7.8.dfsg-2 Debugging symbols for the GNOME XML library ii libxslt1-dbg 1.1.26-6 XSLT 1.0 processing library - debugging symbols ii zlib1g-dbg 1:1.2.3.4.dfsg-3 compression library - development if you need a debugging symbol package to get better info from a crash, please let me know. The current suppressions used are at: http://winezeug.googlecode.com/svn/trunk/valgrind/valgrind-suppressions Please let me know if you have more to add I've filed bugs for most results, see: http://bugs.winehq.org/buglist.cgi?query_format=advanced&emailreporter1=1&s… as always, results are at: http://austinenglish.com/logs/valgrind/ Cheers, Austin

Feb. 15, 2011