April 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] mfplat: Implement MFTRegister

by Nikolay Sivov

On 28.04.2017 7:28, Alistair Leslie-Hughes wrote: > From: Michael Müller <michael(a)fds-team.de> > > Changes > - Added pointer check output_types, input_types > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/mfplat/Makefile.in | 1 + > dlls/mfplat/main.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/mfplat/mfplat.spec | 2 +- > loader/wine.inf.in | 4 ++ > 4 files changed, 150 insertions(+), 1 deletion(-) > > diff --git a/dlls/mfplat/Makefile.in b/dlls/mfplat/Makefile.in > index 2b5bd24..9679f53 100644 > --- a/dlls/mfplat/Makefile.in > +++ b/dlls/mfplat/Makefile.in > @@ -1,4 +1,5 @@ > MODULE = mfplat.dll > +IMPORTS = user32 advapi32 > > C_SRCS = \ > main.c > diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c > index aae81f8..424c7f4 100644 > --- a/dlls/mfplat/main.c > +++ b/dlls/mfplat/main.c > @@ -23,15 +23,44 @@ > > #include "windef.h" > #include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > > #include "initguid.h" > #include "mfapi.h" > #include "mferror.h" > > #include "wine/debug.h" > +#include "wine/unicode.h" > > WINE_DEFAULT_DEBUG_CHANNEL(mfplat); > > +static WCHAR transform_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s',0}; > +static WCHAR categories_keyW[] = {'S','o','f','t','w','a','r','e','\\','C','l','a','s','s','e','s', > + '\\','M','e','d','i','a','F','o','u','n','d','a','t','i','o','n','\\', > + 'T','r','a','n','s','f','o','r','m','s','\\', > + 'C','a','t','e','g','o','r','i','e','s',0}; > +static WCHAR inputtypesW[] = {'I','n','p','u','t','T','y','p','e','s',0}; > +static WCHAR outputtypesW[] = {'O','u','t','p','u','t','T','y','p','e','s',0}; Shouldn't those be constants too? > +static const WCHAR szGUIDFmt[] = > +{ > + '%','0','8','x','-','%','0','4','x','-','%','0','4','x','-','%','0', > + '2','x','%','0','2','x','-','%','0','2','x','%','0','2','x','%','0','2', > + 'x','%','0','2','x','%','0','2','x','%','0','2','x',0 > +}; > + > +static LPWSTR GUIDToString(LPWSTR lpwstr, REFGUID lpcguid) > +{ > + wsprintfW(lpwstr, szGUIDFmt, lpcguid->Data1, lpcguid->Data2, > + lpcguid->Data3, lpcguid->Data4[0], lpcguid->Data4[1], > + lpcguid->Data4[2], lpcguid->Data4[3], lpcguid->Data4[4], > + lpcguid->Data4[5], lpcguid->Data4[6], lpcguid->Data4[7]); > + > + return lpwstr; > +} It's easier to use sprintfW() here. Please for consistency remove the rest of LP* types and prefixed names. > + > BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > { > switch (reason) > @@ -46,6 +75,121 @@ BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, LPVOID reserved) > return TRUE; > } > > +static HRESULT register_transform(CLSID *clsid, WCHAR *name, > + UINT32 cinput, MFT_REGISTER_TYPE_INFO *input_types, > + UINT32 coutput, MFT_REGISTER_TYPE_INFO *output_types) > +{ > + HKEY htransform, hclsid = 0; > + WCHAR buffer[64]; > + GUID *types; > + DWORD size; > + LONG ret; > + UINT32 i; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, transform_keyW, &htransform)) > + return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htransform, buffer, &hclsid); > + RegCloseKey(htransform); > + if (ret) return E_FAIL; > + > + size = (strlenW(name) + 1) * sizeof(WCHAR); > + if (RegSetValueExW(hclsid, NULL, 0, REG_SZ, (BYTE *)name, size)) > + goto err; > + > + if (cinput && input_types) > + { > + size = 2 * cinput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < cinput; i++) > + { > + memcpy(&types[2 * i], &input_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &input_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, inputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + if (coutput && output_types) > + { > + size = 2 * coutput * sizeof(GUID); > + types = HeapAlloc(GetProcessHeap(), 0, size); > + if (!types) goto err; > + > + for (i = 0; i < coutput; i++) > + { > + memcpy(&types[2 * i], &output_types[i].guidMajorType, sizeof(GUID)); > + memcpy(&types[2 * i + 1], &output_types[i].guidSubtype, sizeof(GUID)); > + } > + > + ret = RegSetValueExW(hclsid, outputtypesW, 0, REG_BINARY, (BYTE *)types, size); > + HeapFree(GetProcessHeap(), 0, types); > + if (ret) goto err; > + } > + > + RegCloseKey(hclsid); > + return S_OK; > + > +err: > + RegCloseKey(hclsid); > + return E_FAIL; > +} > + > +static HRESULT register_category(CLSID *clsid, GUID *category) > +{ > + HKEY hcategory, htmp1, htmp2; > + WCHAR buffer[64]; > + DWORD ret; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, categories_keyW, &hcategory)) > + return E_FAIL; > + > + GUIDToString(buffer, category); > + ret = RegCreateKeyW(hcategory, buffer, &htmp1); > + RegCloseKey(hcategory); > + if (ret) return E_FAIL; > + > + GUIDToString(buffer, clsid); > + ret = RegCreateKeyW(htmp1, buffer, &htmp2); > + RegCloseKey(htmp1); > + if (ret) return E_FAIL; > + > + RegCloseKey(htmp2); > + return S_OK; > +} > + > +/*********************************************************************** > + * MFTRegister (mfplat.@) > + */ > +HRESULT WINAPI MFTRegister(CLSID clsid, GUID category, LPWSTR name, UINT32 flags, UINT32 cinput, > + MFT_REGISTER_TYPE_INFO *input_types, UINT32 coutput, > + MFT_REGISTER_TYPE_INFO *output_types, void *attributes) This should use proper type for last argument. > +{ > + HRESULT hr; > + > + FIXME("(%s, %s, %s, %x, %u, %p, %u, %p, %p)\n", debugstr_guid(&clsid), debugstr_guid(&category), > + debugstr_w(name), flags, cinput, input_types, > + coutput, output_types, attributes); > + Why FIXME? > + if (attributes) > + FIXME("attributes not yet supported.\n"); > + > + if (flags) > + FIXME("flags not yet supported.\n"); > + > + hr = register_transform(&clsid, name, cinput, input_types, coutput, output_types); > + > + if (SUCCEEDED(hr)) > + hr = register_category(&clsid, &category); > + > + return hr; > +}

