September 2017 - Wine-Devel

Re: [PATCH 01/10] atl80: Fix processorArchitecture in manifest

by Alexandre Julliard

Fabian Maurer <dark.shadow4(a)web.de> writes: > processorArchitecture should not be empty string I don't think that's correct for assemblies that can be imported. Note that the processorArchitecture is fixed up when creating the fake dll, so it doesn't end up empty in the resources. -- Alexandre Julliard julliard(a)winehq.org

Sept. 6, 2017

Re: [PATCH] secur32: Split push/pull schannel transports

by Anton Romanov

On Sat, Aug 5, 2017 at 11:27 AM, Anton Romanov <theli.ua(a)gmail.com> wrote: > This makes schan_EncryptMessage/schan_DecryptMessage thread safe between > each other. > MSDN states that it's supposed to be thread safe. > Fixes Magic The Gathering: Online crash: > https://bugs.winehq.org/show_bug.cgi?id=43453 > > Signed-off-by: Anton Romanov <theli.ua(a)gmail.com> > --- > dlls/secur32/schannel.c | 33 +++++++++++++++++++-------------- > dlls/secur32/schannel_gnutls.c | 12 +++++++----- > dlls/secur32/schannel_macosx.c | 21 ++++++++++++--------- > dlls/secur32/secur32_priv.h | 5 +++-- > 4 files changed, 41 insertions(+), 30 deletions(-) > > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index 82374efd55..1f938e1a37 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -59,6 +59,8 @@ struct schan_context > schan_imp_session session; > ULONG req_ctx_attr; > const CERT_CONTEXT *cert; > + struct schan_transport *push_transport; > + struct schan_transport *pull_transport; > }; > > static struct schan_handle *schan_handle_table; > @@ -895,7 +897,7 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( > init_schan_buffers(&transport.in, pInput, schan_init_sec_ctx_get_next_input_buffer); > transport.in.limit = expected_size; > init_schan_buffers(&transport.out, pOutput, schan_init_sec_ctx_get_next_output_buffer); > - schan_imp_set_session_transport(ctx->session, &transport); > + schan_imp_set_session_transports(ctx->session, &transport, &transport); > > /* Perform the TLS handshake */ > ret = schan_imp_handshake(ctx->session); > @@ -927,6 +929,13 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextW( > if (ctx->req_ctx_attr & ISC_REQ_STREAM) > *pfContextAttr |= ISC_RET_STREAM; > > + ctx->push_transport = HeapAlloc(GetProcessHeap(), 0, sizeof(struct schan_transport)); > + ctx->push_transport->ctx = ctx; > + ctx->pull_transport = HeapAlloc(GetProcessHeap(), 0, sizeof(struct schan_transport)); > + ctx->pull_transport->ctx = ctx; > + schan_imp_set_session_transports(ctx->session, ctx->push_transport, > + ctx->pull_transport); > + > return ret; > } > > @@ -1205,7 +1214,6 @@ static int schan_encrypt_message_get_next_buffer_token(const struct schan_transp > static SECURITY_STATUS SEC_ENTRY schan_EncryptMessage(PCtxtHandle context_handle, > ULONG quality, PSecBufferDesc message, ULONG message_seq_no) > { > - struct schan_transport transport; > struct schan_context *ctx; > struct schan_buffers *b; > SECURITY_STATUS status; > @@ -1235,13 +1243,11 @@ static SECURITY_STATUS SEC_ENTRY schan_EncryptMessage(PCtxtHandle context_handle > data = HeapAlloc(GetProcessHeap(), 0, data_size); > memcpy(data, buffer->pvBuffer, data_size); > > - transport.ctx = ctx; > - init_schan_buffers(&transport.in, NULL, NULL); > + init_schan_buffers(&ctx->push_transport->in, NULL, NULL); > if (schan_find_sec_buffer_idx(message, 0, SECBUFFER_STREAM_HEADER) != -1) > - init_schan_buffers(&transport.out, message, schan_encrypt_message_get_next_buffer); > + init_schan_buffers(&ctx->push_transport->out, message, schan_encrypt_message_get_next_buffer); > else > - init_schan_buffers(&transport.out, message, schan_encrypt_message_get_next_buffer_token); > - schan_imp_set_session_transport(ctx->session, &transport); > + init_schan_buffers(&ctx->push_transport->out, message, schan_encrypt_message_get_next_buffer_token); > > length = data_size; > status = schan_imp_send(ctx->session, data, &length); > @@ -1251,7 +1257,7 @@ static SECURITY_STATUS SEC_ENTRY schan_EncryptMessage(PCtxtHandle context_handle > if (length != data_size) > status = SEC_E_INTERNAL_ERROR; > > - b = &transport.out; > + b = &ctx->push_transport->out; > b->desc->pBuffers[b->current_buffer_idx].cbBuffer = b->offset; > HeapFree(GetProcessHeap(), 0, data); > > @@ -1327,7 +1333,6 @@ static void schan_decrypt_fill_buffer(PSecBufferDesc message, ULONG buffer_type, > static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle, > PSecBufferDesc message, ULONG message_seq_no, PULONG quality) > { > - struct schan_transport transport; > struct schan_context *ctx; > SecBuffer *buffer; > SIZE_T data_size; > @@ -1371,11 +1376,9 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > data_size = expected_size - 5; > data = HeapAlloc(GetProcessHeap(), 0, data_size); > > - transport.ctx = ctx; > - init_schan_buffers(&transport.in, message, schan_decrypt_message_get_next_buffer); > - transport.in.limit = expected_size; > - init_schan_buffers(&transport.out, NULL, NULL); > - schan_imp_set_session_transport(ctx->session, &transport); > + init_schan_buffers(&ctx->pull_transport->in, message, schan_decrypt_message_get_next_buffer); > + ctx->pull_transport->in.limit = expected_size; > + init_schan_buffers(&ctx->pull_transport->out, NULL, NULL); > > while (received < data_size) > { > @@ -1573,6 +1576,8 @@ void SECUR32_deinitSchannelSP(void) > { > struct schan_context *ctx = schan_free_handle(i, SCHAN_HANDLE_CTX); > schan_imp_dispose_session(ctx->session); > + HeapFree(GetProcessHeap(), 0, ctx->push_transport); > + HeapFree(GetProcessHeap(), 0, ctx->pull_transport); > HeapFree(GetProcessHeap(), 0, ctx); > } > } > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index bc3bbaf67d..97b2c2d767 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -73,7 +73,7 @@ MAKE_FUNCPTR(gnutls_record_send); > MAKE_FUNCPTR(gnutls_server_name_set); > MAKE_FUNCPTR(gnutls_transport_get_ptr); > MAKE_FUNCPTR(gnutls_transport_set_errno); > -MAKE_FUNCPTR(gnutls_transport_set_ptr); > +MAKE_FUNCPTR(gnutls_transport_set_ptr2); > MAKE_FUNCPTR(gnutls_transport_set_pull_function); > MAKE_FUNCPTR(gnutls_transport_set_push_function); > #undef MAKE_FUNCPTR > @@ -214,11 +214,13 @@ void schan_imp_dispose_session(schan_imp_session session) > pgnutls_deinit(s); > } > > -void schan_imp_set_session_transport(schan_imp_session session, > - struct schan_transport *t) > +void schan_imp_set_session_transports(schan_imp_session session, > + struct schan_transport *t_push, > + struct schan_transport *t_pull) > { > gnutls_session_t s = (gnutls_session_t)session; > - pgnutls_transport_set_ptr(s, (gnutls_transport_ptr_t)t); > + pgnutls_transport_set_ptr2(s, (gnutls_transport_ptr_t)t_pull, > + (gnutls_transport_ptr_t)t_push); > } > > void schan_imp_set_session_target(schan_imp_session session, const char *target) > @@ -568,7 +570,7 @@ BOOL schan_imp_init(void) > LOAD_FUNCPTR(gnutls_server_name_set) > LOAD_FUNCPTR(gnutls_transport_get_ptr) > LOAD_FUNCPTR(gnutls_transport_set_errno) > - LOAD_FUNCPTR(gnutls_transport_set_ptr) > + LOAD_FUNCPTR(gnutls_transport_set_ptr2) > LOAD_FUNCPTR(gnutls_transport_set_pull_function) > LOAD_FUNCPTR(gnutls_transport_set_push_function) > #undef LOAD_FUNCPTR > diff --git a/dlls/secur32/schannel_macosx.c b/dlls/secur32/schannel_macosx.c > index 7f38133b4b..4cd562411b 100644 > --- a/dlls/secur32/schannel_macosx.c > +++ b/dlls/secur32/schannel_macosx.c > @@ -184,7 +184,8 @@ enum { > > struct mac_session { > SSLContextRef context; > - struct schan_transport *transport; > + struct schan_transport *push_transport; > + struct schan_transport *pull_transport; > }; > > > @@ -631,9 +632,9 @@ static OSStatus schan_pull_adapter(SSLConnectionRef transport, void *buff, > int status; > OSStatus ret; > > - TRACE("(%p/%p, %p, %p/%lu)\n", s, s->transport, buff, buff_len, *buff_len); > + TRACE("(%p/%p, %p, %p/%lu)\n", s, s->pull_transport, buff, buff_len, *buff_len); > > - status = schan_pull(s->transport, buff, buff_len); > + status = schan_pull(s->pull_transport, buff, buff_len); > if (status == 0) > { > if (*buff_len == 0) > @@ -690,9 +691,9 @@ static OSStatus schan_push_adapter(SSLConnectionRef transport, const void *buff, > int status; > OSStatus ret; > > - TRACE("(%p/%p, %p, %p/%lu)\n", s, s->transport, buff, buff_len, *buff_len); > + TRACE("(%p/%p, %p, %p/%lu)\n", s, s->push_transport, buff, buff_len, *buff_len); > > - status = schan_push(s->transport, buff, buff_len); > + status = schan_push(s->push_transport, buff, buff_len); > if (status == 0) > { > TRACE("Pushed %lu bytes\n", *buff_len); > @@ -806,14 +807,16 @@ void schan_imp_dispose_session(schan_imp_session session) > HeapFree(GetProcessHeap(), 0, s); > } > > -void schan_imp_set_session_transport(schan_imp_session session, > - struct schan_transport *t) > +void schan_imp_set_session_transports(schan_imp_session session, > + struct schan_transport *t_push, > + struct schan_transport *t_pull) > { > struct mac_session *s = (struct mac_session*)session; > > - TRACE("(%p/%p, %p)\n", s, s->context, t); > + TRACE("(%p/%p, %p, %p)\n", s, s->context, t_push, t_pull); > > - s->transport = t; > + s->push_transport = t_push; > + s->pull_transport = t_pull; > } > > void schan_imp_set_session_target(schan_imp_session session, const char *target) > diff --git a/dlls/secur32/secur32_priv.h b/dlls/secur32/secur32_priv.h > index 9a60d65788..0bc8a57c1a 100644 > --- a/dlls/secur32/secur32_priv.h > +++ b/dlls/secur32/secur32_priv.h > @@ -246,8 +246,9 @@ extern schan_imp_session schan_session_for_transport(struct schan_transport* t) > /* schannel implementation interface */ > extern BOOL schan_imp_create_session(schan_imp_session *session, schan_credentials *cred) DECLSPEC_HIDDEN; > extern void schan_imp_dispose_session(schan_imp_session session) DECLSPEC_HIDDEN; > -extern void schan_imp_set_session_transport(schan_imp_session session, > - struct schan_transport *t) DECLSPEC_HIDDEN; > +extern void schan_imp_set_session_transports(schan_imp_session session, > + struct schan_transport *t_push, > + struct schan_transport *t_pull) DECLSPEC_HIDDEN; > extern void schan_imp_set_session_target(schan_imp_session session, const char *target) DECLSPEC_HIDDEN; > extern SECURITY_STATUS schan_imp_handshake(schan_imp_session session) DECLSPEC_HIDDEN; > extern unsigned int schan_imp_get_session_cipher_block_size(schan_imp_session session) DECLSPEC_HIDDEN; > -- > 2.11.0 > So, it's been a month now. Is there something I could do to have this accepted? Thanks.

