On 3 August 2016 at 04:29, Alistair Leslie-Hughes
<leslie_alistair(a)hotmail.com> wrote:
> - if (tq->context->tid != GetCurrentThreadId())
> + if (!tq->context || tq->context->tid != GetCurrentThreadId())
How can the context be NULL?
On 03.08.2016 0:33, Bernhard Übelacker wrote:
> https://bugs.winehq.org/show_bug.cgi?id=40385
>
> ScriptStringAnalyse crashes if InClass is just one byte in size
> followed by memory marked as PAGE_NOACCESS.
> By testing the size it seems it should have the same size as characters
> in teststr are given to the function.
> ---
> dlls/usp10/tests/usp10.c | 103 +++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 95 insertions(+), 8 deletions(-)
>
> diff --git a/dlls/usp10/tests/usp10.c b/dlls/usp10/tests/usp10.c
> index 6b2152f..7eb0592 100644
> --- a/dlls/usp10/tests/usp10.c
> +++ b/dlls/usp10/tests/usp10.c
> @@ -2900,7 +2900,7 @@ static void test_ScriptString(HDC hdc)
> DWORD Flags = SSA_GLYPHS;
> int ReqWidth = 100;
> const int Dx[5] = {10, 10, 10, 10, 10};
> - const BYTE InClass = 0;
> + const BYTE InClass[len];
> SCRIPT_STRING_ANALYSIS ssa = NULL;
>
> int X = 10;
> @@ -2916,29 +2916,30 @@ static void test_ScriptString(HDC hdc)
>
>
> Charset = -1; /* this flag indicates unicode input */
> + memset((void*)InClass, 0, sizeof(InClass));
Instead of using len, it should be either use a constant, or be
allocated dynamically, otherwise you'll get compiler warning with
default flags we're building with.
I think it would be easier to make it 'static const BYTE InClass[32];'
(or whatever length is appropriate).
Otherwise it looks reasonable, thanks for working on this.
Hi Ken,
I was looking into how the Linux-dinput code and joy.cpl work and comparing
that to the macOS-dinput code. I have some questions about how best to
proceed:
joy.cpl uses joy->instance.tszInstanceName to name the joysticks in the
control panel. In Linux-dinput code, they pass
the joystick_devices[id].name to both tszInstanceName and tszProductName
In the macOS-dinput code, they pass the name "Joystick #" where # is the
index in the joystick array to the instance name and the joystick's actual
name to the product name. When looking at the Microsoft guidelines for
dinput, it does indeed say that the instance name *can* be joystick +
position in the array, but doesn't specify that it *has* to be (
https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_…).
Also, I've confirmed that in the Windows 10 joystick control panel the
joysticks are listed by their name, not by joystick number (and in my
memory of earlier Windows OSes it's the same).
So, should I change the macOS-dinput code to set both tszInstanceName
and tszProductName to the product name (as in Linux) or should I change
joy.cpl to use tszProductName instead of tszInstanceName? This will also
make it easier in the registry to know which joystick is being
enabled/disabled.
Further, while joy.cpl correctly is a dinput control panel,
enabling/disabling joystick should be for both dinput and winmm games -
e.g. X-wing vs Tie Fighter even has the joystick control panel in the
game's loader window*, but, once in the game, joystick control is handled
by winmm. I believe the joystick registry entry is under dinput, but the
winmm wine joystick driver should read that as well.
Is it acceptable for wine joystick driver to read the dinput registry? Or
should two registry entries be created? or should a single general joystick
registry entry not under dinput or winmm control both?
I may have more questions, but we'll start off with these. :)
Cheers,
David
*Interestingly, the game's sequel X-wing: Alliance says I need to install
DirectX to access joystick options in the loader window. I'm not sure why
the older title brings up the joystick control panel just fine, but the
later one does not.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=24688
Your paranoid android.
=== w1064 (32 bit thread) ===
thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=24687
Your paranoid android.
=== w1064 (32 bit loader) ===
loader.c:2980: Test failed: Test 0: ResolveDelayLoadedAPI failed
loader.c:2981: Test failed: Test 0: expected 74374550, got 00000000
loader.c:2980: Test failed: Test 1: ResolveDelayLoadedAPI failed
loader.c:2981: Test failed: Test 1: expected 72BC2CF0, got 00000000
loader.c:2980: Test failed: Test 2: ResolveDelayLoadedAPI failed
loader.c:2981: Test failed: Test 2: expected 74372DC0, got 00000000
loader.c:2988: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000
loader.c:2989: Test failed: Test 3: Wrong callback count: 0
loader.c:2988: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000
loader.c:2989: Test failed: Test 4: Wrong callback count: 0
=== wvistau64 (64 bit loader) ===
loader.c:720: Test failed: 2: unexpected error 193
loader.c:720: Test failed: 3: unexpected error 193
loader.c:720: Test failed: 4: unexpected error 193
loader.c:720: Test failed: 6: unexpected error 193
loader.c:720: Test failed: 7: unexpected error 193
loader.c:177: Test failed: WriteFile error 1784
=== w2008s64 (64 bit loader) ===
loader.c:720: Test failed: 2: unexpected error 193
loader.c:720: Test failed: 3: unexpected error 193
loader.c:720: Test failed: 4: unexpected error 193
loader.c:720: Test failed: 6: unexpected error 193
loader.c:720: Test failed: 7: unexpected error 193
loader.c:177: Test failed: WriteFile error 1784
=== w7pro64 (64 bit loader) ===
loader.c:720: Test failed: 2: unexpected error 193
loader.c:720: Test failed: 3: unexpected error 193
loader.c:720: Test failed: 4: unexpected error 193
loader.c:720: Test failed: 6: unexpected error 193
loader.c:720: Test failed: 7: unexpected error 193
loader.c:177: Test failed: WriteFile error 1784
=== w864 (64 bit loader) ===
loader.c:720: Test failed: 2: unexpected error 193
loader.c:720: Test failed: 3: unexpected error 193
loader.c:720: Test failed: 4: unexpected error 193
loader.c:720: Test failed: 6: unexpected error 193
loader.c:720: Test failed: 7: unexpected error 193
loader.c:177: Test failed: WriteFile error 1784
=== w1064 (64 bit loader) ===
loader.c:720: Test failed: 2: unexpected error 193
loader.c:720: Test failed: 3: unexpected error 193
loader.c:720: Test failed: 4: unexpected error 193
loader.c:720: Test failed: 6: unexpected error 193
loader.c:720: Test failed: 7: unexpected error 193
loader.c:177: Test failed: WriteFile error 1784
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=24683
Your paranoid android.
=== w1064 (32 bit usp10) ===
usp10.c:1467: Test failed: 0: uJustification incorrect (0)
usp10.c:1467: Test failed: 1: uJustification incorrect (0)
usp10.c:1467: Test failed: 2: uJustification incorrect (0)
usp10.c:1467: Test failed: 3: uJustification incorrect (0)
usp10.c:1467: Test failed: 4: uJustification incorrect (0)
usp10.c:1467: Test failed: 5: uJustification incorrect (0)
usp10.c:1467: Test failed: 6: uJustification incorrect (0)
usp10.c:1467: Test failed: 7: uJustification incorrect (0)
usp10.c:1467: Test failed: 8: uJustification incorrect (0)
usp10.c:1467: Test failed: 9: uJustification incorrect (0)
usp10.c:1483: Test failed: 3: uJustification incorrect (0)
usp10.c:1483: Test failed: 5: fDiacritic incorrect (1)
usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1)
usp10.c:1483: Test failed: 15: fDiacritic incorrect (1)
usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)
=== w1064 (64 bit usp10) ===
usp10.c:1467: Test failed: 0: uJustification incorrect (0)
usp10.c:1467: Test failed: 1: uJustification incorrect (0)
usp10.c:1467: Test failed: 2: uJustification incorrect (0)
usp10.c:1467: Test failed: 3: uJustification incorrect (0)
usp10.c:1467: Test failed: 4: uJustification incorrect (0)
usp10.c:1467: Test failed: 5: uJustification incorrect (0)
usp10.c:1467: Test failed: 6: uJustification incorrect (0)
usp10.c:1467: Test failed: 7: uJustification incorrect (0)
usp10.c:1467: Test failed: 8: uJustification incorrect (0)
usp10.c:1467: Test failed: 9: uJustification incorrect (0)
usp10.c:1483: Test failed: 3: uJustification incorrect (0)
usp10.c:1483: Test failed: 5: fDiacritic incorrect (1)
usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1)
usp10.c:1483: Test failed: 15: fDiacritic incorrect (1)
usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)
2016-08-01 22:28 GMT+02:00 Józef Kucia <jkucia(a)codeweavers.com>:
> + refcount = IDXGIOutput_Release(output);
> + ok(!refcount, "IDXGIOuput has %u references left.\n", refcount);
> refcount = IDXGIOutput_Release(output2);
> ok(!refcount, "IDXGIOuput has %u references left.\n", refcount);
There are a number of those "Ouput" typos through the patch, probably
copypasted from this preexisting ok() message.
Certainly not worth a resend by itself, but since you're going to anyway...