April 28, 2017

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)

by Bruno Jesus

On Thu, Apr 27, 2017 at 8:27 PM, Michael Müller <michael(a)fds-team.de> wrote: > This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: > > schannel_gnutls.c: In function schannel_get_mac_algid: > schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use in this function) > schannel_gnutls.c:329:10: note: each undeclared identifier is reported only once for each function it appears in > > Build overview: https://dev.wine-staging.com/builder/group/60/ (Click Downloads for build logs) > Debian Wheezy build log: https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log PC-BSD 9 broke too, same error.

April 28, 2017

Re: [4/6] secur32: Return PRF algorithm value when using GCM. (resend)

by Michael Müller

This patch broke the compilation on Debian Wheezy and Ubuntu Trusty: schannel_gnutls.c: In function schannel_get_mac_algid: schannel_gnutls.c:329:10: error: ‘GNUTLS_MAC_AEAD undeclared (first use in this function) schannel_gnutls.c:329:10: note: each undeclared identifier is reported only once for each function it appears in Build overview: https://dev.wine-staging.com/builder/group/60/ (Click Downloads for build logs) Debian Wheezy build log: https://builds.wine-staging.com/2017-04-27-21-23-02-job-10597/build.log Regards, Michael

April 27, 2017

Re: [PATCH 5/9] d3dx9: Store effect creation flags in struct d3dx_base_effect.

