September 2016 - Wine-Devel

Re: [3/3] imm32,user32: Create and destroy the default IME window implicitly. (try 9; resend)

by Akihiro Sagawa

On Fri, 2 Sep 2016 05:41:48 +0200, Sebastian Lackner wrote: > > Just to let you know, in the meantime I have tracked down what is causing the test failure > > (but I am not yet sure how to fix it). Starting with your change, we are also creating IME > > windows for "OleMainThreadWndClass" windows. In this particular case, the watch_desktop_folders > > thread created by explorer.exe is causing the trouble. The thread does not have any message > > loop which is blocking broadcast messages. > > > > Should we filter this case in imm32.needs_ime_window? > > Actually we should probably skip creation for all windows with HWND_MESSAGE parent. > Nevertheless, I will leave a fix to someone more familiar. ;) Great! I verified that the default IME window isn't created for message-only window (= a window created with HWND_MESSAGE parent). I'm preparing tests now. Thanks a lot, Akihiro Sagawa

Sept. 2, 2016

Re: [PATCH 2/2] ole32/tests: Update tests to the new channel hook info structure.

by Huw Davies

On 2 Sep 2016, at 11:32, Huw Davies <huw(a)codeweavers.com> wrote: > > Also add tests for method number and causality. Please ignore this, I’ve sent a better version that doesn’t trace() garbage when the new structs are in use. Huw.

Sept. 2, 2016

Re: [3/3] imm32,user32: Create and destroy the default IME window implicitly. (try 9; resend)

by Sebastian Lackner

On 02.09.2016 05:35, Sebastian Lackner wrote: > On 31.08.2016 12:49, Akihiro Sagawa wrote: >> On Tue, 30 Aug 2016 21:48:49 +0200, Sebastian Lackner wrote: >>> This patch broke various user32 tests in virtual desktop mode, for example: >>> >>> $ (cd dlls/user32/tests/; make broadcast.ok) >>> ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so broadcast && touch broadcast.ok >> (snip) >>> make: *** [Makefile:197: broadcast.ok] Fehler 17 >>> >>> Could you please take a look? >> >> Sure. I'll take a look. >> Thanks for report. >> >> Akihiro Sagawa >> > > Just to let you know, in the meantime I have tracked down what is causing the test failure > (but I am not yet sure how to fix it). Starting with your change, we are also creating IME > windows for "OleMainThreadWndClass" windows. In this particular case, the watch_desktop_folders > thread created by explorer.exe is causing the trouble. The thread does not have any message > loop which is blocking broadcast messages. > > Should we filter this case in imm32.needs_ime_window? > Actually we should probably skip creation for all windows with HWND_MESSAGE parent. Nevertheless, I will leave a fix to someone more familiar. ;) Regards, Sebastian

Sept. 2, 2016

Re: [3/3] imm32,user32: Create and destroy the default IME window implicitly. (try 9; resend)

by Sebastian Lackner

On 31.08.2016 12:49, Akihiro Sagawa wrote: > On Tue, 30 Aug 2016 21:48:49 +0200, Sebastian Lackner wrote: >> This patch broke various user32 tests in virtual desktop mode, for example: >> >> $ (cd dlls/user32/tests/; make broadcast.ok) >> ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so broadcast && touch broadcast.ok > (snip) >> make: *** [Makefile:197: broadcast.ok] Fehler 17 >> >> Could you please take a look? > > Sure. I'll take a look. > Thanks for report. > > Akihiro Sagawa > Just to let you know, in the meantime I have tracked down what is causing the test failure (but I am not yet sure how to fix it). Starting with your change, we are also creating IME windows for "OleMainThreadWndClass" windows. In this particular case, the watch_desktop_folders thread created by explorer.exe is causing the trouble. The thread does not have any message loop which is blocking broadcast messages. Should we filter this case in imm32.needs_ime_window?

Sept. 2, 2016

Re: Implementing Fiber-Local Storage Callbacks: sharing data between DLLs

by Alexandre Julliard

