Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite
On Mon, Sep 27, 2010 at 3:57 AM, Henri Verbeet hverb...@gmail.com wrote: On 27 September 2010 02:22, Travis Athougies iamm...@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 0x)\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 = 0x0200) You can just use D3DPS_VERSION(2, 0) here. Uhmm Didn't know that.. thanks! -- Travis Athougies
Wine and security
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.
Re: Wine and security
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?
Re: winscard.dll
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.idra...@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
Re: winscard.dll
2010/9/29 viny vincent.hardy...@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.idra...@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.
Re: wined3d: Keep track of textures projection state in compiled pixel shaders. [try 2]
On 28 September 2010 23:07, Matteo Bruni matteo.myst...@gmail.com wrote: You still need to use this state in the shader backends, instead of getting it from the stateblock.
Re: mshtml and friends
On 9/28/10 9:37 PM, Reece Dunn wrote: On 28 September 2010 15:14, Jacek Cabanja...@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 LSWFObject 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 ascript 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
Re: [PATCH] mshtml: implement ActiveScriptSite_OnScriptError.
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
Re: [PATCH] mshtml: implement ActiveScriptSite_OnScriptError.
On 29 September 2010 11:41, Jacek Caban ja...@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
Re: winex11: Add support for animated cursors in X11 driver (try 2).
I didn't really look at the patch at all, but that's not how HeapReAlloc() works.
Re: mshtml and friends
On 29 September 2010 11:39, Jacek Caban ja...@codeweavers.com wrote: On 9/28/10 9:37 PM, Reece Dunn wrote: On 28 September 2010 15:14, Jacek Cabanja...@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 LSWFObject 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 ascript 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. OK. Thanks. I'll use that to proceed on the issues with Big fish Games. I am also planning on improving wine's behaviour in this regard on error (to assist in tracking down regressions/unimplemented behaviour). The details will likely change as I progress on this. Specifically: 1/ new_expression_eval @ dlls/jscript/engine.c -- FIXME: throw TypeError a/ add dlls/jscript/tests/api.js test -- 'new null;' throws TypeError b/ call throw_type_error @ dlls/jscript/error.c == I have a patch for this, just need to run it on winetestbot to verify Windows behaviour. 2/ Test unhandled exceptions when parsing scripts a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function b/ modify parse_script_a to support expected error code tests c/ call parse_script_a(script, new null;, error) i/ thrown error -- throw TypeError(); ii/ unexpected -- new null; iii/ parse error -- new ; iv/ caught error does not call ActiveScriptSite_OnScriptError -- try { new null; } catch (e) {} d/ if FAILED(parse_script_a) i/ check if ActiveScriptSite_OnScriptError is called ii/ test values on IActiveScriptError object e/ implement calling ActiveScriptSite_OnScriptError in wine's jscript correctly 3/ ActiveScriptSite_OnScriptError @ dlls/mshtml/script.c a/ add dlls/mshtml/tests/script.c test == mshtml.ActiveScriptSite_OnScriptError fires an onerror event b/ implement the behaviour in wine 4/ Real-world test case: a/ add a new dlls/mshtml/tests/jserror.html file: script called_onerror = false; function trigger_error(){ throw SomeError(); } /script body onerror=called_onerror = true; onload=trigger_error(); ok(called_onerror); /body 5/ test/investigate the default mshtml onerror behaviour - Reece
Re: mshtml and friends
On 9/29/10 2:30 PM, Reece Dunn wrote: On 29 September 2010 11:39, Jacek Cabanja...@codeweavers.com wrote: On 9/28/10 9:37 PM, Reece Dunn wrote: On 28 September 2010 15:14, Jacek Cabanja...@codeweavers.comwrote: 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 LSWFObject 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 ascriptfile, 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. OK. Thanks. I'll use that to proceed on the issues with Big fish Games. That's all fine, but all this won't help with fixing Big Fish Games. The problem is probably somewhere else and the question is why the script takes code path resulting in an exception (and even if it's supposed to do so, current exception handling is probably good enough for it). BTW, the script seems to mess with a flash plugin, that won't work with jscript as we'd have to handle ActiveX controls in MSHTML. That's a hard problem. a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function That's not the right place. See exception_test in api.js for exceptions test. It's obviously not testing OnScriptError, but most tests should go there. Jacek
Re: mshtml and friends
On 29 September 2010 13:45, Jacek Caban ja...@codeweavers.com wrote: On 9/29/10 2:30 PM, Reece Dunn wrote: On 29 September 2010 11:39, Jacek Cabanja...@codeweavers.com wrote: On 9/28/10 9:37 PM, Reece Dunn wrote: On 28 September 2010 15:14, Jacek Cabanja...@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 LSWFObject 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 ascript 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. OK. Thanks. I'll use that to proceed on the issues with Big fish Games. That's all fine, but all this won't help with fixing Big Fish Games. I understand this -- I am thinking of improving things for when errors occur. The problem is probably somewhere else and the question is why the script takes code path resulting in an exception (and even if it's supposed to do so, current exception handling is probably good enough for it). The problem with the current wine tip is that 'fixme:jscript:new_expression_eval throw TypeError' line. Since this is triggered in the main script (not in a try ... catch block) it will not get handled properly. BTW, the script seems to mess with a flash plugin, that won't work with jscript as we'd have to handle ActiveX controls in MSHTML. That's a hard problem. Aha! That is likely what is calling the TypeError fixme. a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function That's not the right place. See exception_test in api.js for exceptions test. It's obviously not testing OnScriptError, but most tests should go there. This is what step (1) is testing: exception_test(function() {new null;}, TypeError, ...); which is great if you have something like: scripttry { new null; } catch (e) { ... }/script but not something like: scriptnew null;/script This triggers (http://msdn.microsoft.com/en-us/library/shbz8x82%28v=VS.85%29.aspx) the IActiveScriptSite_OnScriptError callback notification. This is what I intend on testing in the dlls/jscript/tests/activex.c tests as I need to inspect that call when executing this type of unhandled/uncaught exception, which is what will happen in the Big Fish Games client. - Reece
Wanted: small C program to drop all capabilities but cap_sys_ptrace
Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. On an Ubuntu system, this is very similar to what DHCP and PING do -- setuid 0, however they drop all privs except cap_net_rawio at the start. Existing code can be used: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch Basically, I need someone to write this shim for me. The long term solution is probably to just package Wine such that the wine binary itself has cap_sys_ptrace, however currently Ubuntu has no support for this kind of extended attribute in the packaging system so workarounds like the above for DHCP need to be done. I suspect other distros have similar issues. Thanks, Scott Ritchie
Re: mshtml and friends
On 9/29/10 3:03 PM, Reece Dunn wrote: On 29 September 2010 13:45, Jacek Cabanja...@codeweavers.com wrote: The problem is probably somewhere else and the question is why the script takes code path resulting in an exception (and even if it's supposed to do so, current exception handling is probably good enough for it). The problem with the current wine tip is that 'fixme:jscript:new_expression_eval throw TypeError' line. Since this is triggered in the main script (not in a try ... catch block) it will not get handled properly. Sure, but if you want to test new_expression_eval behavior, it's enough and better as the code is cleaner. OnScriptError is a separate problem. a/ dlls/jscript/tests/activex.c -- add a test_jscript_error function That's not the right place. See exception_test in api.js for exceptions test. It's obviously not testing OnScriptError, but most tests should go there. This is what step (1) is testing: exception_test(function() {new null;}, TypeError, ...); which is great if you have something like: scripttry { new null; } catch (e) { ... }/script but not something like: scriptnew null;/script This triggers (http://msdn.microsoft.com/en-us/library/shbz8x82%28v=VS.85%29.aspx) the IActiveScriptSite_OnScriptError callback notification. This is what I intend on testing in the dlls/jscript/tests/activex.c tests as I need to inspect that call when executing this type of unhandled/uncaught exception, which is what will happen in the Big Fish Games client. You have run.c for that. activex.c is, as the name suggests, for testing ActiveXObject-related stuff. Jacek
Re: winex11: Add support for animated cursors in X11 driver (try 2).
On Wed, Sep 29, 2010 at 6:29 AM, Henri Verbeet hverb...@gmail.com wrote: I didn't really look at the patch at all, but that's not how HeapReAlloc() works. Whoops! I can't believe I screwed that up, thanks. Erich Hoover ehoo...@mines.edu
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 03:14 PM, Scott Ritchie wrote: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of processing belonging to the same uid? On an Ubuntu system, this is very similar to what DHCP and PING do -- setuid 0, however they drop all privs except cap_net_rawio at the start. Existing code can be used: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch Basically, I need someone to write this shim for me. The long term solution is probably to just package Wine such that the wine binary itself has cap_sys_ptrace, however currently Ubuntu has no support for this kind of extended attribute in the packaging system so workarounds like the above for DHCP need to be done. I suspect other distros have similar issues. Doubt that Fedora has that problem as they are using SELinux to restrict what processes can do. There is a policy for Wine and rpm supports the setting of the correct SELinux context on rpm installation/upgrade time. bye michael
Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite
On 29 September 2010 08:21, Travis Athougies iamm...@gmail.com wrote: 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 0x)\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? Sorry, in compute_pixel_shader9(). You'd do something like this: struct test_data { UINT x, y; D3DCOLOR color; UINT max_dev; const char *message; }; struct test_data test_data[] = { {320, 240, D3DCOLOR_ARGB(0x00, 0xff, 0xff, 0x00), 1, Some failure message}, ... }; Then pass the test data array to compute_pixel_shader9() which would loop through it and do the actual tests. You'd probably also want to pass __LINE__. Note that this specific structure would be a problem for floating point data though; you'll probably want to use floating point values for your expected data everywhere, and just convert D3DCOLOR result data to floating point inside compute_pixel_shader9().
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 29 September 2010 15:42, Michael Stefaniuc mstef...@redhat.com wrote: On 09/29/2010 03:14 PM, Scott Ritchie wrote: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. Pardon my ignorance but why is Ubuntu restricting the ptrace'ing of processing belonging to the same uid? See http://lkml.org/lkml/2010/6/29/401 for some background on this. I think the conclusion from that thread was essentially that ptrace restrictions and the like should be done using something like SELinux instead.
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... -- Alexandre Julliard julli...@winehq.org
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 07:12 AM, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user...
Error path issues with gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics.
Hello, I noticed the committed patch gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics. (5cac9d2cb2c020802a56a5b1b28348316f1087ba) The GAMEUX_getAppIdFromGDFPath() function now ends with: +HeapFree(GetProcessHeap(), 0, lpRegistryPath); + +TRACE(found app id: %s, return: %#x\n, debugstr_w(lpApplicationId), hr); +return hr; In most of the error paths, lpRegistryPath is not initialized, so it's pointing to garbage; I think just initializing to NULL should be sufficient; Similarly, in that case, lpApplicationId is not initialized, so it contains garbage; Tracing will probably print some random stack bytes before hitting a zero byte. I'm not completely sure what should be done about this issue; I think it should probably only be traced on success, perhaps tracing the error otherwise; Any ideas? HTH, Joris
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 29/09/10 16:53, Scott Ritchie wrote: Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user... What do other packages that depend on ptrace do? In particular, what does strace do? I'd ask about fakeroot-ng, but it's in universe, and I'm the upstream maintainer (read - Debian), so I'm fairly sure that's just broken, but do have a look at that too. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 24/09/10 23:00, Alexandre Julliard wrote: Paul Vrienspaul.vriens.w...@gmail.com writes: I see you made great steps in getting the RTL stuff working. The Hebrew version of native winmine shows the menu's right-aligned now! What are the plans/ideas for the Wine builtin programs with respect to RTL languages? I mean, how are we going to make the distinction between LTR or RTL when builtin apps are run? The apps that are ready for it will have to call SetProcessDefaultLayout when appropriate. I don't think we want to use the version resource for this, the mechanism is badly designed and would be painful to use. If I might recommend something, I suggest not to use SetProcessDefaultLayout at all. Just localize whatever needs localization through the resources and that's it. Even for menus, the resources have an option to define the menus as RTL. The automatic mirroring process is, simply put, a broken idea, badly implemented (I'm talking about Windows here, not Wine). I'm not even sure that the Windows built-in applications use this hack, but even if some do, that is no reason to go down that path. Just my 2cents Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
Shachar Shemesh shac...@shemesh.biz writes: If I might recommend something, I suggest not to use SetProcessDefaultLayout at all. Just localize whatever needs localization through the resources and that's it. Even for menus, the resources have an option to define the menus as RTL. Most applications are not dialogs, so you can't mirror the application window through resources. For instance with notepad, you'd most likely want the edit control to be RTL too, not just the main menu. -- Alexandre Julliard julli...@winehq.org
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 18:21, Alexandre Julliard wrote: Shachar Shemeshshac...@shemesh.biz writes: If I might recommend something, I suggest not to use SetProcessDefaultLayout at all. Just localize whatever needs localization through the resources and that's it. Even for menus, the resources have an option to define the menus as RTL. Most applications are not dialogs, so you can't mirror the application window through resources. For instance with notepad, you'd most likely want the edit control to be RTL too, not just the main menu. Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? At the moment, the edit control does not even properly support BiDi. I do not have a Hebrew localized version of Windows on hand, so it's a bit hard for me to check how that works, but even if we had a BiDi text control, the only effect this localization would have is to set the default direction of the control. The user would then switch it anyways. Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
Shachar Shemesh shac...@shemesh.biz writes: Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? What do you consider broken about it? Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Pretty much all of them. For example, Wordpad has combo boxes in the toolbars, those won't be RTL without changing the process layout. Winefile and Regedit have treeviews that would need mirroring, etc. -- Alexandre Julliard julli...@winehq.org
Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace
On 09/29/2010 07:53 AM, Scott Ritchie wrote: On 09/29/2010 07:12 AM, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: Ubuntu 10.10 is coming out soon, and its new kernel settings prevent Wine apps from looking at each others' memory. This breaks World of Warcraft, among other things. See: http://bugs.winehq.org/show_bug.cgi?id=24193 What's needed is a very small shim for Wine that can be setuid 0, but then release all capabilities except what Wine actually needs -- what a normal user has, and cap_sys_ptrace. I don't think that's a good idea. CAP_SYS_PTRACE allows access to any process, so it's a lot more dangerous than the standard ptrace checks that Ubuntu decided to break. Going back to the default behavior is probably safer than making Wine setuid... Unfortunately the default behavior can only be set globally, so that leaves me with: 1) make installing the package cause the global change 2) the above idea 3) do nothing I'm not sure which is worse, although I know doing nothing breaks a lot of apps. The long term solutions are described at the bug however. It would be rather nice if there were a cap_sys_ptrace that were at least restricted to other processes owned by that user... Actually there's a 4th option that I hadn't realized: apps can give up their own ptrace protection. So Wine can do that for all Wine apps. This should be fairly easy (details at bug report).
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 20:25, Alexandre Julliard wrote: Shachar Shemeshshac...@shemesh.biz writes: Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? What do you consider broken about it? Everything. The concept is that a RTL layout is just a LTR layout reversed. This is almost never the case. Almost always, some controls need to still be LTR (URL edit control, tree view of, basically, Latin registry keys, etc.) Defaulting to a mirrored UI means you need to base your redesign on something substantially different than the original, which I do not see as a good move. Microsoft's implementation of this idea is just as crappy as the core concept. The UI often contains images that are part of it. In order to keep the thing even slightly okay, Windows automatically mirrors every image (yes, EVERY image) displayed into a DC which has the RTL attribute set. The MSDN page discussing this has hilarious images of the Microsoft logo reversed. Their OFFICIAL recommendation is to create localized Hebrew/Arabic resources of the images, which are mirrored at the source, so that after the UI second mirroring they turn out okay. Two wrongs don't make a right indeed. All in all, it is my experience that starting with the LTR layout requires less work and is less error prone than starting with a mirrored LTR layout. This aside from the problems I've mentioned before on this list, of the utter stupidity of having some windows on the same desktop with a close button on the left and some on the right. I know no one who finds this convenient. Don't get me wrong. I'm not saying we shouldn't implement this (except the window decoration part, that i think we should not implement). I'm just saying that I would rather if Wine's built in applications not participate in this madness. Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Pretty much all of them. For example, Wordpad has combo boxes in the toolbars, those won't be RTL without changing the process layout. Winefile and Regedit have treeviews that would need mirroring, etc. First, I'm not sure what the proper way to RTLize regedit should be. See above. Less specifically, however, all controls that have BiDi settings can have those settings set through the resource for that control, without setting it for the entire application. In those cases that the layout is not control by a resource, we are pretty much in deep #...@$!@# anyways because of the reasons stated above. Whether it is Yaron doing the localization or someone else, they must have some way to change the layout in a way that is not merely mirroring, and whatever way that is, it will require being able to tell the system which controls need RTL and which don't. Shachar P.s. I am going over the built in wine applications, and would like to point out for whoever is thinking of localizing clock that clocks in RTL speaking regions still rotate in the same direction. -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
Shachar Shemesh shac...@shemesh.biz writes: Less specifically, however, all controls that have BiDi settings can have those settings set through the resource for that control, without setting it for the entire application. In those cases that the layout is not control by a resource, we are pretty much in deep #...@$!@# anyways because of the reasons stated above. Whether it is Yaron doing the localization or someone else, they must have some way to change the layout in a way that is not merely mirroring, and whatever way that is, it will require being able to tell the system which controls need RTL and which don't. You can't do that in resources, apart from simple dialogs. Many controls are created directly in the code, so you need to change the source. Whether this is to set the process-wide layout or to set WS_EX_LAYOUTRTL individually on appropriate windows will depend on the app, but it needs code changes either way. -- Alexandre Julliard julli...@winehq.org
Re: Right-To-Left (RTL) languages and Wine
Alexandre Julliard julli...@winehq.org wrote: Sent: Sep 29, 2010 11:25 AM To: Shachar Shemesh shac...@shemesh.biz Cc: Paul Vriens paul.vriens.w...@gmail.com, 'wine-devel@winehq.org' wine-devel@winehq.org Subject: Re: Right-To-Left (RTL) languages and Wine Shachar Shemesh shac...@shemesh.biz writes: Did I mention that the automatic mirroring is a broken idea implemented in a broken way already? What do you consider broken about it? Aside from notepad, for which the difference is very small, and most people would regard a default LTR control as the correct behavior anyway, what other applications are you concerned over? Pretty much all of them. For example, Wordpad has combo boxes in the toolbars, those won't be RTL without changing the process layout. Winefile and Regedit have treeviews that would need mirroring, etc. And Microsoft Office appears different in RTL rather than LTR. I used to work with someone that had the Arabic version of these programs and it would switch from RTL when typing in Arabic to LTR when typing in a Latin-based language. As AJ has stated, there is more to do than just 'mirroring' to get RTL into Wine. I remember this was quite difficult to get into OpenOffice.org as well when I was testing it (I think I still have Hebrew and Arabic test files for Writer in OpenDocument (.odt) format.) James McKenzie
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 21:59, James Mckenzie wrote: And Microsoft Office appears different in RTL rather than LTR. I used to work with someone that had the Arabic version of these programs and it would switch from RTL when typing in Arabic to LTR when typing in a Latin-based language. I'm sorry, but you are confusing several issues here. The question is not whether to implement BiDi (yes, provided we find the working hands to do it) or mirroring (yes, except I don't think we need to bother with mirroring the window decoration UI components that Windows does, and I have not heard anyone else weight in on this issue lately). The question is whether Wine's built in application should set a specific flag to do automatic mirroring. Since Word is not a Wine built in application, what it does is irrelevant for this discussion, not because we don't intend to support it, but because it is undisputed we do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Right-To-Left (RTL) languages and Wine
On 29/09/10 21:52, Alexandre Julliard wrote: You can't do that in resources, apart from simple dialogs. Many controls are created directly in the code, so you need to change the source. Whether this is to set the process-wide layout or to set WS_EX_LAYOUTRTL individually on appropriate windows will depend on the app, but it needs code changes either way. Okay. No dispute about that. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: msxml3/httprequest: Add basic bind callback for moniker binding
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=5605 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2917: Test failed: got 0x8000 domdoc.c:2979: Test failed: got 0x8000 === W2KPROSP4 (32 bit domdoc) === domdoc.c:2917: Test failed: got 0x8000 domdoc.c:2979: Test failed: got 0x8000
Re: [PATCH] jscript: throw TypeError if T in 'new T' is not an object.
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=5608 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
Re: Right-To-Left (RTL) languages and Wine
On 9/29/10 2:29 PM, Shachar Shemesh wrote: On 29/09/10 21:59, James Mckenzie wrote: And Microsoft Office appears different in RTL rather than LTR. I used to work with someone that had the Arabic version of these programs and it would switch from RTL when typing in Arabic to LTR when typing in a Latin-based language. I'm sorry, but you are confusing several issues here. The question is not whether to implement BiDi (yes, provided we find the working hands to do it) or mirroring (yes, except I don't think we need to bother with mirroring the window decoration UI components that Windows does, and I have not heard anyone else weight in on this issue lately). The question is whether Wine's built in application should set a specific flag to do automatic mirroring. Since Word is not a Wine built in application, what it does is irrelevant for this discussion, not because we don't intend to support it, but because it is undisputed we do. Thank you for the clarification on what the thread was all about. I thought it was a general RTL/LTR conversation. Pardon the interruption. Everyone on the thread does have a valid point though and I'll continue to watch rather than shout out a comment where it is not needed. James McKenzie