by Matteo Bruni

2017-04-28 0:35 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > On 04/28/2017 01:30 AM, Matteo Bruni wrote: >> >> 2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >>> >>> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> >>> --- >>> dlls/d3dx9_36/effect.c | 8 +++++--- >>> 1 file changed, 5 insertions(+), 3 deletions(-) >>> >>> diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c >>> index c2fb1d0..7885241 100644 >>> --- a/dlls/d3dx9_36/effect.c >>> +++ b/dlls/d3dx9_36/effect.c >>> @@ -154,6 +154,7 @@ struct d3dx9_base_effect >>> struct d3dx_object *objects; >>> >>> struct d3dx_effect_pool *pool; >>> + DWORD flags; >>> }; >>> >>> struct ID3DXEffectImpl >>> @@ -169,7 +170,7 @@ struct ID3DXEffectImpl >>> struct d3dx_technique *active_technique; >>> struct d3dx_pass *active_pass; >>> BOOL started; >>> - DWORD flags; >>> + DWORD begin_flags; >> >> begin_flags is quite ugly IMO. If you really want to change it from >> just flags, maybe call it creation_flags. >> >> > But they are not creation flags, that's why I wanted to change the name, as > otherwise we would end up having 'flags' in ID3DXEffectImpl and same 'flags' > in 'd3dx9_base_effect'. Those flags in ID3DXEffectImpl are the flags passed > to effect Begin() function, not to the effect creation. Maybe rename them to > effect_begin_flags then? Ah, right. No, it's fine then.

April 27, 2017

Re: [v6 PATCH 03/21] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

by Ricardo Neri

On Wed, 2017-04-26 at 10:05 +0200, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 07:04:20PM -0700, Ricardo Neri wrote: > > For the specific case of ModRM.mod being 0, I feel I need to clarify > > that REX.B is not decoded and if SIB.base is %r13 the base is also 0. > > Well, that all doesn't matter. The rule is this: > > ModRM.mod == 00b and ModRM.r/m == 101b -> effective address: disp32 > > See Table 2-2. "32-Bit Addressing Forms with the ModR/M Byte" in the SDM. You are right. This summarizes the rule. Then I will shorten the comment. > > So the base register is not used. How that base register is specified > then doesn't matter (undecoded REX bits or not). > > > This comment adds clarity because REX.X is decoded when determining > > SIB.index. > > Well, that's a different thing. The REX bits participating in the SIB > fields don't matter about this particular case. We only want to say that > we're returning a disp32 without a base register and the comment should > keep it simple without extraneous information. > > I know, you want to mention what Table 2-5. "Special Cases of REX > Encodings" says but we should avoid unnecessary content in the comment. > People who want details can stare at the manuals - the comment should > only document what that particular case is. > > Btw, you could write it even better: > > if (!X86_MODRM_MOD(insn->modrm.value) && X86_MODRM_RM(insn->modrm.value) == 5) > > and then it is basically a 1:1 copy of the rule from Table 2-2. It is! Thanks and BR, Ricardo

April 27, 2017

Re: [PATCH 5/9] d3dx9: Store effect creation flags in struct d3dx_base_effect.

by Paul Gofman

On 04/28/2017 01:30 AM, Matteo Bruni wrote: > 2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> >> --- >> dlls/d3dx9_36/effect.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c >> index c2fb1d0..7885241 100644 >> --- a/dlls/d3dx9_36/effect.c >> +++ b/dlls/d3dx9_36/effect.c >> @@ -154,6 +154,7 @@ struct d3dx9_base_effect >> struct d3dx_object *objects; >> >> struct d3dx_effect_pool *pool; >> + DWORD flags; >> }; >> >> struct ID3DXEffectImpl >> @@ -169,7 +170,7 @@ struct ID3DXEffectImpl >> struct d3dx_technique *active_technique; >> struct d3dx_pass *active_pass; >> BOOL started; >> - DWORD flags; >> + DWORD begin_flags; > begin_flags is quite ugly IMO. If you really want to change it from > just flags, maybe call it creation_flags. > > But they are not creation flags, that's why I wanted to change the name, as otherwise we would end up having 'flags' in ID3DXEffectImpl and same 'flags' in 'd3dx9_base_effect'. Those flags in ID3DXEffectImpl are the flags passed to effect Begin() function, not to the effect creation. Maybe rename them to effect_begin_flags then?

