December 2020 - Wine-Devel - list.winehq.org

[PATCH] ws2_32/tests: Don't fail the test in test_wsaioctl() if only one interface is available.

by Paul Gofman

Fixes test failure on Testbot. Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> --- dlls/ws2_32/tests/sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c index 98cc3881853..2b0a7354f4b 100644 --- a/dlls/ws2_32/tests/sock.c +++ b/dlls/ws2_32/tests/sock.c @@ -10530,7 +10530,7 @@ static void test_wsaioctl(void) ok(size && size != 0xdeadbeef && !(size % sizeof(INTERFACE_INFO)), "Got unexpected size %u.\n", size); size = 0xdeadbeef; - ret = WSAIoctl(s, SIO_GET_INTERFACE_LIST, NULL, 0, buffer, sizeof(INTERFACE_INFO), &size, NULL, NULL); + ret = WSAIoctl(s, SIO_GET_INTERFACE_LIST, NULL, 0, buffer, sizeof(INTERFACE_INFO) - 1, &size, NULL, NULL); ok(ret == -1, "Got unexpected ret %d.\n", ret); ok(WSAGetLastError() == WSAEFAULT, "Got unexpected error %d.\n", WSAGetLastError()); ok(!size, "Got unexpected size %u.\n", size); -- 2.29.2

Dec. 17, 2020

Re: [RFC] Announcing Wayland driver development

by Alexandros Frantzis

On Wed, Dec 16, 2020 at 10:24:43AM +0100, Julian Rüger wrote: > > FWIW, I recommend looking at the commit history, how past big changes > > were introduced i.e. the Mac driver, maybe the DIB-Engine (although that > > was quite long ago and a lot has changed since) > > The most recent example of a new driver: > > https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=wineusb Hi Julian, I really appreciate all the feedback and pointers! Thanks, Alexandros

Dec. 17, 2020

[PATCH v2] crypt32/tests: Fix a registerOIDInfo() failure when missing elevated privileges.

by Francois Gouget

Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> --- With my apologies for the previous botched attempt. dlls/crypt32/tests/oid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dlls/crypt32/tests/oid.c b/dlls/crypt32/tests/oid.c index ae03bba90e8..7e7c1310dd2 100644 --- a/dlls/crypt32/tests/oid.c +++ b/dlls/crypt32/tests/oid.c @@ -646,7 +646,8 @@ static void test_registerOIDInfo(void) SetLastError(0xdeadbeef); ret = CryptUnregisterOIDInfo(&info1); ok(!ret, "should fail\n"); - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "got %u\n", GetLastError()); + ok(GetLastError() == ERROR_FILE_NOT_FOUND || + GetLastError() == ERROR_ACCESS_DENIED, "got %u\n", GetLastError()); info2 = CryptFindOIDInfo(CRYPT_OID_INFO_OID_KEY, (void *)test_oid, 0); ok(!info2, "should fail\n"); -- 2.20.1

Dec. 17, 2020

Looking for TestBot help

by Francois Gouget

In these freezing times I'm looking for volunteers to help with three TestBot related tasks: * Modify WineTest to detect which tests can be run by running 'xxx_test --list' and automatically detecting and dismissing the "Missing dll" / "Missing entrypoint" dialogs. This would fix a lot of issues with tests not being run when they should: - Detect and report WineTest's "load errors" https://bugs.winehq.org/show_bug.cgi?id=48062 - Detect missing entry point errors https://bugs.winehq.org/show_bug.cgi?id=48208 * Alternatively the same type of change is needed for the TestBot's TestLauncher where it would replace AllImportedDllsPresent(): https://source.winehq.org/git/tools.git/blob/HEAD:/testbot/src/TestLauncher… There too it will help with a lot of issues: - TestLauncher says a required DLL is missing, but the test runs fine without TestLauncher https://bugs.winehq.org/show_bug.cgi?id=31609 But I expect that once this is done on one side it will be easy to port to the other. So the choice of codebase is yours. * Write or find a Windows tool to automatically take a screenshot every few seconds and deduplicate identical screenshots. The requirements are: - Open-source of course. - No dependency (so if using an off-the-shelf tool it should not require installing some language runtime, etc). - Must support multi-screen configurations, even with slightly different resolutions. - Will eventually need to be used by the TestBot through TestAgentd, either by running this external tool, or be integrated in TestAgentd itself. The same functionality will be needed on Unix. If that's not possible with a Windows tool this may turn into a separate project to do the same on the Unix side. There I expect some scriptable open-source tools to already exist but if one tool can do it all that would be simpler. - Take live/regular screenshots https://bugs.winehq.org/show_bug.cgi?id=44709 In the meantime I'll continue refreshing the test VMs, and working on the website and Engine perl side of things (but if there are volunteers for that you're welcome too). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

Dec. 17, 2020

Re: TestBot job 83503 results: [PATCH] ws2_32: Fix buffer size check in WSAIoctl() for SIO_GET_INTERFACE_LIST.

by Francois Gouget

On Wed, 16 Dec 2020, Paul Gofman wrote: > On 12/16/20 12:10, Marvin wrote: > > ws2_32: > > sock.c:10534: Test failed: Got unexpected ret 0. > > sock.c:10535: Test failed: Got unexpected error 6. > > sock.c:10536: Test failed: Got unexpected size 76. > > Can it be that Wine is not getting updated on Testbot? The tests results > are like the changes to test are applied but ws2_32.dll is unchanged. The "Show full task log" links show that ws2_32.dll.so was rebuilt. https://testbot.winehq.org/JobDetails.pl?Key=83503&f401=task.log#k401 https://testbot.winehq.org/JobDetails.pl?Key=83503&f402=task.log#k402 Also, as far as I can tell, the WinePrefix only contains a fake dll so it does not look like there any way the WinePrefix could use an old version. -- Francois Gouget <fgouget(a)codeweavers.com>

