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

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 3:08 AM, Aric Stewart wrote: > diff --git a/dlls/winemac.drv/ime.c b/dlls/winemac.drv/ime.c > index 2c74f6e..066c77a 100644 > --- a/dlls/winemac.drv/ime.c > +++ b/dlls/winemac.drv/ime.c > @@ -1585,14 +1585,20 @@ BOOL query_ime_char_rect(macdrv_query* query) > if (focus && (focus == hwnd || IsChild(hwnd, focus)) && > GetClientRect(focus, &charpos.rcDocument)) > { > + HDC hdc = GetDC(focus); > + TEXTMETRICA tm; > + > if (!GetCaretPos((POINT*)&charpos.rcDocument)) > charpos.rcDocument.left = charpos.rcDocument.top = 0; > > + GetTextMetricsA(hdc, &tm); > charpos.rcDocument.right = charpos.rcDocument.left + 1; > + charpos.rcDocument.bottom = charpos.rcDocument.top + tm.tmHeight; > MapWindowPoints(focus, 0, (POINT*)&charpos.rcDocument, 2); > > *rect = cgrect_from_rect(charpos.rcDocument); > ret = TRUE; > + ReleaseDC(focus, hdc); > } > } I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. Also, you don't check if GetTextMetricsA() succeeded. Perhaps using GetGUIThreadInfo() and the rcCaret field of the GUITHREADINFO structure would be better than using GetCaretPos(). In that case, you'd map the coordinates from hwndCaret (which may be different from "focus") to the screen. Be sure to read the remarks in the MSDN docs for the GetGUIThreadInfo() function about how to use rcCaret, although it's not clear to me if Wine implements this faithfully. -Ken

Feb. 19, 2014

Wine 64 bit

by Kevin Davies

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

Feb. 19, 2014

Re: [3/3] gdi32/tests: Avoid using GetGlyphIndices directly.

by 中川祥

What a phrase it is! By the way,please replay to my patches 102290 and 102289. Please comment if they are safe,if true,they will be comitted. 2014-02-19 21:02 GMT+09:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>: > > This makes NT4 happy. > --- > dlls/gdi32/tests/font.c | 45 ++++++++++++++++++++++++++++----------------- > 1 file changed, 28 insertions(+), 17 deletions(-) > > > > >

Feb. 19, 2014

ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

Hi, In the process of reviewing the Wine DInput translation layer, I noticed an inconvenience (in the ff-core implementation?) that can possibly lead to confusing problems to application developers (not only for Wine), in short: If a new (id==-1) effect was uploaded (look at ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), ff-core will have assigned a positive number to the effect id. This can be confusing because the dev->ff->effects[] array will not contain an element at the index of that new effect id. Here is a more elaborated description/discussion: - This is a bug that is either the responsibility of the Linux kernel, or of Wine (and possibly other applications that do the same thing as described below): It is caused by the following situation: When uploading an effect, the specific kernel device driver may return an error, e.g. EINVAL for example when a periodic's effect period is set to zero. This error will then be returned by "ioctl(*(This->fd), EVIOCSFF, &This->effect)". With or without error, one can find out that /drivers/input/ff-core.c:input_ff_upload(...) is called, which will set effect->id >= 0, if it was set to -1 (=> new effect created) by the user. But in case of an error: - Assume effect->id was set to -1 by the user: The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will also be set >= 0 (*). The offending effect will not be saved in the ff->effects[] array (***). - Assume effect->id was set >= 0 by the user (and ff->effects[effect->id] is a valid existing effect): The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will remain unchanged (**). The offending effect will not overwrite the ff->effects[effect->id] element (****). Is this (see *, **, *** and ****) desired behaviour? - If yes: Change the following in Wine's dinput/effect_linuxinput.c:90 : if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { to : int effectId_old = This->effect.id; if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { This->effect.id = effectId_old; - If no for *: Kernel code /drivers/input/ff-core.c:input_ff_upload(...) has to be patched to revert "effect->id" back to its original value set by the user, which is only needed when the initial (by user) value of "effect->id" was equal to -1. - If no for **** (or maybe also ***): ff->effects[effect->id] could be replaced by an 'empty' effect (however this can get complex because the effect's type has to remain unchanged) This would be a change in the kernel code /drivers/input/ff-core.c:input_ff_upload(...). - If no for **: I don't really know. Discussion is needed. - In my opinion, **, *** and **** are desired behaviour, while * should leave the effect->id at -1. In that case, Wine's dinput implementation does not have to be patched, and the kernel code only should apply a minor patch. Best regards, Elias

Feb. 19, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Aric Stewart

Ok, I will try that tomorrow and report if windows successfully installs the service or not. -aric On 2014/02/19 20:28, Hans Leidekker wrote: > On Wed, 2014-02-19 at 20:03 +0900, Aric Stewart wrote: >> I have not dug into the details, but I know it does not crash and the >> overall install does succeed. >> >> I can try investigating further on windows, Is there an easy way to >> determine what service this is and if it gets successfully installed on windows? > > A +msi,+service trace should reveal the service name. "sc query" will list > installed services, for example. > >

Feb. 19, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Hans Leidekker

On Wed, 2014-02-19 at 20:03 +0900, Aric Stewart wrote: > I have not dug into the details, but I know it does not crash and the > overall install does succeed. > > I can try investigating further on windows, Is there an easy way to > determine what service this is and if it gets successfully installed on windows? A +msi,+service trace should reveal the service name. "sc query" will list installed services, for example.

Feb. 19, 2014

Re: shell32: Ensure that tmpdir contains long path name.

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 https://newtestbot.winehq.org/JobDetails.pl?Key=5017 Your paranoid android. === wxppro (32 bit shlexec) === shlexec.c:1211: Test failed: expected 1 args, got 4 shlexec.c:2283: Test failed: argcA expected 5, but got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1532: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1564: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD34F.tmp\wtD35F.tmp" Exec") WaitForSingleObject returned 258

Feb. 19, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Aric Stewart

I have not dug into the details, but I know it does not crash and the overall install does succeed. I can try investigating further on windows, Is there an easy way to determine what service this is and if it gets successfully installed on windows? -aric On 2014/02/19 18:11, Hans Leidekker wrote: > On Wed, 2014-02-19 at 17:57 +0900, Aric Stewart wrote: >> Well the image path in the component is optional and looking at the documentation >> for CreateServiceW lpBinaryPathName is also optional. So it seemed correct. >> >> If you feel like we should just exit then that is acceptable as well. > > What happens on Windows? > >

Feb. 19, 2014

[idea]wine support for Chrome OS

by 中川祥

Now,we don't run wine in Chrome OS. Google also think they can run windows executable files. My idea is about how to use wine in the OS. Google Chrome has two types of extensions:one is the extension,that support only web technology.the other is PPAPI,Google Native Client. Here's the overview↓ https://developers.google.com/native-client/dev/overview For example,Flash Player uses PPAPI. C/C++ programs can be transformed and run in its sandbox. then we can run wine in Chrome OS. I think if wine supports Chrome OS,Google helps us.

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Henri Verbeet

On 19 February 2014 02:53, Ken Thomases <ken(a)codeweavers.com> wrote: > OK, I can see how that would happen. However, my wined3d patch didn't change that part of the logic. I think my test just exposed a pre-existing bug. It doesn't show up without my wined3d patch applied because, in that case, wined3d fails to restore the window's pixel format and leaves it with a double-buffered pixel format. The two bugs cancel each other out and fixing one allowed the other to be revealed. > With the current code, the pixel format only needs changing if the GL context also does, that's just an implication of setting/restoring both at the same time.

Feb. 19, 2014