August 2017 - Wine-Devel - list.winehq.org

Re: Wine fails to compile in kernel32

by Fabian Maurer

> Since commit e99811aee2dff88c41d6e2875401810a85325839 wine fails to build Thanks you, it's fixed as of 3b399bbbf894b894f8ee753465ad90d7bfb7841d. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> Interesting thing to test I think is to verify if current cross-built > winecfg shows the same issue on Windows, before changing them all. Well, I already added a testcase to show this behavior, but it can't hurt, I guess. I needed to remove the link to "wine_get_unix_file_name" in theme.c, and remove the manifest from the exe, then it starts up on windows. For some reason, it started itself a few hundred times, but then the GUI showed up. The issue is the same on windows, the combobox doesn't work properly the way it currently is, with the patch I submitted it works fine. Actually, windows does show a listbox without the patch, but it's merely 2 pixels in height. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: >> > There are resources in other modules that look like they would have the >> > same problem, a grep over the codebase would probably be useful. >> >> Indeed, I'll look into it. > > There are 10 other components affected. Two questions: > > 1) Should I only look in *.rc files or are there others to look out for? That's probably good enough. > 2) Should I make one big patch or for each component one? One per component please. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Nikolay Sivov

On 29.08.2017 20:06, Fabian Maurer wrote: > Fixes Bug 43632. > winecfg used the broken behavior that was fixed > in f7f7b89e2e9117811c91269643868c6d063db5e9, > so we need to adjust it. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > programs/winecfg/winecfg.rc | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > Interesting thing to test I think is to verify if current cross-built winecfg shows the same issue on Windows, before changing them all.

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> > There are resources in other modules that look like they would have the > > same problem, a grep over the codebase would probably be useful. > > Indeed, I'll look into it. There are 10 other components affected. Two questions: 1) Should I only look in *.rc files or are there others to look out for? 2) Should I make one big patch or for each component one? Regards, Fabian Maurer

Aug. 30, 2017

WINED3DFMT_RESZ in wined3d.

by lorenzo Skotos

Hi. I was investigating a regression that cause the CheckDeviceFormat function to return WINED3DERR_NOTAVAILABLE when quering for RESZ surfaces. (WINED3DFMT_RESZ). This is causing OblivionReloaded (that worked properly until wine 2.5) to not work properly (it detect an incompatible hardware in wine or NVIDIA in wine-staging). I tacked the regression to this commit : https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979… [https://camo.githubusercontent.com/db3db2bf09d082a1f4244859890e83954d8410ab…]<https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979…> wined3d: Allow all formats with "glInternal" set in CheckSurfaceCapab… · wine-mirror/wine(a)8c98be4<https://github.com/wine-mirror/wine/commit/8c98be4791f18f31b04a4a0f08d18979…> github.com …ility(). Rendertarget, depth/stencil and texturing restrictions are applied later in wined3d_check_device_format(), so to the extent this make a difference it mostly affects off-screen plain surf... I tried to fix this issue. The last patch I made in my local branch is adding a wined3d_format_texture_info in the format_texture_info array: + {WINED3DFMT_RESZ, GL_DEPTH24_STENCIL8, GL_DEPTH24_STENCIL8, 0, + GL_DEPTH_STENCIL, GL_UNSIGNED_INT, 0, + WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL | WINED3DFMT_FLAG_RENDERTARGET | WINED3DFMT_FLAG_FBO_ATTACHABLE, + ARB_FRAMEBUFFER_OBJECT, NULL}, However I know almost nothing about the internal work of wined3d and opengl and don't know if this kind of addition is correct. OblivionReloaded works and can properly use the RESZ depth texture. I based this patch on the INTZ and RAWZ surfaces that are somewhat reported to be similar in scope in some docs. Also I don't know if the flags are correct or even meaningful in this scope. I could not find any documentation about the internal meaning of these flags. As the good Jon Snow I know nothing. Note I never did a patch in wine before (except adding some debug message). So please tell me if I'm in a completly wrong direction. Also note that I didn't run the test suite. Using make test is failing hard on an advapi32 test even without this patch applied. I attached the full patch file.

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Fabian Maurer

> There are resources in other modules that look like they would have the > same problem, a grep over the codebase would probably be useful. Indeed, I'll look into it. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH 1/2] comctl32/taskdialog: Initial support for callback procedure

by Fabian Maurer

Hello, thanks for the quick response. > I have no problem with that, except for maybe initializing > size/callback/user data in run_test still. Yes, since that's always the same that makes sense. It's a minor issue really, we could pull it out later, too, but we too could just define it outside from the beginning. > Ok, this is easy to add. If this is so, don't mind this. I just didn't know whether we could fit that into the message structure, too. > What do you mean by last message arrival? Currently all messages to > control are posted, so we don't wait for anything but rely on callback > to be called eventually. Do you mean that you want to specify message to > be sent to control for every callback individually, like for example in > mes_cancel_esc_callback1 - WM_KEYDOWN is sent in response to TDN_CREATED > and TDM_CLICK_BUTTON in response to TDN_BUTTON_CLICKED? Basically yes. Right now all messages are posted at once, and that's where we run into problems. When running my patch on a win7 machine, mes_cancel_esc_callback1 succeeds while mes_cancel_esc_callback2 fails. For some reason the "M_KEYDOWN, VK_ESCAPE" message is completely ignored, and we get IDOK. E.g., modify it like ------ static const struct message_info mes_cancel_esc_callback2[] = { { TDN_CREATED, 0, 0, S_OK, { { WM_KEYDOWN, VK_ESCAPE, 0 }, { TDM_CLICK_BUTTON, IDOK, 0 }, { 0 }}}, { TDN_BUTTON_CLICKED, IDOK, 0, S_OK }, { 0 } }; ------ and it works fine again. As you see, this is something that shouldn't happen. Honestly, I have no idea why that happens, maybe you know more. Could be that I'm just doing something really wrong, but this is the reason I switched to the new strategy - sending the new messages after the old were processed. I just found it to be way more reliable. I'm fine with a different strategy of course, it's just that this was the only way I managed to solve this particular issue. On a site note, the second test fail with ------ taskdialog.c:213: Failed sequence Cancellation: stopped by callback 2: taskdialog.c:213: 0: expected: nothing - actual: 8000 wp 00000000 lp 00000000 taskdialog.c:213: 1: expected: nothing - actual: 8000 wp 00000000 lp 00000000 taskdialog.c:213: 2: expected: nothing - actual: 8000 wp 00000001 lp 00000000 taskdialog.c:213: 3: expected: nothing - actual: 8000 wp 00000000 lp 00000000 ------ and that's obviously wrong. Attached a quick hack, I assume this is a bug in the msg.h implementation. Regards, Fabian Maurer

Aug. 30, 2017

Re: [PATCH] user32: In GetMinMaxInfo, use the default X pos even if the Y pos changes

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This fixes maximizing to the wrong monitor on a Mac with multiple > monitors. Maximizing with multiple monitors continues to work correctly > on Linux for me. > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > dlls/user32/winpos.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) I'm not sure it makes sense to use only one coordinate of the monitor rectangle. What are the coordinate values that trigger this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017

Re: [PATCH] winecfg: Use proper size for combobox controls

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > Fixes Bug 43632. > winecfg used the broken behavior that was fixed > in f7f7b89e2e9117811c91269643868c6d063db5e9, > so we need to adjust it. > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > programs/winecfg/winecfg.rc | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) There are resources in other modules that look like they would have the same problem, a grep over the codebase would probably be useful. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2017