June 2022 - Wine-Devel - list.winehq.org

[PATCH 2/7] wineandroid: Don't use unicode.h.

by Jacek Caban

From: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/wineandroid.drv/android.h | 7 +++++++ dlls/wineandroid.drv/keyboard.c | 9 +++++---- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/dlls/wineandroid.drv/android.h b/dlls/wineandroid.drv/android.h index 93e3c2201bf..a7581d1b67f 100644 --- a/dlls/wineandroid.drv/android.h +++ b/dlls/wineandroid.drv/android.h @@ -187,4 +187,11 @@ extern JavaVM **p_java_vm; extern jobject *p_java_object; extern unsigned short *p_java_gdt_sel; +/* string helpers */ + +static inline void ascii_to_unicode( WCHAR *dst, const char *src, size_t len ) +{ + while (len--) *dst++ = (unsigned char)*src++; +} + #endif /* __WINE_ANDROID_H */ diff --git a/dlls/wineandroid.drv/keyboard.c b/dlls/wineandroid.drv/keyboard.c index 00a55c697c6..e92079c0f59 100644 --- a/dlls/wineandroid.drv/keyboard.c +++ b/dlls/wineandroid.drv/keyboard.c @@ -32,7 +32,6 @@ #include "config.h" #include "android.h" -#include "wine/unicode.h" #include "wine/server.h" #include "wine/debug.h" @@ -802,9 +801,11 @@ INT ANDROID_GetKeyNameText( LONG lparam, LPWSTR buffer, INT size ) if (!len) { - static const WCHAR format[] = {'K','e','y',' ','0','x','%','0','2','x',0}; - snprintfW( buffer, size, format, vkey ); - len = strlenW( buffer ); + char name[16]; + len = sprintf( name, "Key 0x%02x", vkey ); + len = min( len + 1, size ); + ascii_to_unicode( buffer, name, len ); + if (len) buffer[--len] = 0; } TRACE( "lparam 0x%08x -> %s\n", lparam, debugstr_w( buffer )); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/191

June 6, 2022

[PATCH 1/7] wineandroid: Use ntdll for UTF8 conversion.

by Jacek Caban