April 27, 2017

Re: [PATCH 5/9] d3dx9: Store effect creation flags in struct d3dx_base_effect.

by Matteo Bruni

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/effect.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index c2fb1d0..7885241 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -154,6 +154,7 @@ struct d3dx9_base_effect > struct d3dx_object *objects; > > struct d3dx_effect_pool *pool; > + DWORD flags; > }; > > struct ID3DXEffectImpl > @@ -169,7 +170,7 @@ struct ID3DXEffectImpl > struct d3dx_technique *active_technique; > struct d3dx_pass *active_pass; > BOOL started; > - DWORD flags; > + DWORD begin_flags; begin_flags is quite ugly IMO. If you really want to change it from just flags, maybe call it creation_flags.

April 27, 2017

Re: [PATCH 4/9] d3dx9/tests: Add test for D3DXFX_LARGEADDRESSAWARE effect creation flag.

by Matteo Bruni

2017-04-27 13:05 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/tests/effect.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 997c1fc..a58352e 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -5743,6 +5743,30 @@ static void test_cross_effect_handle(IDirect3DDevice9 *device) > > effect2->lpVtbl->Release(effect2); > effect1->lpVtbl->Release(effect1); > + > + hr = D3DXCreateEffect(device, test_effect_preshader_effect_blob, sizeof(test_effect_preshader_effect_blob), > + NULL, NULL, D3DXFX_LARGEADDRESSAWARE, NULL, &effect1, NULL); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + param1 = effect1->lpVtbl->GetParameterByName(effect1, NULL, "g_iVect"); > + ok(!!param1, "GetParameterByName failed.\n"); > + > + hr = effect1->lpVtbl->SetValue(effect1, param1, expected_ivect, sizeof(expected_ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + hr = effect1->lpVtbl->GetValue(effect1, param1, ivect, sizeof(ivect)); > + ok(hr == D3D_OK, "Got result %#x.\n", hr); > + > + ok(!memcmp(ivect, expected_ivect, sizeof(expected_ivect)), "Vector value mismatch.\n"); > + > + if (0) > + { > + /* Native d3dx crashes in GetValue(). */ > + hr = effect1->lpVtbl->GetValue(effect1, "g_iVect", ivect, sizeof(ivect)); > + ok(hr == D3DERR_INVALIDCALL, "Got result %#x.\n", hr); > + } > + > + effect1->lpVtbl->Release(effect1); > } The test is okay but it doesn't feel right to put it in test_cross_effect_handle(). Probably just make a separate function.

April 27, 2017

Re: [PATCH 2/3] dwrite: Fix name section strings lookup

by Nikolay Sivov

On 27.04.2017 17:54, Piotr Caban wrote: > On 04/27/17 16:52, Nikolay Sivov wrote: >> On 27.04.2017 17:03, Piotr Caban wrote: >>> Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> >>> --- >>> dlls/dwrite/opentype.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> >> >> The problem with this patch is that we want to continue and add as many >> strings for different locales as possible. So the condition should set >> 'exists' to TRUE after first pair was added successfully and never touch >> it after. >> >> > Yes, sorry, this patch is incorrect. I think that it would be nice to > not fail in hard way if any of the names were decoded. Also I'll check > why name decoding fails here. Yes, it shouldn't fail if only some records failed, it does that now because variable is overwritten on every iteration. > > Thanks, > Piotr

April 27, 2017

Re: [PATCH 2/3] dwrite: Fix name section strings lookup

by Piotr Caban

Hi Nikolay, this should probably give some more light on what is happening. The font that is failing has following entry in names section: PlatformID: 3 (Windows) LanguageID: USHORT_MAX The data is in UTF-16 format. Thanks, Piotr

April 27, 2017