September 2010 - Wine-Devel

Re: winex11: Add support for animated cursors in X11 driver (try 2).

by Henri Verbeet

I didn't really look at the patch at all, but that's not how HeapReAlloc() works.

Sept. 29, 2010

Re: [PATCH] mshtml: implement ActiveScriptSite_OnScriptError.

by Reece Dunn

On 29 September 2010 11:41, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 9/29/10 9:39 AM, Reece Dunn wrote: >> >> Hi, >> >> This reports any errors sent to the mshtml ActiveScriptSite >> OnScriptError handler to the user and traces it to ERR to aid >> debugging. > > static HRESULT WINAPI ActiveScriptSite_OnScriptError(IActiveScriptSite > *iface, IActiveScriptError *pscripterror) > { > ScriptHost *This = ACTSCPSITE_THIS(iface); > - FIXME("(%p)->(%p)\n", This, pscripterror); > - return E_NOTIMPL; > + EXCEPINFO excep; > + HRESULT hr; > + > + TRACE("(%p)->(%p)\n", This, pscripterror); > + > + hr = IActiveScriptError_GetExceptionInfo(pscripterror,&excep); > + > + ERR("ActiveScript Error: %s source: %s\n", > + debugstr_w(excep.bstrDescription), debugstr_w(excep.bstrSource)); > > ERR is not appropriate in this case. > > + MessageBoxW(NULL, excep.bstrDescription, excep.bstrSource, > MB_OK|MB_ICONERROR); > > This is not how this function should work. If you want to implement it, > please start with a test case. It probably should fire onerror event. OK. I will look into addressing this with an associated test case. - Reece

Sept. 29, 2010

Re: [PATCH] mshtml: implement ActiveScriptSite_OnScriptError.

by Jacek Caban

On 9/29/10 9:39 AM, Reece Dunn wrote: > Hi, > > This reports any errors sent to the mshtml ActiveScriptSite > OnScriptError handler to the user and traces it to ERR to aid > debugging. static HRESULT WINAPI ActiveScriptSite_OnScriptError(IActiveScriptSite *iface, IActiveScriptError *pscripterror) { ScriptHost *This = ACTSCPSITE_THIS(iface); - FIXME("(%p)->(%p)\n", This, pscripterror); - return E_NOTIMPL; + EXCEPINFO excep; + HRESULT hr; + + TRACE("(%p)->(%p)\n", This, pscripterror); + + hr = IActiveScriptError_GetExceptionInfo(pscripterror,&excep); + + ERR("ActiveScript Error: %s source: %s\n", + debugstr_w(excep.bstrDescription), debugstr_w(excep.bstrSource)); ERR is not appropriate in this case. + MessageBoxW(NULL, excep.bstrDescription, excep.bstrSource, MB_OK|MB_ICONERROR); This is not how this function should work. If you want to implement it, please start with a test case. It probably should fire onerror event. Jacek

Sept. 29, 2010

Re: mshtml and friends

by Jacek Caban

On 9/28/10 9:37 PM, Reece Dunn wrote: > On 28 September 2010 15:14, Jacek Caban<jacek(a)codeweavers.com> wrote: >>> I am interested in helping out to improve this area -- my aim is to >>> not require the `winetricks ie6` command to get some of these >>> applications (specifically the Big Fish Games client) to a usable >>> state. >>> >>> Therefore, I am wondering if anyone knows where the best place is to >>> start looking (e.g. known areas of missing functionality) or how to >>> debug applications (and interpret WINEDEBUG output) to identify where >>> the issues are. >> There is no single answer. You want mshtml debug channel for most cases. If >> the problem is with embedding document in an app, then shdocvw is also >> useful. If you have scripts that don't work (and we use jscript for them), >> then jscript debug channel is the answer. If you have a problem with loading >> document, I'd add urlmon,wininet channel. > After some digging around, there appears to be some issues with the > jscript.dll implementation: > > $ trace:jscript:DispatchEx_QueryInterface > (0x1dad2d0)->(IID_IDispatchJS 0x33d5e8) > $ trace:jscript:DispatchEx_AddRef (0x1dad2d0) ref=7 > $ trace:jscript:prop_get L"SWFObject" ret {VT_EMPTY} > $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=6 > $ trace:jscript:DispatchEx_Release (0x1dad2d0) ref=5 > $ fixme:jscript:new_expression_eval throw TypeError > The new_expression_eval fixme is because V_VT(&constr) == VT_EMPTY. > > Now SWFObject is defined in a<script> file, but there are various > script files. For example, given a html file containing: > > <script src="a.js"></script> > <script src="b.js"></script> > with a.js: > > function SWFObject() { this.x = 5; } > > and b.js: > > var swf = new SWFObject(); // appears to be erroring here > alert(swf.x); > Is this supported currently in Wine, or am I going down the wrong track? It's a known regression. A hack from bug 24365 should work around it. Jacek

Sept. 29, 2010

Re: wined3d: Keep track of textures projection state in compiled pixel shaders. [try 2]

by Henri Verbeet

On 28 September 2010 23:07, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > You still need to use this state in the shader backends, instead of getting it from the stateblock.

Sept. 29, 2010

Re: winscard.dll

by Ricardo Filipe

2010/9/29 viny <vincent.hardy.be(a)gmail.com>: >> However, I don't see any credits to me or IDRIX in you submission. > > I don't understand Mounir : after patching, all wine Winscard sources files > contain/keep this words : > "Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX)" > >> In the coming days, I'll prepare an updated version of the 2007 patch that >> can >> be applied cleanly against the latest source tree. > > OK , I'm waiting your new patch. > > -- > Vincent > > > what he meant was that on your patch you didn't credit them.

Sept. 29, 2010

Re: winscard.dll

by viny

> However, I don't see any credits to me or IDRIX in you submission. I don't understand Mounir : after patching, all wine Winscard sources files contain/keep this words : "Copyright 2007 Mounir IDRASSI (mounir.idrassi(a)idrix.fr, for IDRIX)" > In the coming days, I'll prepare an updated version of the 2007 patch that can > be applied cleanly against the latest source tree. OK , I'm waiting your new patch. -- Vincent

Sept. 29, 2010

Re: Wine and security

by Scott Ritchie

On 09/28/2010 11:25 PM, Dan Kegel wrote: > I keep seeing people asking about wine and security, e.g. > http://bugs.winehq.org/show_bug.cgi?id=24550 > or > http://forum.winehq.org/viewtopic.php?t=9770 > or > https://answers.launchpad.net/ubuntu/+source/wine/+question/59148 > ... > > It seems worth listing the things one can do to > partially lock down wine, so I started a page at > http://wiki.winehq.org/SecuringWine > which is appropriately morose, yet lists a few > things one could do if one really wanted to. > > Corrections or additions welcome. > > How about App Armor?

Sept. 29, 2010

Wine and security

by Dan Kegel

I keep seeing people asking about wine and security, e.g. http://bugs.winehq.org/show_bug.cgi?id=24550 or http://forum.winehq.org/viewtopic.php?t=9770 or https://answers.launchpad.net/ubuntu/+source/wine/+question/59148 ... It seems worth listing the things one can do to partially lock down wine, so I started a page at http://wiki.winehq.org/SecuringWine which is appropriately morose, yet lists a few things one could do if one really wanted to. Corrections or additions welcome.

Sept. 29, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Travis Athougies

On Mon, Sep 27, 2010 at 3:57 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 27 September 2010 02:22, Travis Athougies <iammisc(a)gmail.com> wrote: >>>> + /* The Direct3D 9 docs state that we cannot lock a render target surface, >>>> + instead we must copy the render target onto this surface to lock it */ >>> I think you can, if you create it with D3DUSAGE_DYNAMIC | D3DUSAGE_RENDERTARGET. If you want the backbuffer to be lockable you'll need some device creation flag whose name I forgot. >> >> There is the lockable boolean argument that I think might work. I will >> look into using this >> > Please don't. I think GetRenderTargetData() is the correct way to do > this. Generally you don't want lockable render targets at all, but the > case where they're "useful" is for writing data to the render target, > not reading. This is what I read somewhere, some time ago, so I'll just keep it the same. > > The problem with your current setup is that you do the readback after > doing a Present(). Present() invalidates the contents of the > backbuffer. > >> + ok(data[0] == D3DCOLOR_ARGB(0, 0, 255, 255), >> + "swizzle_test: Got color %08x (should be 0x0000FFFF)\n", data[0]); > While I doubt you're going to care a lot for this specific test, I > think it makes sense to integrate something like color_match() from > the d3d9 tests right from the start. In fact, I think the way you want > to do this is to keep the actual testing inside > compile_pixel_shader9(). E.g., you could pass it an array with things > like probe locations, expected values, allowed deviations and failure > messages. I'm wondering... Inside compile_pixel_shader9? or compute_pixel_shader9? I'm thinking that this might make the argument list of compile_pixel_shader9 really really ugly. I'm unsure of exactly what you're telling me here? Could you be more explicit? > >> + if (caps.PixelShaderVersion >= 0xffff0200) > You can just use D3DPS_VERSION(2, 0) here. > Uhmm.... Didn't know that.. thanks! -- Travis Athougies

Sept. 29, 2010