Sept. 6, 2017

Re: [v5 PATCH] wmvcore/tests: add tests for WMReader methods

by Alexandre Julliard

Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes: > Without a large binary file, how would we test the successful > processing of an audio or video file? We could use an IWMWriter to > create it, but then we wouldn't be testing for conformance against the > Windows API. In general, to test something like a file loader, you'd want to test multiple files with various contents, including invalid values for header fields and the like. This is better done by generating them instead of including pre-built binaries. Like you said, using IWMWriter wouldn't guarantee that we are testing the right thing, so we'd most likely want to generate them by hand somehow. Again, this would be better done along with the implementation, so we can get a better idea of what cases would be interesting to test. -- Alexandre Julliard julliard(a)winehq.org

Sept. 5, 2017

Re: [PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.

by Lorenzo Ferrillo

In data martedì 5 settembre 2017 19:30:37 CEST, hai scritto: > On 5 September 2017 at 18:31, Lorenzo Ferrillo <lorenzofersteam(a)live.it> wrote: > > Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ? > > > > I admit that I know nothing about directx or wined3d (and the code is not > > > > much documented. ). Also considering that this specific control wasn't > > the > > only thing that was removed in that commit. > > I'd certianly like to learn a better way to deal with these issues. My > > studying of the wine source code started recently. > > Thanks. > > Special formats like "RESZ", "NVDB" and "INST" can't be used to create > resources, but are instead used to indicate that drivers support > specific vendor extensions. In wined3d, these formats have > WINED3DFMT_FLAG_TEXTURE set, but don't have an internal format, since > they can't be used to create textures. The reason they have > WINED3DFMT_FLAG_TEXTURE set is mostly historic. > > There also exist formats like e.g. YUV and P8 formats that can't be > used for texturing, but can be used for e.g. blits. Those have an > internal format, but don't have WINED3DFMT_FLAG_TEXTURE. The intention > of commit 8c98be4791f18f31b04a4a0f08d18979aa0d06df was to report those > formats as supported for surfaces, without calling into the blitter, > since that wouldn't work with subsequent commits, and was a little > questionable to begin with. Unfortunately that commit failed to take > the "extension" formats into account. Instead of restoring the > WINED3DFMT_FLAG_TEXTURE check, I think it would make more sense to > introduce a dedicated flag for those extension formats, and check that > instead. So it made sense to replace that code with the current one. Before there wasn't a check for format->gl_internal or similar. However with this patch it should restore the possibility of returning TRUE for formats without an internal format (such as NULL,REZ,NDBV) but have the WINED3DFMT_FLAG_TEXTURE AND for the formats that doesn't have this flag but have an internal format (as YUV and P8 formats). Also this doesn't call the blitter at all, unless the blitter is wrongly called in a different part of the code. However thanks for explanations. Now this part of code is less obscure to me.

Sept. 5, 2017

Re: [PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.

by Henri Verbeet

On 5 September 2017 at 18:31, Lorenzo Ferrillo <lorenzofersteam(a)live.it> wrote: > Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ? > I admit that I know nothing about directx or wined3d (and the code is not > much documented. ). Also considering that this specific control wasn't the > only thing that was removed in that commit. > I'd certianly like to learn a better way to deal with these issues. My > studying of the wine source code started recently. > Thanks. > Special formats like "RESZ", "NVDB" and "INST" can't be used to create resources, but are instead used to indicate that drivers support specific vendor extensions. In wined3d, these formats have WINED3DFMT_FLAG_TEXTURE set, but don't have an internal format, since they can't be used to create textures. The reason they have WINED3DFMT_FLAG_TEXTURE set is mostly historic. There also exist formats like e.g. YUV and P8 formats that can't be used for texturing, but can be used for e.g. blits. Those have an internal format, but don't have WINED3DFMT_FLAG_TEXTURE. The intention of commit 8c98be4791f18f31b04a4a0f08d18979aa0d06df was to report those formats as supported for surfaces, without calling into the blitter, since that wouldn't work with subsequent commits, and was a little questionable to begin with. Unfortunately that commit failed to take the "extension" formats into account. Instead of restoring the WINED3DFMT_FLAG_TEXTURE check, I think it would make more sense to introduce a dedicated flag for those extension formats, and check that instead.

Sept. 5, 2017

Re: [PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.

by Lorenzo Ferrillo

In data martedì 5 settembre 2017 17:55:54 CEST, hai scritto: > On 4 September 2017 at 18:26, lorenzo Skotos <lorenzofersteam(a)live.it> wrote: > > - if (format->glInternal) > > + if (format->glInternal || format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & > > WINED3DFMT_FLAG_TEXTURE) > That should fix the regression, but since the ambiguity of > WINED3DFMT_FLAG_TEXTURE led to the issue in the first place, I'd > rather not simply restore the check. Instead, I think it would be > better to explicitly mark these special "extension" formats as such. > In theory Matteo has a patch for that. Which issue was caused by relying on WINED3DFMT_FLAG_TEXTURE ? I admit that I know nothing about directx or wined3d (and the code is not much documented. ). Also considering that this specific control wasn't the only thing that was removed in that commit. I'd certianly like to learn a better way to deal with these issues. My studying of the wine source code started recently. Thanks. P.S Sorry I wrongly sent the response on your email instead of the mailing list

Sept. 5, 2017

Re: [PATCH] wined3d: wined3d_check_surface_capability return TRUE for surfaces with WINED3DFMT_FLAG_TEXTURE.

by Henri Verbeet

On 4 September 2017 at 18:26, lorenzo Skotos <lorenzofersteam(a)live.it> wrote: > - if (format->glInternal) > + if (format->glInternal || format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE) That should fix the regression, but since the ambiguity of WINED3DFMT_FLAG_TEXTURE led to the issue in the first place, I'd rather not simply restore the check. Instead, I think it would be better to explicitly mark these special "extension" formats as such. In theory Matteo has a patch for that.

Sept. 5, 2017

Re: [PATCH] ntdll: Make RtlDeregisterWaitEx(handle, INVALID_HANDLE_VALUE) thread safe.

by Stefan Dösinger

Hi, Is the test I was referring to in the description of the previous patch. It causes seemingly unrelated test failures like https://testbot.winehq.org/JobDetails.pl?Key=32956 (previous iteration of the test that used a different implementation) Stefan Am 2017-09-05 um 17:34 schrieb Stefan Dösinger: > Chromium signals the wait semaphore and calls DeregisterWaitEx with > CompletionHandle = INVALID_HANDLE_VALUE in close succession. Sometimes > the worker thread decides to run the callback, but before it sets > CallbackInProgress RtlDeregisterWaitEx decides that the callback is not > running and returns STATUS_SUCCESS. Chromium then releases resources > that the callback needs to run, resulting in random crashes. > > Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> > > --- > > The tests show that we're only supposed to return STATUS_PENDING if the > callback is running. Note that the choice between waiting and returning > STATUS_SUCCESS and not waiting and returning STATUS_PENDING is still > racy, but we'll no longer return STATUS_SUCCESS and run the callback > afterwards. > > I tried to extend the tests to show what happens when both events are > available simultanously. The answer is that it is fairly random. > INVALID_HANDLE_VALUE blocks and runs the callback one last time, the > other ways of calling RtlDeregisterWait[Ex] randomly return STATUS_SUCCESS > and do not run the callback, or they return STATUS_PENDING and may or > may not run the callback. However, in no circumstance does the callback > run after STATUS_SUCCESS is returned. > > I am not including the tests because of the random outcome and because > it plays with SuspendThread and makes the random failures in follow up > tests worse. I'll send it to wine-devel for reference. > --- > dlls/ntdll/threadpool.c | 59 +++++++++++++++++++++++++++---------------------- > 1 file changed, 32 insertions(+), 27 deletions(-) > > diff --git a/dlls/ntdll/threadpool.c b/dlls/ntdll/threadpool.c > index 6063d51d9f..1b0546a781 100644 > --- a/dlls/ntdll/threadpool.c > +++ b/dlls/ntdll/threadpool.c > @@ -541,11 +541,13 @@ static DWORD CALLBACK wait_thread_proc(LPVOID Arg) > break; > } > > - completion_event = wait_work_item->CompletionEvent; > - if (completion_event) NtSetEvent( completion_event, NULL ); > > if (interlocked_inc( &wait_work_item->DeleteCount ) == 2 ) > + { > + completion_event = wait_work_item->CompletionEvent; > delete_wait_work_item( wait_work_item ); > + if (completion_event) NtSetEvent( completion_event, NULL ); > + } > > return 0; > } > @@ -633,44 +635,47 @@ NTSTATUS WINAPI RtlRegisterWait(PHANDLE NewWaitObject, HANDLE Object, > NTSTATUS WINAPI RtlDeregisterWaitEx(HANDLE WaitHandle, HANDLE CompletionEvent) > { > struct wait_work_item *wait_work_item = WaitHandle; > - NTSTATUS status = STATUS_SUCCESS; > + NTSTATUS status; > + HANDLE LocalEvent = NULL; > + BOOLEAN CallbackInProgress; > > - TRACE( "(%p)\n", WaitHandle ); > + TRACE( "(%p %p)\n", WaitHandle, CompletionEvent ); > > if (WaitHandle == NULL) > return STATUS_INVALID_HANDLE; > > - NtSetEvent( wait_work_item->CancelEvent, NULL ); > - if (wait_work_item->CallbackInProgress) > + CallbackInProgress = wait_work_item->CallbackInProgress; > + if (CompletionEvent == INVALID_HANDLE_VALUE || !CallbackInProgress) > { > - if (CompletionEvent != NULL) > - { > - if (CompletionEvent == INVALID_HANDLE_VALUE) > - { > - status = NtCreateEvent( &CompletionEvent, EVENT_ALL_ACCESS, NULL, NotificationEvent, FALSE ); > - if (status != STATUS_SUCCESS) > - return status; > - interlocked_xchg_ptr( &wait_work_item->CompletionEvent, CompletionEvent ); > - if (wait_work_item->CallbackInProgress) > - NtWaitForSingleObject( CompletionEvent, FALSE, NULL ); > - NtClose( CompletionEvent ); > - } > - else > - { > - interlocked_xchg_ptr( &wait_work_item->CompletionEvent, CompletionEvent ); > - if (wait_work_item->CallbackInProgress) > - status = STATUS_PENDING; > - } > - } > - else > - status = STATUS_PENDING; > + status = NtCreateEvent( &LocalEvent, EVENT_ALL_ACCESS, NULL, NotificationEvent, FALSE ); > + if (status != STATUS_SUCCESS) > + return status; > + interlocked_xchg_ptr( &wait_work_item->CompletionEvent, LocalEvent ); > + } > + else if (CompletionEvent != NULL) > + { > + interlocked_xchg_ptr( &wait_work_item->CompletionEvent, CompletionEvent ); > } > > + NtSetEvent( wait_work_item->CancelEvent, NULL ); > + > if (interlocked_inc( &wait_work_item->DeleteCount ) == 2 ) > { > status = STATUS_SUCCESS; > delete_wait_work_item( wait_work_item ); > } > + else if (LocalEvent) > + { > + NtWaitForSingleObject( LocalEvent, FALSE, NULL ); > + status = STATUS_SUCCESS; > + } > + else > + { > + status = STATUS_PENDING; > + } > + > + if (LocalEvent) > + NtClose( LocalEvent ); > > return status; > } >

Sept. 5, 2017

Re: [PATCH] wbemprox: Fix CreateInstanceEnum/Async entries.

by Hans Leidekker

On Tue, 2017-09-05 at 15:19 +0300, Andrey Gusev wrote: > @@ -599,7 +599,7 @@ static HRESULT WINAPI wbem_services_CreateInstanceEnum( > > static HRESULT WINAPI wbem_services_CreateInstanceEnumAsync( > IWbemServices *iface, > - const BSTR strFilter, > + const BSTR strClass, > LONG lFlags, > IWbemContext *pCtx, > IWbemObjectSink *pResponseHandler ) I think the original name is fine.

Sept. 5, 2017

Re: [2/2] ntdll: Implement RtlUnwind for ARM64

by Stefan Dösinger

Am 2017-09-04 um 20:46 schrieb André Hentschel: > + frame = NtCurrentTeb()->Tib.ExceptionList; > + while ((frame != (EXCEPTION_REGISTRATION_RECORD*)~0UL) && (frame != endframe)) Unless I am blind this handles only x86-style stack handlers, and not the function tables similar to amd64 that are likely to be present as well on arm64. Though I guess because of the lack of arm64 compilers, documentation and binaries from Microsoft we don't really know how Windows (will) handle arm64 exceptions.

Sept. 5, 2017