- wine-devel - winehq.org

Re: [PATCH 1/2] msvcrt/tests: Add tests for _creat.
by Lauri Kenttä 06 Feb '17

06 Feb '17

On 2017-02-06 19:54, Piotr Caban wrote: > On 02/06/17 18:27, Lauri Kenttä wrote: >> + int fd, pos, count, readonly, old_fmode = _fmode; > This will not compile in 64-bit wine. Please use e.g. > __p__fmode instead of _fmode. > > Thanks, > Piotr Thanks. __p__fmode doesn't seem to work on 64-bit either. What a mess. Resubmitted with _get_fmode/_set_fmode. I'm not sure if those should be used without GetProcAddress, but at least MinGW has unresolved symbols. Whatever, at least it's working now on both 32-bit and 64-bit. :) -- Lauri Kenttä

1 0

Re: [PATCH 2/2] msvcrt: Fix _creat and _wcreat.
by Marvin 06 Feb '17

06 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28359 Your paranoid android. === wvistau64 (64 bit file) === file.c:2416: Test failed: expected pos 4 (binary mode), got 6 === w2008s64 (64 bit file) === file.c:2416: Test failed: expected pos 4 (binary mode), got 6 === w7pro64 (64 bit file) === file.c:2416: Test failed: expected pos 4 (binary mode), got 6 === w864 (64 bit file) === file.c:2416: Test failed: expected pos 4 (binary mode), got 6 === w1064 (64 bit file) === file.c:2416: Test failed: expected pos 4 (binary mode), got 6

1 0

Re: [PATCH] msvcrt: Pass a missing flag to MSVCRT__open.
by Piotr Caban 06 Feb '17

06 Feb '17

On 02/04/17 14:15, Lauri Kenttä wrote: > int CDECL MSVCRT__creat(const char *path, int flags) > { > int usedFlags = (flags & MSVCRT__O_TEXT)| MSVCRT__O_CREAT| MSVCRT__O_WRONLY| MSVCRT__O_TRUNC; > - return MSVCRT__open(path, usedFlags); > + return MSVCRT__open(path, usedFlags, MSVCRT__S_IWRITE); > } According to MSDN the function takes pmode as second argument. Could you please add some tests for it? It looks like wine's implementation is handling second argument incorrectly. Thanks, Piotr

2 1

Re: [PATCH 1/2] msvcrt/tests: Add tests for _creat.
by Marvin 06 Feb '17

06 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28358 Your paranoid android. === wvistau64 (64 bit file) === file.c:2417: Test failed: expected pos 4 (binary mode), got 6 === w2008s64 (64 bit file) === file.c:2417: Test failed: expected pos 4 (binary mode), got 6 === w7pro64 (64 bit file) === file.c:2417: Test failed: expected pos 4 (binary mode), got 6 === w864 (64 bit file) === file.c:2417: Test failed: expected pos 4 (binary mode), got 6 === w1064 (64 bit file) === file.c:2417: Test failed: expected pos 4 (binary mode), got 6

1 0

Re: [PATCH 2/2] msvcrt: Check pmode in _wsopen_dispatch.
by Piotr Caban 06 Feb '17

06 Feb '17

Hi Lauri, On 02/04/17 15:38, Lauri Kenttä wrote: > if (oflags & MSVCRT__O_CREAT) > { > - if(pmode & ~(MSVCRT__S_IREAD | MSVCRT__S_IWRITE)) > - FIXME(": pmode 0x%04x ignored\n", pmode); > + if (secure && !MSVCRT_CHECK_PMT(!(pmode & ~(MSVCRT__S_IREAD | MSVCRT__S_IWRITE)))) > + return MSVCRT_EINVAL; According to my testing pmode validation doesn't depend on secure flag value (I've tested _wsopen function in msvcr90, I didn't test the _wsopen_dispatch function). Thanks, Piotr

2 2

winmm: deferred patches
by Carlo Bramini 06 Feb '17

06 Feb '17

Hello friends, I had sent two little patches that they were deferred, I do not know if it was because the code freeze or something else: https://www.winehq.org/pipermail/wine-patches/2016-December/156556.html https://www.winehq.org/pipermail/wine-patches/2016-December/156558.html I was wondering if I have to resend them or somebody could just apply them, since they are so small and if you think that they could be useful. Sincerely, Carlo Bramini.

2 1

Re: [PATCH 1/2] wined3d: Add patch primitives.
by Henri Verbeet 06 Feb '17

06 Feb '17

On 2 February 2017 at 19:45, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > @@ -72,6 +72,38 @@ enum wined3d_primitive_type > WINED3D_PT_LINESTRIP_ADJ = 11, > WINED3D_PT_TRIANGLELIST_ADJ = 12, > WINED3D_PT_TRIANGLESTRIP_ADJ = 13, > + WINED3D_PT_1_CONTROL_POINT_PATCHLIST = 33, > + WINED3D_PT_2_CONTROL_POINT_PATCHLIST = 34, > + WINED3D_PT_3_CONTROL_POINT_PATCHLIST = 35, > + WINED3D_PT_4_CONTROL_POINT_PATCHLIST = 36, > + WINED3D_PT_5_CONTROL_POINT_PATCHLIST = 37, > + WINED3D_PT_6_CONTROL_POINT_PATCHLIST = 38, > + WINED3D_PT_7_CONTROL_POINT_PATCHLIST = 39, > + WINED3D_PT_8_CONTROL_POINT_PATCHLIST = 40, > + WINED3D_PT_9_CONTROL_POINT_PATCHLIST = 41, > + WINED3D_PT_10_CONTROL_POINT_PATCHLIST = 42, > + WINED3D_PT_11_CONTROL_POINT_PATCHLIST = 43, > + WINED3D_PT_12_CONTROL_POINT_PATCHLIST = 44, > + WINED3D_PT_13_CONTROL_POINT_PATCHLIST = 45, > + WINED3D_PT_14_CONTROL_POINT_PATCHLIST = 46, > + WINED3D_PT_15_CONTROL_POINT_PATCHLIST = 47, > + WINED3D_PT_16_CONTROL_POINT_PATCHLIST = 48, > + WINED3D_PT_17_CONTROL_POINT_PATCHLIST = 49, > + WINED3D_PT_18_CONTROL_POINT_PATCHLIST = 50, > + WINED3D_PT_19_CONTROL_POINT_PATCHLIST = 51, > + WINED3D_PT_20_CONTROL_POINT_PATCHLIST = 52, > + WINED3D_PT_21_CONTROL_POINT_PATCHLIST = 53, > + WINED3D_PT_22_CONTROL_POINT_PATCHLIST = 54, > + WINED3D_PT_23_CONTROL_POINT_PATCHLIST = 55, > + WINED3D_PT_24_CONTROL_POINT_PATCHLIST = 56, > + WINED3D_PT_25_CONTROL_POINT_PATCHLIST = 57, > + WINED3D_PT_26_CONTROL_POINT_PATCHLIST = 58, > + WINED3D_PT_27_CONTROL_POINT_PATCHLIST = 59, > + WINED3D_PT_28_CONTROL_POINT_PATCHLIST = 60, > + WINED3D_PT_29_CONTROL_POINT_PATCHLIST = 61, > + WINED3D_PT_30_CONTROL_POINT_PATCHLIST = 62, > + WINED3D_PT_31_CONTROL_POINT_PATCHLIST = 63, > + WINED3D_PT_32_CONTROL_POINT_PATCHLIST = 64, > }; > I'm not sure this really makes sense in wined3d, in OpenGL the primitive type and control point count are separate.

2 2

Re: [PATCH 2/2] wined3d: Add support for SRCCOLOR1, INVSRCCOLOR1, SRCALPHA1 and INVSRCALPHA1 blend modes.
by Henri Verbeet 06 Feb '17

06 Feb '17

On 4 February 2017 at 12:33, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > > Overrides http://source.winehq.org/patches/data/129692 > > Signed-off-by: Guillaume Charifi <guillaume.charifi(a)sfr.fr> > --- > dlls/wined3d/state.c | 8 ++++++++ > include/wine/wined3d.h | 4 ++++ > 2 files changed, 12 insertions(+) > The naming is better in this revision, but it looks like Thunderbird corrupted the patch.

