Module: wine
Branch: master
Commit: d289dfc2c0e978a99229cae8b76b35bcdb176e3d
URL: https://gitlab.winehq.org/wine/wine/-/commit/d289dfc2c0e978a99229cae8b76b35…
Author: Dmitry Timoshkov <dmitry(a)baikal.ru>
Date: Thu Jul 28 16:27:59 2022 +0300
server: Write terminating '\0' in the strings.
I have an application that creates its special registry key using
NtCreateKey(parent, "Something\0"), and then expects to be able to
open this key with NtOpenKey("Something\0") on start up. Currently
this fails because terminating '\0' in the key name doesn't survive
saving/loading the registry. parse_strW() helper already supports
loading such key names.
As the tests show after creating a kernel object with the name "Something\0"
it's possible to only open it as "Something\0", and an attempt opening it
as "Something" fails with STATUS_OBJECT_NAME_NOT_FOUND, and vice versa.
Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru>
---
server/registry.c | 2 +-
server/unicode.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/server/registry.c b/server/registry.c
index 3fea7dd79a4..629d67c832f 100644
--- a/server/registry.c
+++ b/server/registry.c
@@ -256,7 +256,7 @@ static void dump_value( const struct key_value *value, FILE *f )
if (((WCHAR *)value->data)[value->len / sizeof(WCHAR) - 1]) break;
if (value->type != REG_SZ) fprintf( f, "str(%x):", value->type );
fputc( '\"', f );
- dump_strW( (WCHAR *)value->data, value->len, f, "\"\"" );
+ dump_strW( (WCHAR *)value->data, value->len - sizeof(WCHAR), f, "\"\"" );
fprintf( f, "\"\n" );
return;
diff --git a/server/unicode.c b/server/unicode.c
index edb296be0c8..f84520580d7 100644
--- a/server/unicode.c
+++ b/server/unicode.c
@@ -219,7 +219,6 @@ int dump_strW( const WCHAR *str, data_size_t len, FILE *f, const char escape[2]
}
if (*str < 32) /* octal or C escape */
{
- if (!*str && len == 1) continue; /* do not output terminating NULL */
if (escapes[*str] != '.')
pos += sprintf( pos, "\\%c", escapes[*str] );
else if (len > 1 && str[1] >= '0' && str[1] <= '7')
Module: wine
Branch: master
Commit: 7860dd06419e1d124f9f1389b39e3e79f26d551b
URL: https://gitlab.winehq.org/wine/wine/-/commit/7860dd06419e1d124f9f1389b39e3e…
Author: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
Date: Sun Sep 10 18:02:56 2023 +0200
ole32: Leave the RunningObjectTable Critical Section before umarshalling object.
Sometimes umarshalling an object from the RunningObjectTable can cause the routine to access the
table back inside another thread, causing a deadlock.
Visual Studio 2019 is an example of this behaviour.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
---
dlls/ole32/moniker.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dlls/ole32/moniker.c b/dlls/ole32/moniker.c
index ec026758b2f..f9f266044e4 100644
--- a/dlls/ole32/moniker.c
+++ b/dlls/ole32/moniker.c
@@ -541,13 +541,14 @@ RunningObjectTableImpl_GetObject( IRunningObjectTable* iface,
{
IStream *pStream;
hr = create_stream_on_mip_ro(rot_entry->object, &pStream);
+ LeaveCriticalSection(&This->lock);
+
if (hr == S_OK)
{
hr = CoUnmarshalInterface(pStream, &IID_IUnknown, (void **)ppunkObject);
IStream_Release(pStream);
}
- LeaveCriticalSection(&This->lock);
HeapFree(GetProcessHeap(), 0, moniker_data);
return hr;