Dec. 17, 2020

Re: [PATCH 2/2] widl: open files to write in binary mode

by Steve Lhomme

On 2020-12-16 16:41, Jacek Caban wrote: > On 16.12.2020 15:35, Steve Lhomme wrote: >> On 2020-12-16 15:18, Jacek Caban wrote: >>> Hi Steve, >>> >>> On 16.12.2020 10:14, Steve Lhomme wrote: >>>> When compiled with mingw64 the output files have Windows line >>>> endings instead >>>> of UNIX ones. >>>> --- >>>> tools/widl/header.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/tools/widl/header.c b/tools/widl/header.c >>>> index 43be8d74cbe..5457185538e 100644 >>>> --- a/tools/widl/header.c >>>> +++ b/tools/widl/header.c >>>> @@ -1893,7 +1893,7 @@ void write_header(const statement_list_t *stmts) >>>> if (!do_header) return; >>>> - if(!(header = fopen(header_name, "w"))) { >>>> + if(!(header = fopen(header_name, "wb"))) { >>> >>> >>> There are more places that would need to be fixed for consistency. >>> Maybe we could use _set_fmode(_O_BINARY) in main() instead? >> >> Is this a MS-only thing ? I don't mind having this patch only in >> mingw-w64-tools (which also have some extra patch as well). > > > Yes, it would need an #ifdef. OK for me. >> In general it may not be the proper way to handle this. For writing >> all files widl generates, it should be fine. But for reading files the >> "binary" mode is not currently used and it may break reading files >> that used to be read properly on Windows ? > > > Which files do you mean? The only non-binary files that widl generates > are headers and C files. I meant that for generated files it's fine, so I agree with you. I fear that forcing binary mode for input files as well may break reading some files with windows line ending on Windows. I don't think that's the case in mingw-w64 but it may have some side effects elsewhere. > Generally speaking, widl output is cross platform, so it should generate > the same output on regardless of host platform used. Windows line ending > breaks that. That's a good incentive to fix this.

Dec. 17, 2020

Re: [PATCH] winegcc: allow CROSSCC to have a suffix

by Marvin

Hi, While running your changed tests, 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=83537 Your paranoid android. === debiant (build log) === collect2: error: ld returned 1 exit status Task: The wow32 Wine build failed

Dec. 17, 2020

[PATCH] winegcc: allow CROSSCC to have a suffix

by Damjan Jovanovic

This allows eg. CROSSCC=i686-w64-mingw32-gcc10. Does not regenerate ./configure. Signed-off-by: Damjan Jovanovic <damjan.jov(a)gmail.com> --- configure.ac | 2 +- tools/winegcc/Makefile.in | 3 ++- tools/winegcc/winegcc.c | 5 ++++- 3 files changed, 7 insertions(+), 3 deletions(-)

Dec. 17, 2020

[rebased PATCH v3 2/2] ntdll: Save unwind information in KiUserApcDispatcher() on x64.

by Paul Gofman

Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> --- v2: - fix build for other archs. dlls/ntdll/tests/exception.c | 53 +++++++++++++++++++++++++++++++++ dlls/ntdll/thread.c | 28 ++++++++++++++++- dlls/ntdll/unix/signal_x86_64.c | 23 ++++++++++++-- 3 files changed, 101 insertions(+), 3 deletions(-) diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c index 5686e39ab9e..3a0a5ac049c 100644 --- a/dlls/ntdll/tests/exception.c +++ b/dlls/ntdll/tests/exception.c @@ -37,6 +37,8 @@ static void *code_mem; static NTSTATUS (WINAPI *pNtGetContextThread)(HANDLE,CONTEXT*); static NTSTATUS (WINAPI *pNtSetContextThread)(HANDLE,CONTEXT*); +static NTSTATUS (WINAPI *pNtQueueApcThread)(HANDLE handle, PNTAPCFUNC func, + ULONG_PTR arg1, ULONG_PTR arg2, ULONG_PTR arg3); static NTSTATUS (WINAPI *pRtlRaiseException)(EXCEPTION_RECORD *rec); static PVOID (WINAPI *pRtlUnwind)(PVOID, PVOID, PEXCEPTION_RECORD, PVOID); static VOID (WINAPI *pRtlCaptureContext)(CONTEXT*); @@ -4061,6 +4063,55 @@ static void test_nested_exception(void) ok(got_prev_frame_exception, "Did not get nested exception in the previous frame.\n"); } +static CONTEXT test_unwind_apc_context; +static BOOL test_unwind_apc_called; + +static void CALLBACK test_unwind_apc(ULONG_PTR arg1, ULONG_PTR arg2, ULONG_PTR arg3) +{ + EXCEPTION_RECORD rec; + + test_unwind_apc_called = TRUE; + memset(&rec, 0, sizeof(rec)); + pRtlUnwind((void *)test_unwind_apc_context.Rsp, (void *)test_unwind_apc_context.Rip, &rec, (void *)0xdeadbeef); + ok(0, "Should not get here.\n"); +} + +static void test_unwind_from_apc(void) +{ + NTSTATUS status; + int pass; + + if (!pNtQueueApcThread) + { + win_skip("NtQueueApcThread is not available.\n"); + return; + } + + pass = 0; + InterlockedIncrement(&pass); + RtlCaptureContext(&test_unwind_apc_context); + InterlockedIncrement(&pass); + + if (pass == 2) + { + test_unwind_apc_called = FALSE; + status = pNtQueueApcThread(GetCurrentThread(), test_unwind_apc, 0, 0, 0); + ok(!status, "Got unexpected status %#x.\n", status); + SleepEx(0, TRUE); + ok(0, "Should not get here.\n"); + } + if (pass == 3) + { + ok(test_unwind_apc_called, "Test user APC was not called.\n"); + test_unwind_apc_called = FALSE; + status = pNtQueueApcThread(GetCurrentThread(), test_unwind_apc, 0, 0, 0); + ok(!status, "Got unexpected status %#x.\n", status); + NtContinue(&test_unwind_apc_context, TRUE ); + ok(0, "Should not get here.\n"); + } + ok(pass == 4, "Got unexpected pass %d.\n", pass); + ok(test_unwind_apc_called, "Test user APC was not called.\n"); +} #elif defined(__arm__) static void test_thread_context(void) @@ -8073,6 +8124,7 @@ START_TEST(exception) #define X(f) p##f = (void*)GetProcAddress(hntdll, #f) X(NtGetContextThread); X(NtSetContextThread); + X(NtQueueApcThread); X(NtReadVirtualMemory); X(NtClose); X(RtlUnwind); @@ -8241,6 +8293,7 @@ START_TEST(exception) skip( "Dynamic unwind functions not found\n" ); test_extended_context(); test_copy_context(); + test_unwind_from_apc(); #elif defined(__aarch64__) diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index 578c7a5436c..5bf456ec040 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -78,7 +78,7 @@ int __cdecl __wine_dbg_output( const char *str ) /******************************************************************* * KiUserApcDispatcher (NTDLL.@) */ -void WINAPI KiUserApcDispatcher( CONTEXT *context, ULONG_PTR ctx, ULONG_PTR arg1, ULONG_PTR arg2, +void WINAPI dispatch_apc( CONTEXT *context, ULONG_PTR ctx, ULONG_PTR arg1, ULONG_PTR arg2, PNTAPCFUNC func ) { func( ctx, arg1, arg2 ); @@ -86,6 +86,32 @@ void WINAPI KiUserApcDispatcher( CONTEXT *context, ULONG_PTR ctx, ULONG_PTR arg1 } +#ifdef __x86_64__ +__ASM_GLOBAL_FUNC( KiUserApcDispatcher, + "addq $0x8,%rsp\n\t" + "mov 0x98(%rcx),%r10\n\t" /* context->Rsp */ + "mov 0xf8(%rcx),%r11\n\t" /* context->Rip */ + "mov %r11,-0x8(%r10)\n\t" + "mov %rbp,-0x10(%r10)\n\t" + "lea -0x10(%r10),%rbp\n\t" + __ASM_SEH(".seh_pushreg %rbp\n\t") + __ASM_SEH(".seh_setframe %rbp,0\n\t") + __ASM_SEH(".seh_endprologue\n\t") + __ASM_CFI(".cfi_signal_frame\n\t") + __ASM_CFI(".cfi_adjust_cfa_offset 0x10\n\t") + __ASM_CFI(".cfi_def_cfa %rbp,0x10\n\t") + __ASM_CFI(".cfi_rel_offset %rip,0x8\n\t") + __ASM_CFI(".cfi_rel_offset %rbp,0\n\t") + "call " __ASM_NAME("dispatch_apc") "\n\t" + "int3") +#else +void WINAPI KiUserApcDispatcher( CONTEXT *context, ULONG_PTR ctx, ULONG_PTR arg1, ULONG_PTR arg2, + PNTAPCFUNC func ) +{ + dispatch_apc( context, ctx, arg1, arg2, func ); +} +#endif + /*********************************************************************** * RtlExitUserThread (NTDLL.@) */ diff --git a/dlls/ntdll/unix/signal_x86_64.c b/dlls/ntdll/unix/signal_x86_64.c index 3ae3b4c141e..837cd9ed654 100644 --- a/dlls/ntdll/unix/signal_x86_64.c +++ b/dlls/ntdll/unix/signal_x86_64.c @@ -2073,9 +2073,28 @@ __ASM_GLOBAL_FUNC( call_user_apc_dispatcher, "movq %r14,%r9\n" /* arg2 */ "movq $0,0x328(%rbx)\n\t" /* amd64_thread_data()->syscall_frame */ "movq %rsi,0x20(%rsp)\n\t" /* func */ - "movq 0xa0(%rcx),%rbp\n\t" /* context.Rbp */ + "movq %rdi,%r10\n\t" + /* Set nonvolatile regs from context. */ + "movq 0xa0(%rcx),%rbp\n\t" + "movq 0x90(%rcx),%rbx\n\t" + "movq 0xa8(%rcx),%rsi\n\t" + "movq 0xb0(%rcx),%rdi\n\t" + "movq 0xd8(%rcx),%r12\n\t" + "movq 0xe0(%rcx),%r13\n\t" + "movq 0xe8(%rcx),%r14\n\t" + "movq 0xf0(%rcx),%r15\n\t" + "movdqa 0x200(%rcx),%xmm6\n\t" + "movdqa 0x210(%rcx),%xmm7\n\t" + "movdqa 0x220(%rcx),%xmm8\n\t" + "movdqa 0x230(%rcx),%xmm9\n\t" + "movdqa 0x240(%rcx),%xmm10\n\t" + "movdqa 0x250(%rcx),%xmm11\n\t" + "movdqa 0x260(%rcx),%xmm12\n\t" + "movdqa 0x270(%rcx),%xmm13\n\t" + "movdqa 0x280(%rcx),%xmm14\n\t" + "movdqa 0x290(%rcx),%xmm15\n\t" "pushq 0xf8(%rcx)\n\t" /* context.Rip */ - "jmp *%rdi" ) + "jmp *%r10" ) /*********************************************************************** -- 2.29.2

Dec. 16, 2020

[rebased PATCH v3 1/2] ntdll: Always copy context in call_user_apc_dispatcher() on x64.

by Paul Gofman

Currently, if call_user_apc_dispatcher() is called with nonzero context, there is no guarantee that the provided context is stored above the rsp = context_ptr->Rsp - (sizeof(CONTEXT) + offsetof(frame,ret_addr)) being set. Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> --- v3: - properly align / reserve stack for setup_user_apc_dispatcher_stack() call. dlls/ntdll/unix/signal_x86_64.c | 62 +++++++++++++++++++++++++-------- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/dlls/ntdll/unix/signal_x86_64.c b/dlls/ntdll/unix/signal_x86_64.c index 7181b48728c..3ae3b4c141e 100644 --- a/dlls/ntdll/unix/signal_x86_64.c +++ b/dlls/ntdll/unix/signal_x86_64.c @@ -250,6 +250,22 @@ C_ASSERT((offsetof(struct stack_layout, xstate) == sizeof(struct stack_layout))) C_ASSERT( sizeof(XSTATE) == 0x140 ); C_ASSERT( sizeof(struct stack_layout) == 0x590 ); /* Should match the size in call_user_exception_dispatcher(). */ +/* stack layout when calling an user apc function. + * FIXME: match Windows ABI. */ +struct apc_stack_layout +{ + ULONG64 save_regs[4]; + void *func; + ULONG64 align; + CONTEXT context; + ULONG64 rbp; + ULONG64 rip; +}; + +/* Should match size and offset in call_user_apc_dispatcher(). */ +C_ASSERT( offsetof(struct apc_stack_layout, context) == 0x30 ); +C_ASSERT( sizeof(struct apc_stack_layout) == 0x510 ); + struct syscall_frame { ULONG64 xmm[10 * 2]; /* xmm6-xmm15 */ @@ -266,6 +282,9 @@ struct syscall_frame ULONG64 ret_addr; }; +/* Should match the offset in call_user_apc_dispatcher(). */ +C_ASSERT( offsetof( struct syscall_frame, ret_addr ) == 0xf0); + struct amd64_thread_data { DWORD_PTR dr0; /* 02f0 debug registers */ @@ -2013,31 +2032,46 @@ static void setup_exception( ucontext_t *sigcontext, EXCEPTION_RECORD *rec ) /*********************************************************************** * call_user_apc_dispatcher */ +struct apc_stack_layout * WINAPI setup_user_apc_dispatcher_stack( CONTEXT *context, struct apc_stack_layout *stack ) +{ + CONTEXT c; + + if (!context) + { + c.ContextFlags = CONTEXT_FULL; + NtGetContextThread( GetCurrentThread(), &c ); + context = &c; + } + memmove( &stack->context, context, sizeof(stack->context) ); + return stack; +} + __ASM_GLOBAL_FUNC( call_user_apc_dispatcher, "movq 0x28(%rsp),%rsi\n\t" /* func */ "movq 0x30(%rsp),%rdi\n\t" /* dispatcher */ "movq %gs:0x30,%rbx\n\t" - "jrcxz 1f\n\t" - "movq 0x98(%rcx),%rax\n\t" /* context_ptr->Rsp */ - "leaq -0x5c0(%rax),%rsp\n\t" /* sizeof(CONTEXT) + offsetof(frame,ret_addr) */ - "andq $~15,%rsp\n\t" - "jmp 2f\n" - "1:\tmovq 0x328(%rbx),%rax\n\t" /* amd64_thread_data()->syscall_frame */ - "leaq -0x4d0(%rax),%rsp\n\t" - "andq $~15,%rsp\n\t" "movq %rdx,%r12\n\t" /* ctx */ "movq %r8,%r13\n\t" /* arg1 */ "movq %r9,%r14\n\t" /* arg2 */ - "movq %rsp,%rdx\n\t" /* context */ - "movl $0x10000b,0x30(%rdx)\n\t" /* context.ContextFlags */ - "movq $~1,%rcx\n\t" - "call " __ASM_NAME("NtGetContextThread") "\n\t" - "movq %rsp,%rcx\n\t" /* context */ + "jrcxz 1f\n\t" + "movq 0x98(%rcx),%rdx\n\t" /* context->Rsp */ + "jmp 2f\n\t" + "1:\tmovq 0x328(%rbx),%rax\n\t" /* amd64_thread_data()->syscall_frame */ + "leaq 0xf0(%rax),%rdx\n\t" /* &amd64_thread_data()->syscall_frame->ret_addr */ + "2:\tsubq $0x510,%rdx\n\t" /* sizeof(struct apc_stack_layout) */ + "andq $~0xf,%rdx\n\t" + "addq $8,%rsp\n\t" /* pop return address */ + "cmpq %rsp,%rdx\n\t" + "cmovbq %rdx,%rsp\n\t" + "subq $0x20,%rsp\n\t" + "call " __ASM_NAME("setup_user_apc_dispatcher_stack") "\n\t" + "movq %rax,%rsp\n\t" + "leaq 0x30(%rsp),%rcx\n\t" /* context */ "movq $0xc0,0x78(%rcx)\n\t" /* context.Rax = STATUS_USER_APC */ "movq %r12,%rdx\n\t" /* ctx */ "movq %r13,%r8\n\t" /* arg1 */ "movq %r14,%r9\n" /* arg2 */ - "2:\tmovq $0,0x328(%rbx)\n\t" + "movq $0,0x328(%rbx)\n\t" /* amd64_thread_data()->syscall_frame */ "movq %rsi,0x20(%rsp)\n\t" /* func */ "movq 0xa0(%rcx),%rbp\n\t" /* context.Rbp */ "pushq 0xf8(%rcx)\n\t" /* context.Rip */ -- 2.29.2

Dec. 16, 2020

[PATCH 2/2] conhost: Improve get_output_info debug traces.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- programs/conhost/conhost.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)

Dec. 16, 2020

[PATCH 1/2] conhost: Don't create bitmap for hidden windows.

by Jacek Caban

Fixes performance issues in ConEmu. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- programs/conhost/window.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)

Dec. 16, 2020

[PATCH v2] wintrust: Don't fail CryptCATOpen on empty file or invalid data.

by Rémi Bernon

Fixes a regression from 699e0a55ea71e2506917e38fc85cb4ae23a9cd1a, making "winetricks dotnet30sp1" fail. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49831 Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/wintrust/crypt.c | 14 ++++++++++++-- dlls/wintrust/tests/crypt.c | 12 ++++++------ 2 files changed, 18 insertions(+), 8 deletions(-) diff --git a/dlls/wintrust/crypt.c b/dlls/wintrust/crypt.c index be869ad8277..fcf419c76d1 100644 --- a/dlls/wintrust/crypt.c +++ b/dlls/wintrust/crypt.c @@ -908,6 +908,7 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, BYTE *buffer = NULL; DWORD size, open_mode = OPEN_ALWAYS; struct cryptcat *cc; + BOOL valid; TRACE("filename %s, flags %#x, provider %#lx, version %#x, type %#x\n", debugstr_w(filename), flags, hProv, dwPublicVersion, dwEncodingType); @@ -941,13 +942,15 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, HeapFree(GetProcessHeap(), 0, buffer); return INVALID_HANDLE_VALUE; } - if (!ReadFile(file, buffer, size, &size, NULL) || !CryptMsgUpdate(hmsg, buffer, size, TRUE)) + if (!size) valid = FALSE; + else if (!ReadFile(file, buffer, size, &size, NULL)) { CloseHandle(file); HeapFree(GetProcessHeap(), 0, buffer); CryptMsgClose(hmsg); return INVALID_HANDLE_VALUE; } + else valid = CryptMsgUpdate(hmsg, buffer, size, TRUE); HeapFree(GetProcessHeap(), 0, buffer); CloseHandle(file); @@ -961,7 +964,13 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, cc->msg = hmsg; cc->encoding = dwEncodingType; - if (CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_COUNT_PARAM, 0, &cc->attr_count, &size)) + if (!valid) + { + cc->magic = CRYPTCAT_MAGIC; + SetLastError(ERROR_SUCCESS); + return cc; + } + else if (CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_COUNT_PARAM, 0, &cc->attr_count, &size)) { DWORD i, sum = 0; BYTE *p; @@ -1012,6 +1021,7 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, return INVALID_HANDLE_VALUE; } cc->magic = CRYPTCAT_MAGIC; + SetLastError(ERROR_SUCCESS); return cc; } HeapFree(GetProcessHeap(), 0, cc); diff --git a/dlls/wintrust/tests/crypt.c b/dlls/wintrust/tests/crypt.c index 1b436e9f4ab..5f9c402e00f 100644 --- a/dlls/wintrust/tests/crypt.c +++ b/dlls/wintrust/tests/crypt.c @@ -429,10 +429,10 @@ static void test_CryptCATOpen(void) } else { - todo_wine ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); - todo_wine ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); + ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); + ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); ret = pCryptCATClose(cat); - todo_wine ok(ret, "flags %#x: failed to close file\n", flags); + ok(ret, "flags %#x: failed to close file\n", flags); ret = DeleteFileW(filename); ok(ret, "flags %#x: failed to delete file, error %u\n", flags, GetLastError()); } @@ -443,10 +443,10 @@ static void test_CryptCATOpen(void) SetLastError(0xdeadbeef); cat = pCryptCATOpen(filename, flags, 0, 0, 0); - todo_wine ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); - todo_wine ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); + ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); + ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); ret = pCryptCATClose(cat); - todo_wine ok(ret, "flags %#x: failed to close file\n", flags); + ok(ret, "flags %#x: failed to close file\n", flags); file = _wfopen(filename, L"r"); ret = fread(buffer, 1, sizeof(buffer), file); -- 2.29.2