1 0

Re: [PATCH 2/2] user32: Implement BS_SPLITBUTTON and BS_DEFSPLITBUTTON.
by Nikolay Sivov 06 Feb '17

06 Feb '17

On 06.02.2017 3:54, Shu Yokoyama wrote: > Signed-off-by: Shu Yokoyama <yokoyama(a)graco.c.u-tokyo.ac.jp> > --- > dlls/user32/button.c | 152 +++++++++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 142 insertions(+), 10 deletions(-) > > diff --git a/dlls/user32/button.c b/dlls/user32/button.c > index e85e30d..135fb1b 100644 > --- a/dlls/user32/button.c > +++ b/dlls/user32/button.c > @@ -29,6 +29,8 @@ > * > * TODO > * Styles > + * - BS_COMMANDLINK > + * - BS_DEFCOMMANDLINK > * - BS_NOTIFY: is it complete? > * - BS_RIGHTBUTTON: same as BS_LEFTTEXT > * > @@ -42,6 +44,8 @@ > * - BCM_GETTEXTMARGIN > * - BCM_SETIMAGELIST > * - BCM_SETTEXTMARGIN > + * - BCM_SETSPLITINFO > + * - BCM_GETSPLITINFO > * > * Notifications > * - BCN_HOTITEMCHANGE > @@ -61,6 +65,8 @@ > * - Button_GetTextMargin > * - Button_SetImageList > * - Button_SetTextMargin > + * - Button_SetSplitInfo > + * - Button_GetSplitInfo > */ > > #include <stdarg.h> > @@ -73,6 +79,7 @@ > #include "winbase.h" > #include "wingdi.h" > #include "controls.h" > +#include "commctrl.h" > #include "win.h" > #include "user_private.h" > #include "wine/debug.h" > @@ -101,6 +108,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(button); > Hi. Patch has its own problems, but more importantly, that's not the way we want v6 controls to be implemented. We need proper separation between user32 and comctl32, with corresponding versioned classes being registered at the right time, and proper classes used based on current context.

2 3

Re: [v2 PATCH 2/3] user32/button: Use current button font to clear during WM_SETTEXT
by Dmitry Timoshkov 06 Feb '17

06 Feb '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > @@ -394,7 +395,9 @@ LRESULT ButtonWndProc_common(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, > > GetClientRect(hWnd, &client); > rc = client; > + if ((hFont = get_button_font(hWnd))) hPrevFont = SelectObject(hdc, hFont); > BUTTON_CalcLabelRect(hWnd, hdc, &rc); > + if (hPrevFont) SelectObject(hdc, hPrevFont); BUTTON_CalcLabelRect() handles all styles of buttons, there is no reason to penalize every of them, only BS_TEXT style needs to have a proper font selected. -- Dmitry.

1 0

Re: [v2 PATCH 1/3] user32/button: Do not restore font after button has been painted
by Dmitry Timoshkov 06 Feb '17

06 Feb '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + /* Test that original font is not selected back after painting */ > + hdc = CreateCompatibleDC(0); > + > + prevfont = SelectObject(hdc, hfont2); > + SendMessageA(hwnd, WM_PRINTCLIENT, (WPARAM)hdc, 0); > + ok(zfont == GetCurrentObject(hdc, OBJ_FONT), "button[%u]: unexpected font selected after WM_PRINTCLIENT %p, " > + "expected %p\n", i, GetCurrentObject(hdc, OBJ_FONT), zfont); The test works by a pure luck. It should check current dc font against prevfont instead of zfont. Changing zfont to DEFAULT_GUI_FONT makes the test fail because of that mistake. > + prevfont = SelectObject(hdc, hfont2); > + SendMessageA(hwnd, WM_PAINT, (WPARAM)hdc, 0); > + ok(zfont == GetCurrentObject(hdc, OBJ_FONT), "button[%u]: unexpected font selected after WM_PAINT %p, " > + "expected %p\n", i, GetCurrentObject(hdc, OBJ_FONT), zfont); Same here. -- Dmitry.

1 0

Re: [PATCH 3/3] user32: Fix groupbox rectangle calculation in the button's WM_SETTEXT handler.
by Dmitry Timoshkov 06 Feb '17

06 Feb '17

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + /* FIXME: check other BS_* handlers */ > + if (btn_type == BS_GROUPBOX) > + InflateRect(&rc, -7, 1); /* GB_Paint does this */ How about doing what FIXME suggests? Adding some tests wouldn't hurt either. -- Dmitry.

3 5

Re: kernel32/tests: Add test for SetFileTime
by Marvin 06 Feb '17

06 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28348 Your paranoid android. === w7u (32 bit file) === file.c:4321: Test failed: SetFileValidData failed 87 file.c:4324: Test failed: SetFileValidData failed 87

1 0

Re: [PATCH 1/3] user32: Always restore previously selected font in the button painting helpers.
by Nikolay Sivov 06 Feb '17

06 Feb '17

This is broken, I'll resend a fixed one.

1 0

Re: iphlpapi/tests: Add tests for GetUnicastIpAddressEntry (try 2)
by Marvin 05 Feb '17

05 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28340 Your paranoid android. === build (build) === Make failed

1 0

Re: [v3 2/3] ntdll: Save rdi and rsi in raise_func_trampoline.
by Sebastian Lackner 05 Feb '17

05 Feb '17