John Sheu <sheu(a)google.com> writes: > The question is how we manage this. One option is to introduce > additional function call entry points to either ntdll or kernel32, > called by the other, to manages FLS lifetime. I see though that the > list of entry points is pretty tightly defined in the .spec files for > each DLL, and the convention may be (correct me if I'm wrong) not to > introduce "weird" private Wine-only APIs to the list. The other > option is to use some internal structs, pointed to by the PEB and TEB > structures. That's the approach I'd like to go with. > > My proposal would be: > > 1. Define a common struct to hold the FLS data array, that would be: > struct FlsSlots { > LIST_ENTRY fls_link; > void fls_slots[SLOT_COUNT]; > }; > 2. TEB.FlsSlots right now is a void** member; make this a struct > FlsSlots* member instead. > 3. Link the FlsSlots struct into PEB.FlsListHead. > > This would require that struct FlsSlots be defined somewhere -- either > in wine/include, as mentioned, or in <include/winternl.h>. Since it > isn't declared publicly in the win32 API, even as an opaque pointer -- > I'm leaning toward the former. Maybe in "wine/include/fls.h" ? In general adding private headers is reserved for things that are used across a wide range of modules, and cannot possibly be done through the Windows API. If you really have to share a private structure like this, you can duplicate the definition, but that should only be a last resort. In general if there's no equivalent structure on Windows, it means that it's supposed to work in a different way. I'll note that recent Windows versions export functions like RtlFlsAlloc and RtlFlsFree, which probably means it should all be handled inside ntdll. Of course it would first need some tests to find out what these functions do. -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2016

Re: [PATCH] winejoystick.drv: Fix long time consuming task of looking for joysticks

by Bruno Jesus

On Thu, Sep 1, 2016 at 11:37 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 01.09.2016 05:18, Bruno Jesus wrote: >> + joysticks = scandir(p, &files, filter_js, sort_js); > > Usually malloc-like allocations should be avoided in the Wine source. I am > not sure if Alexandre is willing to make an exception in this case because > its only a very small amount of memory - nevertheless, replacing with a > different directory enumeration mechanism should also not be too difficult. I considered that, but since this DLL is very low-level and is already using open/read/close/ioctl I thought one more low level call wouldn't hurt. And since the code is Linux only I really thought it was OK. But I'm OK if the patch is rejected, if the approach is not accepted it won't be useful to change the directory listing to winapi as HID gets closer and closer , it will be better to revert the offender patch. > Regards, > Sebastian Best wishes, Bruno

Sept. 2, 2016

Re: [PATCH] winejoystick.drv: Fix long time consuming task of looking for joysticks

by Sebastian Lackner

On 01.09.2016 05:18, Bruno Jesus wrote: > + joysticks = scandir(p, &files, filter_js, sort_js); Usually malloc-like allocations should be avoided in the Wine source. I am not sure if Alexandre is willing to make an exception in this case because its only a very small amount of memory - nevertheless, replacing with a different directory enumeration mechanism should also not be too difficult. Regards, Sebastian

Sept. 2, 2016

Re: user32/tests: Mark a test failure with todo_wine.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > I am getting very consistently test failures here: > > clipboard.c:199: Test failed: 0002: seqno unchanged > clipboard.c:199: Test failed: 0082: seqno unchanged > > Also, currently the clipboard tests trigger all kind of other race-conditions > and bugs in winex11. Are you already aware of those issues, Alexandre? Yes, the stricter tests reveal all sorts of issues with the X11 implementation. I'll get to that once the user32 side works correctly. I don't get the above failure though (not that it means much, sequence number support is also fairly broken). -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2016

Re: HLSL compiler

by Fabian Maurer

> Notice that fx_4_0 is the effects stuff. You probably want to start > with plain shaders (i.e. vs_4_0 and the like). Well, I'm working along a DX10 tutorial and slowly want to have each part work. It's just that they only use .fx files, they seem to contain both vertex- and pixelshader. > I have a lot of code for SM2/3 shaders but it's nowhere near in shape > for upstreaming and I probably won't have time for cleaning that up in > the foreseeable future. > I could publish the code somewhere as-is but, actually, ignoring my > code's existence and restarting from what's upstream now is probably > better anyway. I can give you (or anyone else interested) pointers and > suggestions along the way though, to try and avoid the same pitfalls > and issues I encountered while writing my code. Since I don't know too much about the implementation yet, a few tips would be great. Currently, I'm just toying with the parser to understand how it all works together. Also, does it really not support function calls? I'm currently trying to get that part to work, like built-in functions, but I somewhat can't believe that is missing. > Yep, d3dcompiler API is supposed to handle all shader versions and the > plan was to have one parser and really one compiler for everything > (splitting out only the strictly necessary stuff, e.g. for writing SM4 > bytecode vs SM1 bytecode), sitting in d3dcompiler_43.dll. Ideally > d3dx9, d3d10, d3dx10 and d3dx11 should all forward to d3dcompiler and > everything should work fine. Ah okey. I'll try to extend it and separate the functionality as needed then.

Sept. 2, 2016

Re: Maximum OpenGL version

by Fabian Maurer

On Thursday, September 1, 2016 7:08:12 PM CEST you wrote: > There are a number of small bits and pieces left other than blitters > (e.g. a few limit checks aren't quite right for core profile, Mesa > doesn't complain about them but macOS does) but that's mostly it. I > have not-quite-ready patches for all of this, the plan is to restart > sending them in the near future, although I can't guarantee any hard > deadline... That's fine, thank you. It's just that I ran into this issue and currently needed to switch to the mesa core profile because dx10 doesn't work otherwise. I'll keep it as warning in mind just in case I run into issues.

Sept. 2, 2016