March 2018 - Wine-Devel - list.winehq.org

Re: [PATCH vkd3d 3/3] tests: Add test for custom PRESENT state transitions.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

March 29, 2018

Re: [PATCH vkd3d 2/3] tests: Allow sharing common code between D3D12 tests.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

March 29, 2018

Re: [PATCH vkd3d 1/3] libs/vkd3d: Add support for custom PRESENT state transitions.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

March 29, 2018

Re: [PATCH 1/2] windowscodecs: Use common base structure for component info implementations.

by Jacek Caban

Hi Vincent, On 03/29/2018 10:11 PM, Vincent Povirk wrote: > This looks fine, but I'm not sure if incrementally changing our > current implementation is the best approach. Incremental changes have value of their own (easier to review, less likely to break, more regression testing friendly), but sure, depending on end goal might not be the best approach. I still think it is the right approach in this case. > I know Windows doesn't > store data in the registry at all for builtin components, Yeah, it would be nice to do that as well. > and my impression is that for custom components it reads from the registry > all at once. My vision for future of this is to read it all in component info constructor. Once we'd have that, a change between reading on the first CreateComponentInfo() for given component or all at once would be rather small and straightforward. > I think the ideal for us is to have some internal data structure > containing all the data, which would be static for builtins and > dynamic for registry info. I'm not sure I agree. For example, the form in which GetPattern() returns pattern is not cleanly expressed as C constants (and regsvr.c has it in a form that allows clean C constants). I guess we need the code to do the conversion, the question is where do we want it. I'd say it's better to convert that in constructor and do simple memcpy() inside GetPattern() instead of doing the conversion every time GetPattern() is called. If we do it that way, registry-based component info could fill that structure inside constructor as well and GetPattern() wouldn't need to care if it's builtin or custom component. > We could probably get rid of the custom > registration for windowscodecs.dll on prefix creation That would be nice. > (but I'm not sure about the COM stuff). We can't get rid of COM registration, but note that once the registration is purely .rgs file based and doesn't need any thing else, Wine is smart and uses that .rgs resources directly instead of calling DllRegisterServer so it's much faster. > I'm not aware of any application that uses its own custom components, > so it might not be all that bad to start over with static data and > leave the dynamic data for later if we need it. But that would be > removing a feature that theoretically works now. I don't think that a step forward. Thanks, Jacek

March 29, 2018

Re: [PATCH 1/2] windowscodecs: Use common base structure for component info implementations.

by Vincent Povirk

This looks fine, but I'm not sure if incrementally changing our current implementation is the best approach. I know Windows doesn't store data in the registry at all for builtin components, and my impression is that for custom components it reads from the registry all at once. I think the ideal for us is to have some internal data structure containing all the data, which would be static for builtins and dynamic for registry info. We could probably get rid of the custom registration for windowscodecs.dll on prefix creation (but I'm not sure about the COM stuff). I'm not aware of any application that uses its own custom components, so it might not be all that bad to start over with static data and leave the dynamic data for later if we need it. But that would be removing a feature that theoretically works now.

March 29, 2018

[PATCH 2/2] windowscodecs: Cache component info objects.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/windowscodecs/info.c | 47 +++++++++++++++++++++++++++++++++- dlls/windowscodecs/main.c | 3 +++ dlls/windowscodecs/tests/info.c | 31 +++++++++++++++++++--- dlls/windowscodecs/wincodecs_private.h | 1 + 4 files changed, 78 insertions(+), 4 deletions(-)

March 29, 2018

[PATCH 1/2] windowscodecs: Use common base structure for component info implementations.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- dlls/windowscodecs/info.c | 148 ++++++++++++++++++++++------------------------ 1 file changed, 71 insertions(+), 77 deletions(-)

March 29, 2018

WineConf and sound recording

by M. GOUJON

Hi everyone, Recordings of previous wine confs have been somewhat disappointing especially the sound part: microphone buggy, people asking question too far from the micro... Some of you are native English speakers, others not and understanding everyone quickly becomes a challenge (and you ends up with a headache). May I suggest you to buy some clip-on microphones ? Handheld ones ones are heavy and people always forget to speak in it. If you wanna invest some bucks, digital recorders are the best option. If needed, I can donate those missing bucks.

March 29, 2018

[PATCH] hlink/tests: Fix save data test on newer Windows 10

by André Hentschel

Signed-off-by: André Hentschel <nerv(a)dawncrow.de> --- dlls/hlink/tests/hlink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dlls/hlink/tests/hlink.c b/dlls/hlink/tests/hlink.c index 3525c44..265dea3 100644 --- a/dlls/hlink/tests/hlink.c +++ b/dlls/hlink/tests/hlink.c @@ -417,7 +417,8 @@ static void test_persist_save_data(const char *testname, IHlink *lnk, (expected_data_alt == expected_hlink_data3_ie7 && i == 109) /* Win10 */ || (expected_data_alt == expected_hlink_data5_ie7 && i == 107) /* Win10 */) { - ok(data[i] == 0 || broken(data[i] == 1), "Expected 0 or 1, got %d\n", data[i]); + ok(data[i] == 0 || broken(data[i] == 1) || broken(data[i] == 3), + "Expected 0 or 1, got %d\n", data[i]); continue; } if ((expected_data_alt[i] != data[i]) && -- 2.7.4

March 29, 2018

[PATCH 2/2] kernel32/tests: Allow GetLastError to be unchanged in a test

by André Hentschel

Signed-off-by: André Hentschel <nerv(a)dawncrow.de> --- dlls/kernel32/tests/locale.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c index 9ce46f9..16b201a 100644 --- a/dlls/kernel32/tests/locale.c +++ b/dlls/kernel32/tests/locale.c @@ -4660,7 +4660,8 @@ static void test_GetGeoInfo(void) SetLastError(0xdeadbeef); ret = pGetGeoInfoA(344, GEO_ISO2, NULL, 0, 0); ok(ret == 0, "got %d\n", ret); - ok(GetLastError() == ERROR_INVALID_PARAMETER, "got %d\n", GetLastError()); + ok(GetLastError() == ERROR_INVALID_PARAMETER || + broken(GetLastError() == 0xdeadbeef /* Win10 */), "got %d\n", GetLastError()); ret = pGetGeoInfoA(203, GEO_ISO2, NULL, 0, 0); ok(ret == 3, "got %d\n", ret); -- 2.7.4

March 29, 2018