On 05.02.2017 07:10, Andrew Wesie wrote: > On Windows, RDI and RSI are callee-saved registers, but on Linux > they are caller-saved registers. As such, raise_func_trampoline > needs to explicitly unwind them. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 12 +++++++++--- > dlls/ntdll/tests/exception.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 51 insertions(+), 3 deletions(-) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index af16cfd..8b85be7 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -2067,9 +2067,11 @@ NTSTATUS context_from_server( CONTEXT *to, const context_t *from ) > extern void raise_func_trampoline( EXCEPTION_RECORD *rec, CONTEXT *context, raise_func func ); > __ASM_GLOBAL_FUNC( raise_func_trampoline, > __ASM_CFI(".cfi_signal_frame\n\t") > - __ASM_CFI(".cfi_def_cfa %rbp,144\n\t") /* red zone + rip + rbp */ > - __ASM_CFI(".cfi_rel_offset %rip,8\n\t") > - __ASM_CFI(".cfi_rel_offset %rbp,0\n\t") > + __ASM_CFI(".cfi_def_cfa %rbp,160\n\t") /* red zone + rip + rbp + rdi + rsi */ > + __ASM_CFI(".cfi_rel_offset %rip,24\n\t") > + __ASM_CFI(".cfi_rel_offset %rbp,16\n\t") > + __ASM_CFI(".cfi_rel_offset %rdi,8\n\t") > + __ASM_CFI(".cfi_rel_offset %rsi,0\n\t") > "call *%rdx\n\t" > "int $3") > > @@ -2086,6 +2088,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > { > CONTEXT context; > EXCEPTION_RECORD rec; > + ULONG64 rsi; > + ULONG64 rdi; > ULONG64 rbp; > ULONG64 rip; > ULONG64 red_zone[16]; > @@ -2155,6 +2159,8 @@ static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func fun > rsp_ptr = (ULONG64 *)RSP_sig(sigcontext) - 16; > *(--rsp_ptr) = RIP_sig(sigcontext); > *(--rsp_ptr) = RBP_sig(sigcontext); > + *(--rsp_ptr) = RDI_sig(sigcontext); > + *(--rsp_ptr) = RSI_sig(sigcontext); Good catch! > > /* now modify the sigcontext to return to the raise function */ > RIP_sig(sigcontext) = (ULONG_PTR)raise_func_trampoline; > diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c > index dc8f1e2..80c22d0 100644 > --- a/dlls/ntdll/tests/exception.c > +++ b/dlls/ntdll/tests/exception.c > @@ -2073,6 +2073,47 @@ static DWORD run_exception_test(void *handler, const void* context, > return result; > } > > +static DWORD WINAPI unwind_rdi_rsi_handler( EXCEPTION_RECORD *rec, ULONG64 frame, > + CONTEXT *context, DISPATCHER_CONTEXT *dispatcher ) > +{ > + if (rec->ExceptionCode != STATUS_BREAKPOINT) > + return ExceptionContinueSearch; > + > + RtlUnwind( (PVOID)context->Rsp, (PVOID)(context->Rip + 1), rec, NULL ); Is it safe to assume that this will always work? Unwinding past the unwind_rdi_rsi_handler function might require unwinding information, but I'm not sure if we have that when compiling with mingw? I thought this was not implemented yet. On the testbot it still passed, probably because it was luckily compiled to a simple leaf function. > + return ExceptionContinueSearch; > +} > + > +static const BYTE unwind_rdi_test_code[] = { > + 0x57, /* push %rdi */ > + 0x48, 0xc7, 0xc7, 0x55, 0x55, 0x55, 0x55, /* mov $0x55555555, %rdi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf8, /* mov %rdi, %rax */ > + 0x5f, /* pop %rdi */ > + 0xc3, /* ret */ > +}; > + > +static const BYTE unwind_rsi_test_code[] = { > + 0x56, /* push %rsi */ > + 0x48, 0xc7, 0xc6, 0x33, 0x33, 0x33, 0x33, /* mov $0x33333333, %rsi */ > + 0xcc, /* int3 */ > + 0x48, 0x89, 0xf0, /* mov %rsi, %rax */ > + 0x5e, /* pop %rsi */ > + 0xc3, /* ret */ > +}; > + > +static void test_unwind_rdi_rsi(void) > +{ > + DWORD result; > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rdi_test_code, > + sizeof(unwind_rdi_test_code), 0); > + ok( result == 0x55555555, "expected %x, got %x\n", 0x55555555, result ); > + > + result = run_exception_test(unwind_rdi_rsi_handler, NULL, unwind_rsi_test_code, > + sizeof(unwind_rsi_test_code), 0); > + ok( result == 0x33333333, "expected %x, got %x\n", 0x33333333, result ); > +} > + > static DWORD WINAPI dr7_handler( EXCEPTION_RECORD *rec, ULONG64 frame, > CONTEXT *context, DISPATCHER_CONTEXT *dispatcher ) > { > @@ -2651,6 +2692,7 @@ START_TEST(exception) > test_virtual_unwind(); > test___C_specific_handler(); > test_restore_context(); > + test_unwind_rdi_rsi(); > > if (pRtlAddFunctionTable && pRtlDeleteFunctionTable && pRtlInstallFunctionTableCallback && pRtlLookupFunctionEntry) > test_dynamic_unwind(); >

1 0

Re: [v3 1/3] ntdll: Set Dr7 when saving context.
by Sebastian Lackner 05 Feb '17

05 Feb '17

On 05.02.2017 07:10, Andrew Wesie wrote: > This is a work-around so that Dr7 is initialized to a reasonable value. Before > it was just uninitialized memory. The test will fail without the work-around, > and shows a todo if Dr7 is zero. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/ntdll/signal_x86_64.c | 1 + > dlls/ntdll/tests/exception.c | 121 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 122 insertions(+) > > diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c > index f33fe4c..af16cfd 100644 > --- a/dlls/ntdll/signal_x86_64.c > +++ b/dlls/ntdll/signal_x86_64.c > @@ -1692,6 +1692,7 @@ static void save_context( CONTEXT *context, const ucontext_t *sigcontext ) > context->u.FltSave = *FPU_sig(sigcontext); > context->MxCsr = context->u.FltSave.MxCsr; > } > + context->Dr7 = 0; > } > > Wouldn't it make more sense to add a proper implementation for all debug registers? We already have the signal_i386 code for an example how to do it, and other functions like NtGetContextThread also support querying the debug registers (even on x86_64). Best regards, Sebastian

2 2

Re: [v2 2/3] ntdll: Save rdi and rsi in raise_func_trampoline.
by Marvin 05 Feb '17

05 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28326 Your paranoid android. === build (build) === Make failed

1 0

Re: [v2 1/3] ntdll: Set Dr7 when saving context.
by Marvin 05 Feb '17

05 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28325 Your paranoid android. === build (build) === Make failed

1 0

GSoC Ideas page
by André Hentschel 04 Feb '17

04 Feb '17

Hi, I just did the GSoC 2017 application for Wine, please update https://wiki.winehq.org/Summer_Of_Code with your Ideas and mention yourself as possible mentor where appropriate. Thanks!

3 2

Re: [3/3] wined3d: Upload textures if NO_DIRTY_UPDATE flag is set when locking dynamic textures.
by Marvin 04 Feb '17

04 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28316 Your paranoid android. === w1064 (32 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00ff0000 for no color attribute test.

1 0

Re: [1/3] d3d9/tests: Add LockRect tests with dynamic textures.
by Marvin 04 Feb '17

04 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28313 Your paranoid android. === w1064 (32 bit visual) === visual.c:7989: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). visual.c:8093: Test failed: Got unexpected color 0x00000080 for no color attribute test. === w864 (64 bit visual) === visual.c:8093: Test failed: Got unexpected color 0x00ff00ff for no color attribute test.

1 0

Re: [PATCH 2/3] ntdll: Add partial NtQueryInformationThread(ThreadIsIoPending) implementation
by Piotr Caban 03 Feb '17

03 Feb '17

This patch is incorrect, please ignore it. Thanks, Piotr

1 0

Re: [PATCH 2/2] wined3d: Add support for SRCCOLOR2, INVSRCCOLOR2, SRCALPHA2 and INVSRCALPHA2 blend modes.
by Henri Verbeet 03 Feb '17

03 Feb '17

On 2 February 2017 at 19:29, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index 4b0ea06..0b801eb 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -400,6 +400,10 @@ enum wined3d_blend > WINED3D_BLEND_BOTHINVSRCALPHA = 13, > WINED3D_BLEND_BLENDFACTOR = 14, > WINED3D_BLEND_INVBLENDFACTOR = 15, > + WINED3D_BLEND_SRCCOLOR2 = 16, > + WINED3D_BLEND_INVSRCCOLOR2 = 17, > + WINED3D_BLEND_SRCALPHA2 = 18, > + WINED3D_BLEND_INVSRCALPHA2 = 19, > }; > What is this naming based on? In d3d11 these are called "D3D11_BLEND_INV_SRC1_ALPHA", etc.

2 1

Re: [PATCH 3/3] mshtml/tests: Added MHTML document tests.
by Marvin 03 Feb '17

03 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28297 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2670: Test failed: unexpected call GetOverrideKeyPath

1 0

Re: dmcompos/tests: Fix a failing test on Windows 8.
by Huw Davies 03 Feb '17

03 Feb '17

On Fri, Feb 03, 2017 at 02:24:49PM +0100, Michael Stefaniuc wrote: > On 02/03/2017 12:45 PM, Huw Davies wrote: > > The dirty bit is most likely uninitialized, so sometimes this returns S_OK. > Interesting, that seems to be only newtb-w8 that does that. Yes. FWIW, I tried calling IPersistStream_Save() in order to clear the dirty bit, but that returned E_NOTIMPL on all Windows versions... Huw.

2 1

Re: [PATCH 6/9] d3d9: Fix query result data for not started queries.
by Marvin 03 Feb '17

03 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28290 Your paranoid android. === w864 (64 bit device) === device.c:3877: Test failed: Failed to reset device, hr 0x88760868, i=1.

1 0

Re: [PATCH 3/3] kernel32: Add GetThreadIOPendingFlag tests
by Dmitry Timoshkov 03 Feb '17

03 Feb '17

Piotr Caban <piotr(a)codeweavers.com> wrote: > + char path[16384] = {0}; ... > + r = GetTempPathA(MAX_PATH, path); > + ok(r, "GetTempPathA error: %u\n", GetLastError()); > + lstrcatA(path, "testIOPendingFlag"); > + r = CreateDirectoryA(path, NULL); > + ok(r, "CreateDirectoryA error: %d\n", GetLastError()); Why path[MAX_PATH] is not enough? Also you need to remove the created directory at the end of the test. -- Dmitry.

2 2

Re: [v2] kernel32: Read entry before LdrInitializeThunk
by Sebastian Lackner 03 Feb '17

03 Feb '17