Dec. 16, 2020

Re: [PATCH 1/3] wintrust: Refactor CryptCATOpen error handling.

by Rémi Bernon

On 12/16/20 9:13 PM, Alexandre Julliard wrote: > Rémi Bernon <rbernon(a)codeweavers.com> writes: > >> Make it simpler, handle all errors in the same place. > > It would be better to leave that kind of refactoring for after code > freeze. Any chance you could do more targeted fix just for that bug in > the meantime? > I was afraid it would be the case, I'll send another version, with a simple diff, but that doesn't make the code simpler. -- Rémi Bernon <rbernon(a)codeweavers.com>

Dec. 16, 2020

Re: [PATCH 1/3] wintrust: Refactor CryptCATOpen error handling.

by Alexandre Julliard

Rémi Bernon <rbernon(a)codeweavers.com> writes: > Make it simpler, handle all errors in the same place. It would be better to leave that kind of refactoring for after code freeze. Any chance you could do more targeted fix just for that bug in the meantime? -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2020

Re: [PATCH] httpapi/tests: Sleep before calling GetOverlappedResult() in test_v2_server().

by Marvin

Hi, While running your changed tests, 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=83524 Your paranoid android. === w1064 (32 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID fd00000160000005. httpapi.c:1375: Test failed: Got SSL connection ID fe00000060000004. httpapi.c:1378: Test failed: Got request info 0064E40C. === w10pro64 (32 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID ff00000260000001. httpapi.c:1375: Test failed: Got SSL connection ID fd00000060000001. httpapi.c:1378: Test failed: Got request info 0064E40C. === w1064 (64 bit report) === httpapi: httpapi.c:1375: Test failed: Got SSL connection ID fc00000160000004. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w1064_2qxl (64 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID ff00000260000001. httpapi.c:1375: Test failed: Got SSL connection ID ff00000060000011. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w10pro64 (64 bit report) === httpapi: httpapi.c:1375: Test failed: Got SSL connection ID ff0000026000000c. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w10pro64_ar (64 bit report) === httpapi: httpapi.c:1375: Test failed: Got SSL connection ID fd0000016000000d. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w10pro64_he (64 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID ff00000260000001. httpapi.c:1375: Test failed: Got SSL connection ID ff00000260000011. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w10pro64_ja (64 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID ff00000260000001. httpapi.c:1375: Test failed: Got SSL connection ID ff00000060000015. httpapi.c:1378: Test failed: Got request info 000000000064E428. === w10pro64_zh_CN (64 bit report) === httpapi: httpapi.c:307: Test failed: Got SSL connection ID ff00000260000001. httpapi.c:1375: Test failed: Got SSL connection ID fd00000160000003. httpapi.c:1378: Test failed: Got request info 000000000064E428.

Dec. 16, 2020

[PATCH] httpapi/tests: Sleep before calling GetOverlappedResult() in test_v2_server().

by Zebediah Figura

This seems to be a variation of a bug already encountered; here the kernel does not report the right value in the IOSB until after completion is signaled. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48587 Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- dlls/httpapi/tests/httpapi.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/httpapi/tests/httpapi.c b/dlls/httpapi/tests/httpapi.c index d758dee6b2c..752d008fc6b 100644 --- a/dlls/httpapi/tests/httpapi.c +++ b/dlls/httpapi/tests/httpapi.c @@ -233,9 +233,11 @@ static void test_v1_server(void) ok(ret, "Got error %u.\n", GetLastError()); ok(ret_size > sizeof(*req), "Got size %u.\n", ret_size); - /* 64-bit Windows 10 version 1507 apparently suffers from a bug where it - * will report success before completely filling the buffer. Wait for a - * short interval to work around this. */ + /* Various versions of Windows (observed on 64-bit Windows 8 and Windows 10 + * version 1507, but probably affecting others) suffer from a bug where the + * kernel will report success before completely filling the buffer or + * reporting the correct buffer size. Wait for a short interval to work + * around this. */ Sleep(100); ok(!req->Flags, "Got flags %#x.\n", req->Flags); @@ -1306,10 +1308,14 @@ static void test_v2_server(void) ret = send(s, req_text, strlen(req_text), 0); ok(ret == strlen(req_text), "send() returned %d.\n", ret); + ret = WaitForSingleObject(ovl.hEvent, 100); + ok(!ret, "Got %u.\n", ret); + + Sleep(100); + ret = GetOverlappedResult(queue, &ovl, &ret_size, TRUE); ok(ret, "Got error %u.\n", GetLastError()); ok(ret_size > sizeof(*req), "Got size %u.\n", ret_size); - Sleep(100); ok(!req->Flags, "Got flags %#x.\n", req->Flags); ok(req->ConnectionId, "Expected nonzero connection ID.\n"); -- 2.29.2

Dec. 16, 2020

Re: [RFC] Announcing Wayland driver development

by Zebediah Figura (she/her)

On 12/16/20 2:44 AM, Julian Rüger wrote: > Hi Alexandros, > > first of all, congratulations and thanks for your work, this sounds very > cool! > > Disclaimer: > > I'm little more than a curious observer of the larger developments in > Wine, but I've been around for a while and have picked up a few things. > Still, you should probably take anything someone who actually > understands the code says over my ramblings ;) > > >> My first question to the Wine community is how complete the driver >> should be before being considered for inclusion. Is the current Wayland >> driver state enough? > > The most important and probably trickiest order of business is to > convince Alexandre you're going the "Right Way" (tm), from an > architectural standpoint. > I can't really say if your current progress is enough to gauge that, but > I think it is. > >> If there is interest, I was hoping to get the >> driver in earlier rather than later, in an experimental capacity, in >> order to provide a single, official point of development for people >> wanting to contribute. > > You should talk to our tireless and competent staging developers, > Zebediah Figura and Alistair Leslie-Hughes about that. That's probably about right. I would like to be sure that a Wayland driver will be accepted upstream in some form or another before we take it—I don't want to maintain any patch set in wine-staging forever, but an entire graphics driver least of all. In particular I've seen a lot of concerns about the long list of things Wayland can't support. Window positioning is one, but not the only by far. See also [1] (not that I can personally verify the veracity of any of these; I don't work with window managers). [1] https://bugs.winehq.org/show_bug.cgi?id=42284#c17 > >> My second question is about the best way to move forward with >> upstreaming. The code is currently split between just a few commits, >> mostly as a result of the experimental nature of this effort, and also >> because I used existing code from winex11 and wineandroid as my starting >> point. I would like to split this into smaller commits to make it more >> review-friendly for the mailing list. I was thinking of splitting by >> user32 function (and internal dependencies), but since this is going to >> be an artificial split, I am open to other ideas to make reviewers' >> lives easier. > > Again, I'm no expert, but from what I've seen, a good approach would be > to start with a stubbed skeleton driver and build it up from that, piece > by piece, in small logical steps. > > The rules for commits are basically: > * leave wine in a consistent and working state after every commit! > * don't introduce dead code > * have meaningful commit messages > > (* normally tests are very important, though I'm not sure how much that > applies in this case or how to go about failing tests under your driver) > > Read the wiki for more info, notably > https://wiki.winehq.org/Submitting_Patches > and most of https://wiki.winehq.org/Wine_Developer%27s_Guide > though some stuff may be out of date. > > FWIW, I recommend looking at the commit history, how past big changes > were introduced i.e. the Mac driver, maybe the DIB-Engine (although that > was quite long ago and a lot has changed since) > > Better wait for advice from actual developers here ;) I think you've described our development guidelines pretty well ;-) It's probably worth pointing out that "leave wine in a working state" is a bit less important when it comes to things like introducing a new driver, at least with respect to that driver itself. You definitely shouldn't break anything when Wayland isn't used, and ideally something working in Wayland from an earlier patch shouldn't be broken by a later one (e.g. the style of development that produces lots of "fixup earlier patch" patches is frowned upon), but of course it's expected that the driver won't be working on Wayland in every patch. > >> Looking forward to your feedback and questions! > > I hope that helps a bit, and that when the experts ship in they don't > have to repeat the basics. > > This is about all I know, sorry I can't really be more specific. Please > correct anything I got wrong! > > > Best, > Julian > >

Dec. 16, 2020

Re: [PATCH 2/2] widl: open files to write in binary mode

by Jacek Caban

On 16.12.2020 15:35, Steve Lhomme wrote: > On 2020-12-16 15:18, Jacek Caban wrote: >> Hi Steve, >> >> On 16.12.2020 10:14, Steve Lhomme wrote: >>> When compiled with mingw64 the output files have Windows line >>> endings instead >>> of UNIX ones. >>> --- >>> tools/widl/header.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/tools/widl/header.c b/tools/widl/header.c >>> index 43be8d74cbe..5457185538e 100644 >>> --- a/tools/widl/header.c >>> +++ b/tools/widl/header.c >>> @@ -1893,7 +1893,7 @@ void write_header(const statement_list_t *stmts) >>> if (!do_header) return; >>> - if(!(header = fopen(header_name, "w"))) { >>> + if(!(header = fopen(header_name, "wb"))) { >> >> >> There are more places that would need to be fixed for consistency. >> Maybe we could use _set_fmode(_O_BINARY) in main() instead? > > Is this a MS-only thing ? I don't mind having this patch only in > mingw-w64-tools (which also have some extra patch as well). Yes, it would need an #ifdef. > In general it may not be the proper way to handle this. For writing > all files widl generates, it should be fine. But for reading files the > "binary" mode is not currently used and it may break reading files > that used to be read properly on Windows ? Which files do you mean? The only non-binary files that widl generates are headers and C files. Generally speaking, widl output is cross platform, so it should generate the same output on regardless of host platform used. Windows line ending breaks that. Jacek

Dec. 16, 2020

[PATCH v2 1/2] widl: don't use local methods when writing async interfaces

by Steve Lhomme

The same entries can have a different call_as between the synchronous and asynchronous interfaces and shouldn't be mixed up. --- tools/widl/header.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/widl/header.c b/tools/widl/header.c index 223ab5c5ca9..e6de236a25f 100644 --- a/tools/widl/header.c +++ b/tools/widl/header.c @@ -1614,7 +1614,8 @@ static void write_com_interface_end(FILE *header, type_t *iface) if (!dispinterface && !winrt_mode) { write_method_proto(header, iface); - write_locals(header, iface, FALSE); + if (type_iface_get_async_iface(iface) != iface) + write_locals(header, iface, FALSE); fprintf(header, "\n"); } fprintf(header, "#endif /* __%s_%sINTERFACE_DEFINED__ */\n", iface->c_name, dispinterface ? "DISP" : ""); -- 2.29.2

Dec. 16, 2020

Re: [PATCH 2/2] widl: open files to write in binary mode

by Steve Lhomme

On 2020-12-16 15:18, Jacek Caban wrote: > Hi Steve, > > On 16.12.2020 10:14, Steve Lhomme wrote: >> When compiled with mingw64 the output files have Windows line endings >> instead >> of UNIX ones. >> --- >> tools/widl/header.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/widl/header.c b/tools/widl/header.c >> index 43be8d74cbe..5457185538e 100644 >> --- a/tools/widl/header.c >> +++ b/tools/widl/header.c >> @@ -1893,7 +1893,7 @@ void write_header(const statement_list_t *stmts) >> if (!do_header) return; >> - if(!(header = fopen(header_name, "w"))) { >> + if(!(header = fopen(header_name, "wb"))) { > > > There are more places that would need to be fixed for consistency. Maybe > we could use _set_fmode(_O_BINARY) in main() instead? Is this a MS-only thing ? I don't mind having this patch only in mingw-w64-tools (which also have some extra patch as well). In general it may not be the proper way to handle this. For writing all files widl generates, it should be fine. But for reading files the "binary" mode is not currently used and it may break reading files that used to be read properly on Windows ?

Dec. 16, 2020

Re: [PATCH 2/2] widl: open files to write in binary mode

by Jacek Caban

Hi Steve, On 16.12.2020 10:14, Steve Lhomme wrote: > When compiled with mingw64 the output files have Windows line endings instead > of UNIX ones. > --- > tools/widl/header.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/widl/header.c b/tools/widl/header.c > index 43be8d74cbe..5457185538e 100644 > --- a/tools/widl/header.c > +++ b/tools/widl/header.c > @@ -1893,7 +1893,7 @@ void write_header(const statement_list_t *stmts) > > if (!do_header) return; > > - if(!(header = fopen(header_name, "w"))) { > + if(!(header = fopen(header_name, "wb"))) { There are more places that would need to be fixed for consistency. Maybe we could use _set_fmode(_O_BINARY) in main() instead? Thanks, Jacek

Dec. 16, 2020

Re: [PATCH 1/2] widl: don't use local methods when writing async interfaces

by Jacek Caban

Hi Steve, On 16.12.2020 10:14, Steve Lhomme wrote: > -static void write_com_interface_end(FILE *header, type_t *iface) > +static void write_com_interface_end(FILE *header, type_t *iface, int as_async) > { > int dispinterface = is_attr(iface->attrs, ATTR_DISPINTERFACE); > const UUID *uuid = get_attrp(iface->attrs, ATTR_UUID); > @@ -1614,7 +1614,8 @@ static void write_com_interface_end(FILE *header, type_t *iface) > if (!dispinterface && !winrt_mode) > { > write_method_proto(header, iface); > - write_locals(header, iface, FALSE); > + if (!as_async) > + write_locals(header, iface, FALSE); You could use something like if (type_iface_get_async_iface(iface) == iface) to avoid extra as_async argument. Thanks, Jacek

Dec. 16, 2020

Re: [RFC] Announcing Wayland driver development

by Alexandros Frantzis

On Wed, Dec 16, 2020 at 06:35:48AM +0200, Damjan Jovanovic wrote: > On Tue, Dec 15, 2020 at 7:16 PM Alexandros Frantzis < > alexandros.frantzis(a)collabora.com> wrote: > > > > > What needs more work (or is completely missing): > > > > * Minimize > > * Better z-order and activation handling > > * Keyboard layout support > > * Grabs > > * GTK menu mouse handling bug (cannot click to select items) > > * Multiple displays > > * Vulkan. Note that that there is another effort at > > https://github.com/varmd/wine-wayland/ focusing solely on vulkan. > > My hope is that we will be able to share efforts going forward. > > > Hi! > What about: > Clipboard > Drag and drop > Games that change screen resolution / color depth These are all in my TODO list (I forgot to mention them in the original list!). Note that Wayland doesn't allow clients to change the monitor display mode per se, but we can still get the desired effect by providing to the game its desired "fullscreen" size window, and instructing the Wayland compositor to scale the window to match the size of the real current monitor mode. > Cross-process window embedding / system tray I haven't looked into this yet. I'll need to investigate what the requirements are from the Windows/Wine side, and whether relevant Wayland extensions ("foreign surfaces") can accommodate those requirements. > X11-based XDG standards, eg. startup notifications I haven't considered support for the XDG standards yet, and we will have to examine each standard we care about separately, to see what Wayland supports or could reasonably support. For startup notifications in particular, Wayland doesn't currently provide a standard extension, but it has been discussed. For now, GTK/gnome provides relevant functionality through their own gtk-shell1 extension. One way forward, and until more standard support is provided, is to use this extension (if present) to at least get startup notifications on gnome-shell. Thanks, Alexandros

Dec. 16, 2020

[PATCH 3/3] wintrust: Don't fail CryptCATOpen if file is empty or its data invalid.

by Rémi Bernon

Fixes a regression from 699e0a55ea71e2506917e38fc85cb4ae23a9cd1a, making "winetricks dotnet30sp1" fail. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49831 Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- Note that sometimes (often?) "winetricks dotnet30sp1" still fails early because NetFx20SP1_x86.exe fails to install. It's unrelated, and happens spuriously. dlls/wintrust/crypt.c | 5 ++++- dlls/wintrust/tests/crypt.c | 12 ++++++------ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/dlls/wintrust/crypt.c b/dlls/wintrust/crypt.c index e9a58a84ac4..2a780e57546 100644 --- a/dlls/wintrust/crypt.c +++ b/dlls/wintrust/crypt.c @@ -935,7 +935,7 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, size = GetFileSize(file, NULL); if (!(buffer = HeapAlloc(GetProcessHeap(), 0, size))) goto failed_alloc; - if (!ReadFile(file, buffer, size, &size, NULL) || !CryptMsgUpdate(hmsg, buffer, size, TRUE)) goto failed; + if (!ReadFile(file, buffer, size, &size, NULL) || !CryptMsgUpdate(hmsg, buffer, size, TRUE)) goto done; size = sizeof(DWORD); if (!CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_COUNT_PARAM, 0, &cc->attr_count, &size)) goto failed; @@ -955,9 +955,12 @@ HANDLE WINAPI CryptCATOpen(WCHAR *filename, DWORD flags, HCRYPTPROV hProv, } cc->inner = decode_inner_content(hmsg, dwEncodingType, &cc->inner_len); if (!cc->inner || !CryptSIPRetrieveSubjectGuid(filename, NULL, &cc->subject)) goto failed; + +done: cc->magic = CRYPTCAT_MAGIC; HeapFree(GetProcessHeap(), 0, buffer); CloseHandle(file); + SetLastError(ERROR_SUCCESS); return cc; failed_alloc: diff --git a/dlls/wintrust/tests/crypt.c b/dlls/wintrust/tests/crypt.c index 1b436e9f4ab..5f9c402e00f 100644 --- a/dlls/wintrust/tests/crypt.c +++ b/dlls/wintrust/tests/crypt.c @@ -429,10 +429,10 @@ static void test_CryptCATOpen(void) } else { - todo_wine ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); - todo_wine ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); + ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); + ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); ret = pCryptCATClose(cat); - todo_wine ok(ret, "flags %#x: failed to close file\n", flags); + ok(ret, "flags %#x: failed to close file\n", flags); ret = DeleteFileW(filename); ok(ret, "flags %#x: failed to delete file, error %u\n", flags, GetLastError()); } @@ -443,10 +443,10 @@ static void test_CryptCATOpen(void) SetLastError(0xdeadbeef); cat = pCryptCATOpen(filename, flags, 0, 0, 0); - todo_wine ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); - todo_wine ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); + ok(cat != INVALID_HANDLE_VALUE, "flags %#x: expected success\n", flags); + ok(!GetLastError(), "flags %#x: got error %u\n", flags, GetLastError()); ret = pCryptCATClose(cat); - todo_wine ok(ret, "flags %#x: failed to close file\n", flags); + ok(ret, "flags %#x: failed to close file\n", flags); file = _wfopen(filename, L"r"); ret = fread(buffer, 1, sizeof(buffer), file); -- 2.29.2

Dec. 16, 2020