From: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/wineandroid.drv/keyboard.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/dlls/wineandroid.drv/keyboard.c b/dlls/wineandroid.drv/keyboard.c index 20c6879de87..00a55c697c6 100644 --- a/dlls/wineandroid.drv/keyboard.c +++ b/dlls/wineandroid.drv/keyboard.c @@ -755,9 +755,10 @@ jboolean keyboard_event( JNIEnv *env, jobject obj, jint win, jint action, jint k */ INT ANDROID_GetKeyNameText( LONG lparam, LPWSTR buffer, INT size ) { - int scancode, vkey, len; + int scancode, vkey; const char *name; char key[2]; + DWORD len; scancode = (lparam >> 16) & 0x1FF; vkey = scancode_to_vkey( scancode ); @@ -795,7 +796,8 @@ INT ANDROID_GetKeyNameText( LONG lparam, LPWSTR buffer, INT size ) name = vkey_to_name( vkey ); } - len = MultiByteToWideChar( CP_UTF8, 0, name, -1, buffer, size ); + RtlUTF8ToUnicodeN( buffer, size * sizeof(WCHAR), &len, name, strlen( name ) + 1 ); + len /= sizeof(WCHAR); if (len) len--; if (!len) -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/191

June 6, 2022

[PATCH 0/7] MR191: wineandroid: PE conversion preparation

by Jacek Caban (＠jacek)

This MR removes Android audio driver. It was considered not worth the effort. If we ever need it, we may restore that from git history (maybe on top of future audio drivers interface unification). For the rest of the rest of driver, the conversion is rather straightforward, so I went ahead and just did it. The tricky part is that I could only build test it... Luckily, most of changes are sed or copy&paste. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/191

June 6, 2022

Re: [PATCH 3/5] d2d1: Implement property parsing for RegisterEffectFromStream().

by Ziqing Hui

On 6/6/22 7:00 PM, Nikolay Sivov wrote: > > > On 6/6/22 13:13, Ziqing Hui wrote: >> >> On 6/6/22 4:36 PM, Nikolay Sivov wrote: >>> >>> On 6/6/22 10:35, Ziqing Hui wrote: >>>> struct d2d_effect_info >>>> { >>>> const CLSID *clsid; >>>> UINT32 default_input_count; >>>> UINT32 min_inputs; >>>> UINT32 max_inputs; >>>> + WCHAR *display_name; >>>> + WCHAR *author; >>>> + WCHAR *category; >>>> + WCHAR *description; >>>> }; >>> Shouldn't these also be expressed as properties? >>> >> Yeah, these are properties in XML. >> >> However, there are two kinds of effect properties, one is system property, the other is custom property. >> >> System property always exists in every effect, not matter if we express them in effect XML or not. >> So my thought is, since they always exists, we don't need to dynamically store them in properties array. We can use one struct to store all system properties. >> We store custom properties as d2d_effect_property, while handle system properties separately. >> >> Currently, we are storing system properties in struct d2d_effect_info. Each field in info is a system property. >> So I just put them there like before. >> >> Also, system properties don't have custom setter and getter, while custom properties have. >> >> Do you think my thought is ok or maybe we should take a different way? > > Hard to tell before it's done. Even we don't have to store them along with custom properties, it would be better to have some organized way for them, and not separate fields. I guess for now we could even ignore them to some extent, the only important ones are input/output configuration. Effect parameters will be all custom properties, right? > Yeah, effect parameters are all custom properties. >> >>>> +static D2D1_PROPERTY_TYPE str_to_property_type(const WCHAR *str) >>>> +{ >>>> + unsigned int i; >>>> + >>>> + static const WCHAR *type_str[] = >>>> + { >>>> + L"", L"string", L"bool", L"uint32", L"int32", L"float", L"vector2", L"vector3", >>>> + L"vector4", L"blob", L"iunknown", L"enum", L"array", L"clsid", L"matrix3x2", >>>> + L"matrix4x3", L"matrix4x4", L"matrix5x4", L"colorcontext", >>>> + }; >>>> + >>>> + for (i = 1; i < ARRAY_SIZE(type_str); ++i) >>>> + { >>>> + if (!wcscmp(str, type_str[i])) >>>> + return i; >>>> + } >>>> + >>>> + return D2D1_PROPERTY_TYPE_UNKNOWN; >>>> +} >>> This uses numeric values of D2D1_PROPERTY_TYPE, that deserves at least a comment.> >> Would it be ok like this: ? >> >> static const WCHAR *type_str[] = >> { >> L"", /* D2D1_PROPERTY_TYPE_UNKNOWN */ >> L"string", /* D2D1_PROPERTY_TYPE_STRING */ >> L"bool", /* D2D1_PROPERTY_TYPE_BOOL */ >> L"uint32", /* D2D1_PROPERTY_TYPE_UINT32 */ >> ... >> }; > Yes. >

June 6, 2022

Re: [PATCH 4/5] d2d1: Implement RegisterEffectFromString().

by Nikolay Sivov

On 6/6/22 13:31, Ziqing Hui wrote: > > On 6/6/22 4:37 PM, Nikolay Sivov wrote: >> >> On 6/6/22 10:35, Ziqing Hui wrote: >>> + size = sizeof(*property_xml) * (wcslen(property_xml) + 1); >>> + hglobal = GlobalAlloc(0, size); >>> + data = GlobalLock(hglobal); >>> + memcpy(data, property_xml, size); >>> + GlobalUnlock(hglobal); >>> + >>> + if (FAILED(hr = CreateStreamOnHGlobal(hglobal, TRUE, &stream))) >>> + return hr; >> Seems easier to write whole string in a stream, and seek back. >> > I'm not familiar with IStream interface... I'm not pretty sure how to do this. > Do I still use CreateStreamOnHGlobal() to create a stream? > Do you mean I should create a stream first. And then use IStream_Write() to write the string to it, then seek back? > Yes, create it with a null memory handle, Write, and Seek() back to the beginning. Another option is to have some wrapper that implements Read() and save on additional allocations, but it's more code that we don't need.

June 6, 2022

Re: [PATCH 3/5] d2d1: Implement property parsing for RegisterEffectFromStream().

by Nikolay Sivov

On 6/6/22 13:13, Ziqing Hui wrote: > > On 6/6/22 4:36 PM, Nikolay Sivov wrote: >> >> On 6/6/22 10:35, Ziqing Hui wrote: >>> struct d2d_effect_info >>> { >>> const CLSID *clsid; >>> UINT32 default_input_count; >>> UINT32 min_inputs; >>> UINT32 max_inputs; >>> + WCHAR *display_name; >>> + WCHAR *author; >>> + WCHAR *category; >>> + WCHAR *description; >>> }; >> Shouldn't these also be expressed as properties? >> > Yeah, these are properties in XML. > > However, there are two kinds of effect properties, one is system property, the other is custom property. > > System property always exists in every effect, not matter if we express them in effect XML or not. > So my thought is, since they always exists, we don't need to dynamically store them in properties array. We can use one struct to store all system properties. > We store custom properties as d2d_effect_property, while handle system properties separately. > > Currently, we are storing system properties in struct d2d_effect_info. Each field in info is a system property. > So I just put them there like before. > > Also, system properties don't have custom setter and getter, while custom properties have. > > Do you think my thought is ok or maybe we should take a different way? Hard to tell before it's done. Even we don't have to store them along with custom properties, it would be better to have some organized way for them, and not separate fields. I guess for now we could even ignore them to some extent, the only important ones are input/output configuration. Effect parameters will be all custom properties, right? > >>> +static D2D1_PROPERTY_TYPE str_to_property_type(const WCHAR *str) >>> +{ >>> + unsigned int i; >>> + >>> + static const WCHAR *type_str[] = >>> + { >>> + L"", L"string", L"bool", L"uint32", L"int32", L"float", L"vector2", L"vector3", >>> + L"vector4", L"blob", L"iunknown", L"enum", L"array", L"clsid", L"matrix3x2", >>> + L"matrix4x3", L"matrix4x4", L"matrix5x4", L"colorcontext", >>> + }; >>> + >>> + for (i = 1; i < ARRAY_SIZE(type_str); ++i) >>> + { >>> + if (!wcscmp(str, type_str[i])) >>> + return i; >>> + } >>> + >>> + return D2D1_PROPERTY_TYPE_UNKNOWN; >>> +} >> This uses numeric values of D2D1_PROPERTY_TYPE, that deserves at least a comment.> > Would it be ok like this: ? > > static const WCHAR *type_str[] = > { > L"", /* D2D1_PROPERTY_TYPE_UNKNOWN */ > L"string", /* D2D1_PROPERTY_TYPE_STRING */ > L"bool", /* D2D1_PROPERTY_TYPE_BOOL */ > L"uint32", /* D2D1_PROPERTY_TYPE_UINT32 */ > ... > }; Yes.

June 6, 2022

Re: [PATCH] cryptnet: Resolve object id to algorithm id when verifying OCSP response.

by Hans Leidekker

Signed-off-by: Hans Leidekker <hans(a)codeweavers.com>

June 6, 2022

Re: [PATCH 4/5] d2d1: Implement RegisterEffectFromString().

by Ziqing Hui

On 6/6/22 4:37 PM, Nikolay Sivov wrote: > > > On 6/6/22 10:35, Ziqing Hui wrote: >> + size = sizeof(*property_xml) * (wcslen(property_xml) + 1); >> + hglobal = GlobalAlloc(0, size); >> + data = GlobalLock(hglobal); >> + memcpy(data, property_xml, size); >> + GlobalUnlock(hglobal); >> + >> + if (FAILED(hr = CreateStreamOnHGlobal(hglobal, TRUE, &stream))) >> + return hr; > Seems easier to write whole string in a stream, and seek back. > I'm not familiar with IStream interface... I'm not pretty sure how to do this. Do I still use CreateStreamOnHGlobal() to create a stream? Do you mean I should create a stream first. And then use IStream_Write() to write the string to it, then seek back?

June 6, 2022

Re: [PATCH 3/5] d2d1: Implement property parsing for RegisterEffectFromStream().

by Ziqing Hui

On 6/6/22 4:36 PM, Nikolay Sivov wrote: > > > On 6/6/22 10:35, Ziqing Hui wrote: >> struct d2d_effect_info >> { >> const CLSID *clsid; >> UINT32 default_input_count; >> UINT32 min_inputs; >> UINT32 max_inputs; >> + WCHAR *display_name; >> + WCHAR *author; >> + WCHAR *category; >> + WCHAR *description; >> }; > Shouldn't these also be expressed as properties? > Yeah, these are properties in XML. However, there are two kinds of effect properties, one is system property, the other is custom property. System property always exists in every effect, not matter if we express them in effect XML or not. So my thought is, since they always exists, we don't need to dynamically store them in properties array. We can use one struct to store all system properties. We store custom properties as d2d_effect_property, while handle system properties separately. Currently, we are storing system properties in struct d2d_effect_info. Each field in info is a system property. So I just put them there like before. Also, system properties don't have custom setter and getter, while custom properties have. Do you think my thought is ok or maybe we should take a different way? >> +static D2D1_PROPERTY_TYPE str_to_property_type(const WCHAR *str) >> +{ >> + unsigned int i; >> + >> + static const WCHAR *type_str[] = >> + { >> + L"", L"string", L"bool", L"uint32", L"int32", L"float", L"vector2", L"vector3", >> + L"vector4", L"blob", L"iunknown", L"enum", L"array", L"clsid", L"matrix3x2", >> + L"matrix4x3", L"matrix4x4", L"matrix5x4", L"colorcontext", >> + }; >> + >> + for (i = 1; i < ARRAY_SIZE(type_str); ++i) >> + { >> + if (!wcscmp(str, type_str[i])) >> + return i; >> + } >> + >> + return D2D1_PROPERTY_TYPE_UNKNOWN; >> +} > This uses numeric values of D2D1_PROPERTY_TYPE, that deserves at least a comment.> Would it be ok like this: ? static const WCHAR *type_str[] = { L"", /* D2D1_PROPERTY_TYPE_UNKNOWN */ L"string", /* D2D1_PROPERTY_TYPE_STRING */ L"bool", /* D2D1_PROPERTY_TYPE_BOOL */ L"uint32", /* D2D1_PROPERTY_TYPE_UINT32 */ ... };

June 6, 2022

Re: [PATCH 2/5] d2d1: Partially implement RegisterEffectFromStream().

by Ziqing Hui

On 6/6/22 4:29 PM, Nikolay Sivov wrote: > > > On 6/6/22 10:35, Ziqing Hui wrote: >> +struct d2d_effect_reg >> +{ >> + PD2D1_EFFECT_FACTORY factory; >> + UINT32 count; >> + >> + struct d2d_effect_info *info; >> + >> + struct list entry; >> +}; > You don't need to allocate 'info' separately. > >> + memset(node_name, 0, sizeof(node_name)); >> + while (IXmlReader_Read(xml_reader, &type) == S_OK) >> + { >> + if (FAILED(hr = IXmlReader_GetDepth(xml_reader, &depth))) >> + goto done; >> + if (depth >= 3) >> + continue; >> + if (FAILED(hr = IXmlReader_GetLocalName(xml_reader, &value, &len))) >> + goto done; >> + if (node_name[depth] && wcslen(node_name[depth]) <= len) >> + { >> + wcscpy(node_name[depth], value); >> + } >> + else >> + { >> + heap_free(node_name[depth]); >> + node_name[depth] = heap_strdupW(value); >> + } >> + >> + if (type != XmlNodeType_Element) >> + continue; > > Depth should not be used for this. What you need is to first find "Effect" element. After that loop within it, until you run out of nested elements. You can then have helpers to process specific elements like Property or Inputs. > >> + if (!wcscmp(node_name[depth - 1], L"Effect") >> + && !wcscmp(node_name[depth], L"Property")) > Is it really case-sensitive? I'm not sure. I'll add a test for it. > >> + reg->info->default_input_count = input_count; >> + reg->info->min_inputs = input_count; >> + reg->info->max_inputs = input_count; > Is this supposed to be subproperties of an Input? Maybe we should have basic property support first, and store it there. Is min/max/default expressible in effect xml? <Input> attributes maybe? It is likely that they can be expressed in xml as properties of <Effect> like "DisplayName"/"Author", tests are still needed. And according to the current test, if I don't explicitly express them in xml, they will be equal to the number of <Input> nodes inside <Inputs>. >> + entry->count = 1; >> + entry->info->clsid = effect_id; >> + entry->factory = effect_factory; >> + list_add_tail(&factory->effect_regs, &entry->entry); > This should store GUID itself, not a pointer. >

June 6, 2022