On 03.02.2017 11:39, Andrew Wesie wrote: > Overwatch overwrites the PE header contents in a TLS callback. This results in > a crash on wine, because the entry point will be incorrect in start_process. > > Fix the issue by reading the entry point before LdrInitializeThunk is called, > and using this stored value in start_process instead of the PE header. > > Signed-off-by: Andrew Wesie <awesie(a)gmail.com> > --- > dlls/kernel32/process.c | 19 +++++++++---------- > 1 file changed, 9 insertions(+), 10 deletions(-) > > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index 5a9fea2..48bb7bb 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -88,6 +88,7 @@ static const BOOL is_win64 = (sizeof(void *) > sizeof(int)); > > HMODULE kernel32_handle = 0; > SYSTEM_BASIC_INFORMATION system_info = { 0 }; > +LPTHREAD_START_ROUTINE entry_proc = NULL; > > const WCHAR *DIR_Windows = NULL; > const WCHAR *DIR_System = NULL; > @@ -1085,14 +1086,7 @@ static inline DWORD call_process_entry( PEB *peb, LPTHREAD_START_ROUTINE entry ) > */ > static DWORD WINAPI start_process( PEB *peb ) > { > - IMAGE_NT_HEADERS *nt; > - LPTHREAD_START_ROUTINE entry; > - > - nt = RtlImageNtHeader( peb->ImageBaseAddress ); > - entry = (LPTHREAD_START_ROUTINE)((char *)peb->ImageBaseAddress + > - nt->OptionalHeader.AddressOfEntryPoint); > - > - if (!nt->OptionalHeader.AddressOfEntryPoint) > + if (entry_proc == (LPTHREAD_START_ROUTINE)peb->ImageBaseAddress) > { > ERR( "%s doesn't have an entry point, it cannot be executed\n", > debugstr_w(peb->ProcessParameters->ImagePathName.Buffer) ); > @@ -1101,11 +1095,11 @@ static DWORD WINAPI start_process( PEB *peb ) > > if (TRACE_ON(relay)) > DPRINTF( "%04x:Starting process %s (entryproc=%p)\n", GetCurrentThreadId(), > - debugstr_w(peb->ProcessParameters->ImagePathName.Buffer), entry ); > + debugstr_w(peb->ProcessParameters->ImagePathName.Buffer), entry_proc ); > > SetLastError( 0 ); /* clear error code */ > if (peb->BeingDebugged) DbgBreakPoint(); > - return call_process_entry( peb, entry ); > + return call_process_entry( peb, entry_proc ); > } > > > @@ -1186,6 +1180,7 @@ void CDECL __wine_kernel_init(void) > RTL_USER_PROCESS_PARAMETERS *params = peb->ProcessParameters; > HANDLE boot_events[2]; > BOOL got_environment = TRUE; > + IMAGE_NT_HEADERS *nt; > > /* Initialize everything */ > > @@ -1299,6 +1294,10 @@ void CDECL __wine_kernel_init(void) > > if (!params->CurrentDirectory.Handle) chdir("/"); /* avoid locking removable devices */ > > + nt = RtlImageNtHeader( peb->ImageBaseAddress ); > + entry_proc = (LPTHREAD_START_ROUTINE)((char *)peb->ImageBaseAddress + > + nt->OptionalHeader.AddressOfEntryPoint); This will not work for .NET CLI-only images. Handling for them is still missing in Wine, but in this case ntdll replaces the entrypoint, which means it shouldn't be stored in a static variable. I would suggest a slightly different solution: pass the start routine as parameter to start_process(). There is no attempt to make this function compatible with Windows, so you can cache the entry point on the ntdll side. This is similar how it is done in this draft patch: https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-CL… Nevertheless, it will require careful testing. This example shows that replacing the PE header is valid in some situations, so just ignoring all changes probably also isn't correct. Maybe it should use the value from some loader structure? > + > LdrInitializeThunk( start_process, 0, 0, 0 ); > > error: >

1 0

Re: [1/2] iphlpapi: Add GetUnicastIpAddressEntry implementation (resend)
by Hans Leidekker 03 Feb '17

03 Feb '17

On Fri, 2017-02-03 at 00:08 +0100, André Hentschel wrote: > + GetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, NULL, &size); GAA_FLAG_INCLUDE_ALL_INTERFACES has no effect on Wine and you're not using the result of GAA_FLAG_INCLUDE_PREFIX. > + ptr = HeapAlloc(GetProcessHeap(), 0, size); > + ret = GetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, ptr, &size); > + if (FAILED(ret)) Please handle allocation failure. GetAdaptersAddresses returns ULONG, not HRESULT.

1 0

Re: [v2 2/3] ntdll: Implement FileIdInformation class support in NtQueryInformationFile.
by Sebastian Lackner 03 Feb '17

03 Feb '17

On 26.01.2017 12:09, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > configure | 24 ++++++++++++++++++++++++ > configure.ac | 16 ++++++++++++++++ > dlls/ntdll/file.c | 22 +++++++++++++++++++++- > include/config.h.in | 3 +++ > include/winbase.h | 9 +++++++++ > 5 files changed, 73 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > index 1a96117..a9d7878 100755 > --- a/configure > +++ b/configure > @@ -16407,6 +16407,30 @@ _ACEOF > fi > > > +ac_fn_c_check_member "$LINENO" "struct statfs" "f_fsid.__val" "ac_cv_member_struct_statfs_f_fsid___val" "#include <sys/types.h> > +#ifdef HAVE_SYS_PARAM_H > +# include <sys/param.h> > +#endif > +#ifdef HAVE_SYS_MOUNT_H > +# include <sys/mount.h> > +#endif > +#ifdef HAVE_SYS_VFS_H > +# include <sys/vfs.h> > +#endif > +#ifdef HAVE_SYS_STATFS_H > +# include <sys/statfs.h> > +#endif > +" > +if test "x$ac_cv_member_struct_statfs_f_fsid___val" = xyes; then : > + > +cat >>confdefs.h <<_ACEOF > +#define HAVE_STRUCT_STATFS_F_SID_VAL 1 > +_ACEOF > + > + > +fi > + > + > ac_fn_c_check_member "$LINENO" "struct statvfs" "f_blocks" "ac_cv_member_struct_statvfs_f_blocks" "#ifdef HAVE_SYS_STATVFS_H > #include <sys/statvfs.h> > #endif There is usually no need to include changes for configure. It will automatically be updated when your patch gets accepted. The same also applies to config.h.in. > diff --git a/configure.ac b/configure.ac > index 353f271..3790a39 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2277,6 +2277,22 @@ AC_CHECK_MEMBERS([struct statfs.f_bfree, struct statfs.f_bavail, struct statfs.f > # include <sys/statfs.h> > #endif]) > > +dnl Check for f_fsid.__val > +AC_CHECK_MEMBERS([struct f_fsid.f_fsid.__val],,, Shouldn't this be "struct statfs.[...]" ? And is there any reason why this isn't merged in the block above, which checks other statfs fields? > +[#include <sys/types.h> > +#ifdef HAVE_SYS_PARAM_H > +# include <sys/param.h> > +#endif > +#ifdef HAVE_SYS_MOUNT_H > +# include <sys/mount.h> > +#endif > +#ifdef HAVE_SYS_VFS_H > +# include <sys/vfs.h> > +#endif > +#ifdef HAVE_SYS_STATFS_H > +# include <sys/statfs.h> > +#endif]) > + > AC_CHECK_MEMBERS([struct statvfs.f_blocks],,, > [#ifdef HAVE_SYS_STATVFS_H > #include <sys/statvfs.h> > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 6eddd19..38ca0c5 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2379,7 +2379,7 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileRenameInformationBypassAccessCheck */ > 0, /* FileLinkInformationBypassAccessCheck */ > 0, /* FileVolumeNameInformation */ > - 0, /* FileIdInformation */ > + sizeof(FILE_ID_INFORMATION), /* FileIdInformation */ > 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > 0, /* FileHardLinkFullIdInformation */ > @@ -2621,6 +2621,26 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > } > } > break; > + case FileIdInformation: > + { > + struct statfs volstats; > + FILE_ID_INFORMATION *info = ptr; > + if ((fstat(fd, &st) == -1) || (fstatfs(fd, &volstats) == -1)) Other blocks using fstatfs are protected with an #if defined(HAVE_FSTATFS) check. You might need that here, too. > + { > + io->u.Status = FILE_GetNtStatus(); > + } > + else > + { > + memset(info, 0, sizeof(*info)); > +#ifdef HAVE_STRUCT_STATFS_F_SID_VAL With my version of autoconf, the define is called HAVE_STRUCT_F_FSID_F_FSID___VAL (with two additional underscores). Are there differences between the versions of autoconf or have you guessed those names? Please note that you can use "autoreconf -f" to update various files automatically after changing configure.ac. > + memcpy(&info->VolumeSerialNumber, > + &volstats.f_fsid.__val, > + min(sizeof(info->VolumeSerialNumber), sizeof(volstats.f_fsid.__val))); > +#endif > + ((PLARGE_INTEGER)&info->FileId)->QuadPart = st.st_ino; Not really an issue, but it is usually preferred to avoid P* types. You could also write: ((LARGE_INTEGER *)&info->FileId)->QuadPart = st.st_ino; To make your changes even more convincing, I would also recommend to take a look at the existing tests and try to add one for this information class. This could for example be used to verify that FileId is indeed identical to the (smaller) FileId returned by some other info classes. > + } > + } > + break; > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > diff --git a/include/config.h.in b/include/config.h.in > index 5dcd90b..6bba9df 100644 > --- a/include/config.h.in > +++ b/include/config.h.in > @@ -963,6 +963,9 @@ > /* Define to 1 if `f_namelen' is a member of `struct statfs'. */ > #undef HAVE_STRUCT_STATFS_F_NAMELEN > > +/* Define to 1 if `f_fsid.__val' is a member of `struct statfs'. */ > +#undef HAVE_STRUCT_STATFS_F_SID_VAL > + > /* Define to 1 if `f_blocks' is a member of `struct statvfs'. */ > #undef HAVE_STRUCT_STATVFS_F_BLOCKS > > diff --git a/include/winbase.h b/include/winbase.h > index eff5972..83c27f8 100644 > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -905,6 +905,15 @@ typedef struct _FILE_REMOTE_PROTOCOL_INFO { > } ProtocolSpecificReserved; > } FILE_REMOTE_PROTOCOL_INFO, *PFILE_REMOTE_PROTOCOL_INFO; Those changes should probably go to include/winternl.h. On Windows they are in include/ntifs.h, but we don't have that in Wine yet, and all other FILE_*_INFORMATION structs are also in winternl.h. > > +typedef struct _FILE_ID_128 { > + BYTE Identifier[16]; My header files define this as UCHAR array. If there are multiple versions out there it shouldn't matter what you use, otherwise I would suggest to stick to what is used in official header files. > +} FILE_ID_128, *PFILE_ID_128; > + > +typedef struct _FILE_ID_INFORMATION { > + ULONGLONG VolumeSerialNumber; > + FILE_ID_128 FileId; > +} FILE_ID_INFORMATION, *PFILE_ID_INFORMATION; > + > #define PIPE_ACCESS_INBOUND 1 > #define PIPE_ACCESS_OUTBOUND 2 > #define PIPE_ACCESS_DUPLEX 3 > Feel free to ask if you have any questions. Regards, Sebastian

