September 2010 - Wine-Devel

Re: Right-To-Left (RTL) languages and Wine

by Alexandre Julliard

Shachar Shemesh <shachar(a)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 julliard(a)winehq.org

Sept. 29, 2010

Re: Right-To-Left (RTL) languages and Wine

by Shachar Shemesh

On 29/09/10 20:25, Alexandre Julliard wrote: > Shachar Shemesh<shachar(a)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

Sept. 29, 2010

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Scott Ritchie

On 09/29/2010 07:53 AM, Scott Ritchie wrote: > On 09/29/2010 07:12 AM, Alexandre Julliard wrote: >> Scott Ritchie <scott(a)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).

Sept. 29, 2010

Re: Right-To-Left (RTL) languages and Wine

by Alexandre Julliard

Shachar Shemesh <shachar(a)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 julliard(a)winehq.org

Sept. 29, 2010

Re: Right-To-Left (RTL) languages and Wine

by Shachar Shemesh

On 29/09/10 18:21, Alexandre Julliard wrote: > Shachar Shemesh<shachar(a)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

Sept. 29, 2010

Re: Right-To-Left (RTL) languages and Wine

by Alexandre Julliard

Shachar Shemesh <shachar(a)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 julliard(a)winehq.org

Sept. 29, 2010

Re: Right-To-Left (RTL) languages and Wine

by Shachar Shemesh

On 24/09/10 23:00, Alexandre Julliard wrote: > Paul Vriens<paul.vriens.wine(a)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

Sept. 29, 2010

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Shachar Shemesh

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

Sept. 29, 2010

Error path issues with "gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics."

by Joris Huizer

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

Sept. 29, 2010

Re: Wanted: small C program to drop all capabilities but cap_sys_ptrace

by Scott Ritchie

On 09/29/2010 07:12 AM, Alexandre Julliard wrote: > Scott Ritchie <scott(a)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...

Sept. 29, 2010