1 0

Re: [v2 1/3] ntdll: Define more file information classes.
by Sebastian Lackner 03 Feb '17

03 Feb '17

On 26.01.2017 12:09, Jonathan Doron wrote: > Signed-off-by: Jonathan Doron <jond(a)wizery.com> > --- > dlls/ntdll/file.c | 7 +++++++ > include/winternl.h | 7 +++++++ > 2 files changed, 14 insertions(+) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index e1583da..6eddd19 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2376,7 +2376,14 @@ NTSTATUS WINAPI NtQueryInformationFile( HANDLE hFile, PIO_STATUS_BLOCK io, > 0, /* FileNumaNodeInformation */ > 0, /* FileStandardLinkInformation */ > 0, /* FileRemoteProtocolInformation */ > + 0, /* FileRenameInformationBypassAccessCheck */ > + 0, /* FileLinkInformationBypassAccessCheck */ > + 0, /* FileVolumeNameInformation */ > + 0, /* FileIdInformation */ > + 0, /* FileIdExtdDirectoryInformation */ > 0, /* FileReplaceCompletionInformation */ > + 0, /* FileHardLinkFullIdInformation */ > + 0, /* FileIdExtdBothDirectoryInformation */ > }; > > struct stat st; > diff --git a/include/winternl.h b/include/winternl.h > index f35091c..891b6a7 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -441,7 +441,14 @@ typedef enum _FILE_INFORMATION_CLASS { > FileNumaNodeInformation, > FileStandardLinkInformation, > FileRemoteProtocolInformation, > + FileRenameInformationBypassAccessCheck, > + FileLinkInformationBypassAccessCheck, > + FileVolumeNameInformation, > + FileIdInformation, > + FileIdExtdDirectoryInformation, > FileReplaceCompletionInformation, > + FileHardLinkFullIdInformation, > + FileIdExtdBothDirectoryInformation, > FileMaximumInformation It looks like the FileMaximumInformation constant is also used in the ntdll/directory tests. Unfortunately, your patch introduces new test failures (not catched automatically because include file changes do not trigger test runs): https://newtestbot.winehq.org/JobDetails.pl?Key=28259. You will have to update those files in the same patch to ensure all tests still pass. Best regards, Sebastian > } FILE_INFORMATION_CLASS, *PFILE_INFORMATION_CLASS; > >

1 0

Re: [1/2] iphlpapi: Add GetUnicastIpAddressEntry implementation (resend)
by Bruno Jesus 03 Feb '17

03 Feb '17

On Thu, Feb 2, 2017 at 9:08 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > For https://bugs.winehq.org/show_bug.cgi?id=41753 > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > resending, because of bad timing together with the testbot > > dlls/iphlpapi/iphlpapi.spec | 2 +- > dlls/iphlpapi/iphlpapi_main.c | 77 +++++++++++++++++++++++++++++++++++++++++++ > include/netioapi.h | 17 ++++++++++ > include/ws2def.h | 13 ++++++++ > include/ws2ipdef.h | 7 ++++ > 5 files changed, 115 insertions(+), 1 deletion(-) > > diff --git a/dlls/iphlpapi/iphlpapi.spec b/dlls/iphlpapi/iphlpapi.spec > index 500267c..1a1f8f7 100644 > --- a/dlls/iphlpapi/iphlpapi.spec > +++ b/dlls/iphlpapi/iphlpapi.spec > @@ -147,7 +147,7 @@ > @ stub GetUdpStatsFromStack > @ stdcall GetUdpTable( ptr ptr long ) > @ stub GetUdpTableFromStack > -#@ stub GetUnicastIpAddressEntry > +@ stdcall GetUnicastIpAddressEntry( ptr ) > #@ stub GetUnicastIpAddressTable > @ stdcall GetUniDirectionalAdapterInfo( ptr ptr ) > @ stdcall Icmp6CreateFile() > diff --git a/dlls/iphlpapi/iphlpapi_main.c b/dlls/iphlpapi/iphlpapi_main.c > index 1daf54d..ff0ad3f 100644 > --- a/dlls/iphlpapi/iphlpapi_main.c > +++ b/dlls/iphlpapi/iphlpapi_main.c > @@ -2467,6 +2467,83 @@ DWORD WINAPI GetExtendedUdpTable(PVOID pUdpTable, PDWORD pdwSize, BOOL bOrder, > return ret; > } > > +DWORD WINAPI GetUnicastIpAddressEntry(MIB_UNICASTIPADDRESS_ROW *row) > +{ > + char buf[MAX_ADAPTER_NAME], *name; > + IP_ADAPTER_ADDRESSES *aa, *ptr; > + ULONG size = 0; > + DWORD ret; > + > + TRACE("%p\n", row); > + > + if (!row) > + return ERROR_INVALID_PARAMETER; > + > + if ((!(name = getInterfaceNameByIndex( row->InterfaceIndex, buf )) && > + !(name = getInterfaceNameByIndex( row->InterfaceLuid.Info.NetLuidIndex, buf )))) > + return ERROR_FILE_NOT_FOUND; > + > + GetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, NULL, &size); > + ptr = HeapAlloc(GetProcessHeap(), 0, size); > + ret = GetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, ptr, &size); Is it possible to restrict GetAdaptersAddresses family to the one passed in the row? Because in the loop below you check if it matches and skip. If it is possible you could get rid of the row->Address.si_family != uaaddr->si_family test in the loop. > + if (FAILED(ret)) > + { > + HeapFree(GetProcessHeap(), 0, ptr); > + return ret; > + } > + > + ret = ERROR_FILE_NOT_FOUND; > + > + for (aa = ptr; aa; aa = aa->Next) > + { > + IP_ADAPTER_UNICAST_ADDRESS *ua; > + > + if (aa->u.s.IfIndex != row->InterfaceIndex) > + continue; > + > + ret = ERROR_NOT_FOUND; > + > + if (!aa->FirstUnicastAddress) > + continue; Is this really necessary? Since the while will not loop if ua = NULL too. > + ua = aa->FirstUnicastAddress; > + while (ua) > + { > + SOCKADDR_INET *uaaddr = (SOCKADDR_INET *)ua->Address.lpSockaddr; > + if (row->Address.si_family != uaaddr->si_family) > + { > + ua = ua->Next; > + continue; > + } > + > + if ((row->Address.si_family == WS_AF_INET6 && !memcmp(&row->Address.Ipv6.sin6_addr, &uaaddr->Ipv6.sin6_addr, sizeof(row->Address.Ipv6.sin6_addr))) || > + (row->Address.si_family == WS_AF_INET && !memcmp(&row->Address.Ipv4.sin_addr, &uaaddr->Ipv4.sin_addr, sizeof(row->Address.Ipv4.sin_addr)))) > + { > + memcpy(&row->InterfaceLuid, &aa->Luid, sizeof(aa->Luid)); > + row->InterfaceIndex = aa->u.s.IfIndex; > + row->PrefixOrigin = ua->PrefixOrigin; > + row->SuffixOrigin = ua->SuffixOrigin; > + row->ValidLifetime = ua->ValidLifetime; > + row->PreferredLifetime = ua->PreferredLifetime; > + row->OnLinkPrefixLength = ua->OnLinkPrefixLength; > + row->SkipAsSource = 0; > + row->DadState = ua->DadState; > + if (aa->IfType != IF_TYPE_SOFTWARE_LOOPBACK && row->Address.si_family == WS_AF_INET6) > + row->ScopeId.Value = aa->Ipv6IfIndex; > + else > + row->ScopeId.Value = 0; As I said in the tests and just to say again, that I don't know where this scopeid = ifindex comes from. > + NtQuerySystemTime(&row->CreationTimeStamp); > + HeapFree(GetProcessHeap(), 0, ptr); > + return NO_ERROR; > + } > + ua = ua->Next; > + } > + } > + HeapFree(GetProcessHeap(), 0, ptr); > + > + return ret; > +} > + Best wishes, Bruno

1 0

Re: [2/2] iphlpapi/tests: Add tests for GetUnicastIpAddressEntry (resend)
by Bruno Jesus 03 Feb '17

03 Feb '17

On Thu, Feb 2, 2017 at 9:09 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > > resending, because of bad timing together with the testbot > > dlls/iphlpapi/tests/iphlpapi.c | 102 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 102 insertions(+) > > diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c > index e4a5864..3814548 100644 > --- a/dlls/iphlpapi/tests/iphlpapi.c > +++ b/dlls/iphlpapi/tests/iphlpapi.c > @@ -75,6 +75,7 @@ static DWORD (WINAPI *pGetTcpTable)(PMIB_TCPTABLE,PDWORD,BOOL); > static DWORD (WINAPI *pGetUdpTable)(PMIB_UDPTABLE,PDWORD,BOOL); > static DWORD (WINAPI *pGetPerAdapterInfo)(ULONG,PIP_PER_ADAPTER_INFO,PULONG); > static DWORD (WINAPI *pGetAdaptersAddresses)(ULONG,ULONG,PVOID,PIP_ADAPTER_ADDRESSES,PULONG); > +static DWORD (WINAPI *pGetUnicastIpAddressEntry)(MIB_UNICASTIPADDRESS_ROW*); > static DWORD (WINAPI *pNotifyAddrChange)(PHANDLE,LPOVERLAPPED); > static BOOL (WINAPI *pCancelIPChangeNotify)(LPOVERLAPPED); > static DWORD (WINAPI *pGetExtendedTcpTable)(PVOID,PDWORD,BOOL,ULONG,TCP_TABLE_CLASS,ULONG); > @@ -123,6 +124,7 @@ static void loadIPHlpApi(void) > pGetUdpTable = (void *)GetProcAddress(hLibrary, "GetUdpTable"); > pGetPerAdapterInfo = (void *)GetProcAddress(hLibrary, "GetPerAdapterInfo"); > pGetAdaptersAddresses = (void *)GetProcAddress(hLibrary, "GetAdaptersAddresses"); > + pGetUnicastIpAddressEntry = (void *)GetProcAddress(hLibrary, "GetUnicastIpAddressEntry"); > pNotifyAddrChange = (void *)GetProcAddress(hLibrary, "NotifyAddrChange"); > pCancelIPChangeNotify = (void *)GetProcAddress(hLibrary, "CancelIPChangeNotify"); > pGetExtendedTcpTable = (void *)GetProcAddress(hLibrary, "GetExtendedTcpTable"); > @@ -1965,6 +1967,105 @@ static void test_GetIfTable2(void) > pFreeMibTable( table ); > } > > +static void test_GetUnicastIpAddressEntry(void) > +{ > + IP_ADAPTER_ADDRESSES *aa, *ptr; > + MIB_UNICASTIPADDRESS_ROW row; > + DWORD ret, size; > + > + if (!pGetUnicastIpAddressEntry) > + { > + win_skip( "GetUnicastIpAddressEntry not available\n" ); > + return; > + } > + if (!pGetAdaptersAddresses) > + { > + win_skip("GetAdaptersAddresses not present\n"); > + return; > + } > + > + ret = pGetUnicastIpAddressEntry( NULL ); > + ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); > + > + memset( &row, 0, sizeof(row) ); > + ret = pGetUnicastIpAddressEntry( &row ); > + todo_wine ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); > + > + memset( &row, 0, sizeof(row) ); > + row.Address.Ipv4.sin_family = AF_INET; > + row.Address.Ipv4.sin_port = 0; > + row.Address.Ipv4.sin_addr.S_un.S_addr = 0x01020304; > + ret = pGetUnicastIpAddressEntry( &row ); > + ok( ret == ERROR_FILE_NOT_FOUND, "got %u\n", ret ); > + > + memset( &row, 0, sizeof(row) ); > + row.InterfaceIndex = 123; > + ret = pGetUnicastIpAddressEntry( &row ); > + todo_wine ok( ret == ERROR_INVALID_PARAMETER, "got %u\n", ret ); > + > + memset( &row, 0, sizeof(row) ); > + row.InterfaceIndex = get_interface_index(); > + row.Address.Ipv4.sin_family = AF_INET; > + row.Address.Ipv4.sin_port = 0; > + row.Address.Ipv4.sin_addr.S_un.S_addr = 0x01020304; > + ret = pGetUnicastIpAddressEntry( &row ); > + ok( ret == ERROR_NOT_FOUND, "got %u\n", ret ); > + > + memset( &row, 0, sizeof(row) ); > + row.InterfaceIndex = 123; > + row.Address.Ipv4.sin_family = AF_INET; > + row.Address.Ipv4.sin_port = 0; > + row.Address.Ipv4.sin_addr.S_un.S_addr = 0x01020304; > + ret = pGetUnicastIpAddressEntry( &row ); > + ok( ret == ERROR_FILE_NOT_FOUND, "got %u\n", ret ); > + > + ret = pGetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, NULL, &size); > + ok(ret == ERROR_BUFFER_OVERFLOW, "expected ERROR_BUFFER_OVERFLOW, got %u\n", ret); > + if (ret != ERROR_BUFFER_OVERFLOW) return; > + > + ptr = HeapAlloc(GetProcessHeap(), 0, size); > + ret = pGetAdaptersAddresses(AF_UNSPEC, GAA_FLAG_INCLUDE_ALL_INTERFACES | GAA_FLAG_INCLUDE_PREFIX, NULL, ptr, &size); > + ok(!ret, "expected ERROR_SUCCESS got %u\n", ret); > + > + for (aa = ptr; !ret && aa; aa = aa->Next) > + { > + IP_ADAPTER_UNICAST_ADDRESS *ua; > + > + ua = aa->FirstUnicastAddress; > + while (ua) > + { > + memset( &row, 0, sizeof(row) ); > + row.InterfaceIndex = S(U(*aa)).IfIndex; > + memcpy(&row.Address, ua->Address.lpSockaddr, ua->Address.iSockaddrLength); > + > + ret = pGetUnicastIpAddressEntry( &row ); > + ok( ret == NO_ERROR, "got %u\n", ret ); > + ok( row.InterfaceIndex == S(U(*aa)).IfIndex, "got %u\n", row.InterfaceIndex ); > + if (ret == NO_ERROR) > + { > + ok(row.InterfaceLuid.Info.Reserved == aa->Luid.Info.Reserved, "Expected %d, got %d\n", aa->Luid.Info.Reserved, row.InterfaceLuid.Info.Reserved); > + ok(row.InterfaceLuid.Info.NetLuidIndex == aa->Luid.Info.NetLuidIndex, "Expected %d, got %d\n", aa->Luid.Info.NetLuidIndex, row.InterfaceLuid.Info.NetLuidIndex); > + ok(row.InterfaceLuid.Info.IfType == aa->Luid.Info.IfType, "Expected %d, got %d\n", aa->Luid.Info.IfType, row.InterfaceLuid.Info.IfType); > + ok(row.InterfaceIndex == aa->IfIndex, "Expected %d, got %d\n", aa->IfIndex, row.InterfaceIndex); > + ok(row.PrefixOrigin == ua->PrefixOrigin, "Expected %d, got %d\n", ua->PrefixOrigin, row.PrefixOrigin); > + ok(row.SuffixOrigin == ua->SuffixOrigin, "Expected %d, got %d\n", ua->SuffixOrigin, row.SuffixOrigin); > + ok(row.ValidLifetime == ua->ValidLifetime, "Expected %d, got %d\n", ua->ValidLifetime, row.ValidLifetime); > + ok(row.PreferredLifetime == ua->PreferredLifetime, "Expected %d, got %d\n", ua->PreferredLifetime, row.PreferredLifetime); > + ok(row.OnLinkPrefixLength == ua->OnLinkPrefixLength, "Expected %d, got %d\n", ua->OnLinkPrefixLength, row.OnLinkPrefixLength); > + ok(row.SkipAsSource == 0, "Expected 0, got %d\n", row.SkipAsSource); > + ok(row.DadState == ua->DadState, "Expected %d, got %d\n", ua->DadState, row.DadState); Some of these lines are a bit too long, like over 170 characters. Can you break line between message and parameters? > + if (aa->IfType != IF_TYPE_SOFTWARE_LOOPBACK && row.Address.si_family == AF_INET6) > + ok(row.ScopeId.Value == aa->Ipv6IfIndex || broken(row.ScopeId.Value == 0), "Expected %d, got %d\n", aa->Ipv6IfIndex, row.ScopeId.Value); Is this really true? The index is supposed to be the same as scope ID? The broken makes it suspicious. I can't find any docs to back that. > + else > + ok(row.ScopeId.Value == 0, "Expected 0, got %d\n", row.ScopeId.Value); > + ok(row.CreationTimeStamp.QuadPart, "CreationTimeStamp is 0\n"); > + } > + ua = ua->Next; > + } > + } > + HeapFree(GetProcessHeap(), 0, ptr); > +} > + > START_TEST(iphlpapi) > { > > @@ -1989,6 +2090,7 @@ START_TEST(iphlpapi) > test_interface_identifier_conversion(); > test_GetIfEntry2(); > test_GetIfTable2(); > + test_GetUnicastIpAddressEntry(); > freeIPHlpApi(); > } > } > -- > 2.7.4 > > >

1 0

Re: [2/2] iphlpapi/tests: Add tests for GetUnicastIpAddressEntry
by Marvin 02 Feb '17

02 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28247 Your paranoid android. === build (build) === Make failed

1 0

Re: [v3 4/6] user32: Add WM_NCPAINT tests for windows crossing screen or maximized
by Marvin 02 Feb '17

02 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28244 Your paranoid android. === wxppro (32 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === wvistau64 (32 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7u (32 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7pro64 (32 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === wvistau64 (64 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7pro64 (64 bit msg) === msg.c:5216: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085

1 0

Re: [v3 3/6] user32: Add tests for windows when first shown if they have children
by Marvin 02 Feb '17

02 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28243 Your paranoid android. === wxppro (32 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === wvistau64 (32 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7u (32 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7pro64 (32 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === wvistau64 (64 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085 === w7pro64 (64 bit msg) === msg.c:5141: Test failed: SetWindowPos:show_popup_first_show_window_child2: 2: the msg sequence is not complete: expected 0000 - actual 0085

1 0

Re: winex11: Remove dead assignment (clang)
by Aric Stewart 02 Feb '17

02 Feb '17

Are you sure that is dead? clang must be saying so but the assignment of ximStyleCallback to ximStyle seems meaningful. Just above this code we have code that ensures that ximStyle is not 0, so if ximStyleCallback == 0 then assigning ximStyleCallback = ximStyle does not seem dead to me. -aric > From: André Hentschel <nerv(a)dawncrow.de> > Subject: winex11: Remove dead assignment (clang) > Message-Id: <8472d171-8b3b-04a7-62cf-a99ee7a37026(a)dawncrow.de> > Date: Mon, 30 Jan 2017 23:11:02 +0100 > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/winex11.drv/xim.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c > index e51169d..3978bca 100644 > --- a/dlls/winex11.drv/xim.c > +++ b/dlls/winex11.drv/xim.c > @@ -416,10 +416,7 @@ static BOOL open_xim( Display *display ) > ximStyle = ximStyleNone; > > if (ximStyleCallback == 0) > - { > TRACE("No callback style available\n"); > - ximStyleCallback = ximStyle; > - } > > } > > > -- > 2.7.4

4 5

Re: [PATCH 1/2] user32: Send WM_NCPAINT and WM_ERASEBKGND when window is shown and add tests
by Alexandre Julliard 02 Feb '17

02 Feb '17

Fabian Maurer <dark.shadow4(a)web.de> writes: > Fixes Bug 2624 and 6682 and a few others > > v2: Make patch independent from the WM_NCPAINT issue > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/user32/tests/msg.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/user32/winpos.c | 7 ++++ > 2 files changed, 111 insertions(+) This would also need tests for child windows, and for various flag combinations. In particular I expect you'd have to handle SWP_DEFERERASE. It would also be more convincing with tests calling SetWindowPos directly instead of through ShowWindow. And whatever changes are necessary should most likely be merged into the existing erase_now() call. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 8/8] wined3d: Implement applying state for compute pipeline.
by Henri Verbeet 02 Feb '17

02 Feb '17

On 2 February 2017 at 12:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -3520,19 +3546,19 @@ BOOL context_apply_draw_state(struct wined3d_context *context, > wined3d_buffer_load_sysmem(state->index_buffer, context); > } > > - for (i = 0; i < context->numDirtyEntries; ++i) > + for (i = 0, dirty_idx = 0; i < context->numDirtyEntries; ++i) > { > DWORD rep = context->dirtyArray[i]; > - DWORD idx = rep / (sizeof(*context->isStateDirty) * CHAR_BIT); > - BYTE shift = rep & ((sizeof(*context->isStateDirty) * CHAR_BIT) - 1); > - context->isStateDirty[idx] &= ~(1u << shift); > - state_table[rep].apply(context, state, rep); > + if (!is_compute_state(rep)) > + apply_state(context, state_table, state, rep); > + else > + context->dirtyArray[dirty_idx++] = rep; I'd rather not do this. How important is it to avoid applying compute dispatch states for draws and vice-versa? As an aside, "dirtyArray" is mostly redundant, and possibly a little harmful.

3 3

Re: [PATCH 3/3] ole2.dll16: Implement several IIDs.
by Huw Davies 02 Feb '17

02 Feb '17

On Wed, Feb 01, 2017 at 10:23:55PM -0600, Zebediah Figura wrote: > Needed for https://appdb.winehq.org/objectManager.php?sClass=version&iId=32136 > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/ole2.dll16/ole2.dll16.spec | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/dlls/ole2.dll16/ole2.dll16.spec b/dlls/ole2.dll16/ole2.dll16.spec > index ed5e917..2789cdc 100644 > --- a/dlls/ole2.dll16/ole2.dll16.spec > +++ b/dlls/ole2.dll16/ole2.dll16.spec > @@ -111,10 +111,10 @@ > 126 stub _IID_IENUMGENERIC > 127 stub _IID_IENUMHOLDER > 128 stub _IID_IENUMCALLBACK > -129 stub _IID_IPERSISTSTREAM > -130 stub _IID_IPERSISTSTORAGE > +129 variable _IID_IPersistStream(0x00000109 0x00000000 0x000000c0 0x46000000) > +130 variable _IID_IPersistStorage(0x0000010a 0x00000000 0x000000c0 0x46000000) > 131 stub _IID_IPERSISTFILE > -132 stub _IID_IPERSIST > +132 variable _IPersist(0x0000010c 0x00000000 0x000000c0 0x46000000) Did you mean to drop the '_IID' prefix here? Huw.

2 1

Stubs in spec files
by Zebediah Figura 02 Feb '17

02 Feb '17

Hi, I am a novice developer with a question about the spec files. Currently the .spec files contain stub lines for functions which have no implementation, and the compiler creates assembly thunks to __wine_spec_unimplemented_stub, which raises an exception when the function is called. However, some entries in the spec files are actually not functions but data, and when applications attempt to read this data they instead read the instruction code of the thunks. I recently was debugging a 16-bit application [1] which was referring to a GUID that I could not find defined anywhere, and only after some time was able to figure out that the application was reading the thunk code for _IID_IClassFactory in this way. The NE segment loading code in krnl386.dll16 will print a warning if an application attempts to request the location of a symbol not defined in the library. However, since the stubs are defined, no such message is printed, but the program will effectively be given a pointer to junk memory. As far as I can tell there is no way to add such a message either. What would in fact work is not to implement stub code in the libraries at all. In 16-bit code this results in a warning when the value is accessed, followed by a crash if it is a function which the code attempts to call. In 32-bit code this seems to behave identically to a stub function. Thus the only difference is that in 16-bit code (and possibly 32-bit code, but I could not find any variable that I could test with) a warning is printed (and 0xdeadbeef is returned instead of junk memory), which I see as a definite improvement. By commenting out all of the stub lines in compobj.dll16.spec I was able to locate several more that the program requested, but I may still be missing some in other DLLs. My question, then, is—is there any purpose of the stub lines besides to directly call __wine_spec_unimplemented_stub, or any other reason why this proposal would be detrimental? Thanks, Zebediah Figura

3 4

Re: [PATCH 3/3] mshtml/tests: Added COM aggregation tests.
by Marvin 02 Feb '17

02 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28226 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2643: Test failed: unexpected call GetOverrideKeyPath htmldoc.c:5053: Test failed: unexpected call {d9befc84-f21e-4166-874b-a8d3010dc764}

1 0

Re: [PATCH 2/2] comdlg32: Delay OleInitialize() for Windows versions older than Vista.
by Alexandre Julliard 02 Feb '17

02 Feb '17

Józef Kucia <jkucia(a)codeweavers.com> writes: > This fixes a regression introduced by commit > f65e04770dc5748521a0de73814cea0b085bf3f8. > > OleInitialize() creates a window for the main apartment. SimCity 2000 > expects that the first created window after GetOpenFileA() is a file > dialog window. According to tests, this is expected to work on Windows > versions before Windows Vista. > > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> Is a version check really necessary? Couldn't we find some better way? In what way does the app depend on the window creation order? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 6/8] wined3d: Introduce wined3d_device_dispatch_compute().
by Henri Verbeet 02 Feb '17

02 Feb '17

On 2 February 2017 at 12:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index a3d88b9..4980413 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -580,3 +580,46 @@ void draw_primitive(struct wined3d_device *device, const struct wined3d_state *s > > TRACE("Done all gl drawing.\n"); > } > + > +void dispatch_compute(struct wined3d_device *device, const struct wined3d_state *state, > + unsigned int group_count_x, unsigned int group_count_y, unsigned int group_count_z) I don't care too much, but in the longer term I'd be inclined to merge drawprim.c into some other file like context.c.

1 0

Re: [PATCH 3/5] wined3d: Fix querying texture-related limits on core profile.
by Józef Kucia 02 Feb '17

02 Feb '17

On Thu, Feb 2, 2017 at 1:04 AM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > else > { > gl_info->limits.texture_coords = max(gl_info->limits.texture_coords, gl_max); > + TRACE("Max texture coords: %d.\n", gl_info->limits.texture_coords); > gl_info->limits.fragment_samplers = max(gl_info->limits.fragment_samplers, gl_max); > } Is this "else" block supposed to be executed only for legacy contexts? It might be better to merge it into the "if (gl_info->supported[WINED3D_GL_LEGACY_CONTEXT])" block above.

1 0

Re: user32: Hardcode the GetWindowLong values for the desktop window to avoid a server round-trip.
by Marvin 02 Feb '17

02 Feb '17

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://testbot.winehq.org/JobDetails.pl?Key=28217 Your paranoid android. === w7u (32 bit win) === win.c:1003: Test failed: wrong dwWindowStatus: 0000 != 0001 active 00CD01B0 fg 000401AE in hook HCBT_MINMAX

2 1

Re: [PATCH v2] user32: In menu.c converted all tabs to spaces
by Michael Stefaniuc 02 Feb '17

02 Feb '17

Hello Fabian, On 02/01/2017 11:25 PM, Fabian Maurer wrote: > This change makes it a lot to edit easier with some editors. > Conversion done with Notepad++, with tabsize 8 spaces. > > v2: removed trailing whitespace > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/user32/menu.c | 1922 ++++++++++++++++++++++++++-------------------------- > 1 file changed, 961 insertions(+), 961 deletions(-) sorry, but this is just change noise. You can do the TAB to SPACE changes en passant when modifying the respective lines. Probably the only valid exception is when the indentation of the code is visibly messed up. But that's not the case here. bye michael

2 3

Re: user32: Avoid querying the server to determine whether the desktop window is a child window.
by Alexandre Julliard 02 Feb '17

02 Feb '17

Huw Davies <huw(a)codeweavers.com> writes: > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > dlls/user32/win.c | 31 +++++++++++++++++++++++++++++-- > 1 file changed, 29 insertions(+), 2 deletions(-) > > diff --git a/dlls/user32/win.c b/dlls/user32/win.c > index a7be4a3..341769f 100644 > --- a/dlls/user32/win.c > +++ b/dlls/user32/win.c > @@ -414,6 +414,33 @@ static HWND *list_window_parents( HWND hwnd ) > return NULL; > } > > +/******************************************************************* > + * is_child_win > + * > + * Helper to determine whether WS_CHILD is set. > + * It avoids a server round trip for the desktop window. > + */ We could probably make GetWindowLong return hardcoded values for the desktop window, so that all callers benefit. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages
by Andrew Eikum 02 Feb '17

02 Feb '17

On Tue, Jan 31, 2017 at 04:16:17AM -0200, Bruno Jesus wrote: > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. > Looking at this spec, should Tune Request be handled the same way as these system real time messages? I also noticed Reset is still handled as a SysEx after your patch. Should it be? Aside from that, I also noticed an old patch that unfortunately never got merged: https://www.winehq.org/pipermail/wine-patches/2013-January/121366.html If you understand this MIDI stuff a little bit, you might be a good person to review and re-submit that patch :) Thanks, Andrew

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel