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=12500
Your paranoid android.
=== wvistau64 (32 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
=== w2008s64 (32 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
=== w7u (32 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
=== w8 (32 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
=== wvistau64 (64 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
=== w2008s64 (64 bit font) ===
font.c:1818: Test failed: got 0x8faecafe
Bruno Jesus <00cpxxx(a)gmail.com> writes:
> Use wine_dbg_sprintf instead of plain sprintf, that simplified the patch =)
What you really want is to implement a debugstr_sockopt and something
like a debugstr_optval and use these in normal TRACE statements, instead
of hiding the trace inside a helper function. Also you can't append to a
wine_dbg_sprintf string, that's why it's const...
--
Alexandre Julliard
julliard(a)winehq.org
Austin English <austinenglish(a)gmail.com> wrote:
> +@ stdcall QueryThreadCycleTime(ptr ptr)
...
> +BOOL WINAPI QueryThreadCycleTime(HANDLE thread, PULONG64 cycle)
'ptr' is not suitable for HANDLE in the .spec file.
--
Dmitry.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 2015-03-29 um 15:37 schrieb Aaryaman Vasishta:
> + { &IID_IDirect3DRM, NULL, E_NOINTERFACE, FALSE },
It's funny that this interface returns the right error value on QI.
> + hr = IDirect3DRM_CreateFrame(d3drm3, NULL, &frame3);
Minor nitpick: IDirect3DRM3_CreateFrame . You can resend the patch with a fix if you want, but I'm OK with this patch as it is.
Something to think about for future tests: It may make sense to split up d3drm.c into d3drm1.c, d3drm2.c and d3drm3.c for each interface version, similar to the ddraw tests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVGBWOAAoJEN0/YqbEcdMwLkUP/3S8gOP5XSYOgOkELFOSznNp
ir09O5ef1HUpECpZjCks7ez4IbUhswcb/idJ3UeEx3lSBy4vIk3vY0usXcXKkfMl
TlioDlOuzKhpXxb/5lZ/SUoG/nguBvzisKeifAA1gi8ne+3REhWeJvY6iBNDNDEX
dNUYiTP+qxsq8c+bzgydxDuu0OT7LVEXrVrDO1g3qOebJjFSdkXOnf1bCntejX4S
WdnxPlioWBMvffP42r0oinXzjoqobi5BDw8r4YppflEUou1bH3oT7fczJEpK4rBm
2ZDz9EOhvMOa6M5PSiqwPpINfI1PpH+p9S0r3iMZz8ux2VbXDyfJ0i/5CdzQ3HX8
rnNq/NcObXVgweBYIN7uFvjlo0Si963ACYDperAVyBNgP/oJXsz3dA5ysvrf6Lf8
Xy1kdP2B79AxWR3DRumQS9sbruaofENF16/7d9MZE933uWY9xBS6JIKTP0AVdDsP
tqF8ppHwVdPfpiazYnrG1ivpE0jNIPJJ67I6FWRC1S8k7QQVmbAdVnDgczDs6lLx
hiZbjksd4Uf16oGO29bXeZ2YM3Zi75K9pCa7ruYoftcF2ihd0tU01+jbM6hY32qm
K1RKe7/HCMANoal7pQEukARHVRvHDpVFRGJzeMbysc8yumnpbgl7/UI9z0wZvoYI
aCAXfxi21aSdCzxC7mIU
=9SMA
-----END PGP SIGNATURE-----
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=12491
Your paranoid android.
=== w7u (32 bit listview) ===
listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000
listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000
=== wvistau64 (64 bit listview) ===
listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000
listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000
=== w2008s64 (64 bit listview) ===
listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000
listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000
Forwarding on to wine-devel, Stas, and Ruslan from Bug 38041.
Any thoughts on the coning breakage, Stas?
Andrew
On Mon, Mar 23, 2015 at 09:52:32PM +0000, Mark Harmstone wrote:
> Hi,
>
> I've had a play with it, and yes, I think he's right. It seems to be a
> lot more robust than my code. One thing though that I think he's
> overlooked is that he changes the behaviour of AngleBetweenVectorsRad,
> which is called by AngleBetweenVectorsDeg and thus the coning code -
> I think this patch will probably break that.
>
> I've not tested it yet, but there's a chance this patch might fix
> bug 38041.
>
> Mark
>
> On 23/03/15 14:39, Andrew Eikum wrote:
> > This seems sane to me, but I never had a good grasp on this to begin
> > with. Does it look OK to you, Mark?
> >
> > Andrew
> >
> > On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote:
> >> This patch fixes incorrect sound positioning in dsound.
> >> As of now, angle to sound source is calculated as angle between
> >> vDistance and vOrientFront.
> >> This leads to incorrect results for all sources that are not in the
> >> same plane as speakers.
> >> In extreme case: for sources directly above or below origin, angle is
> >> calculated to -90 degrees, and they are played in the left speaker.
> >>
> >> This patch changes angle calculation: angle to sound source is
> >> calculated as angle between vDistance and plane given by vectors
> >> vOrientFront and vOrientTop.
> >> ---
> >> dlls/dsound/sound3d.c | 25 ++++++++++++++-----------
> >> 1 file changed, 14 insertions(+), 11 deletions(-)
> >
> >> From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001
> >> From: Stas Cymbalov <dummyunit(a)gmail.com>
> >> Date: Sun, 22 Mar 2015 18:22:49 +0300
> >> Subject: dsound: Fix angle to sound source calculation.
> >>
> >> ---
> >> dlls/dsound/sound3d.c | 25 ++++++++++++++-----------
> >> 1 file changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c
> >> index 9a0226a..ffd4d45 100644
> >> --- a/dlls/dsound/sound3d.c
> >> +++ b/dlls/dsound/sound3d.c
> >> @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT
> >>
> >> cos = product/(la*lb);
> >> angle = acos(cos);
> >> - if (cos < 0.0f) { angle -= M_PI; }
> >> TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x,
> >> b->y, b->z, angle, RadToDeg(angle));
> >> return angle;
> >> @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb)
> >> else
> >> {
> >> vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop);
> >> - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance);
> >> - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance);
> >> -
> >> - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle
> >> - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from
> >> - * this whether the sound is to our left or to our right. We have to perform another dot
> >> - * product, with a vector at right angles to the initial one, to get the correct angle.
> >> - * The angle should be between -180 degrees and 180 degrees. */
> >> - if (flAngle < 0.0f) { flAngle += M_PI; }
> >> - if (flAngle2 > 0.0f) { flAngle = -flAngle; }
> >> + /* To calculate angle to sound source we need to:
> >> + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0.
> >> + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector
> >> + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case).
> >> + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance
> >> + * and vOrientFront.
> >> + */
> >> + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance);
> >> + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance);
> >> + if (flAngle2 > M_PI_2)
> >> + flAngle = -flAngle;
> >> + flAngle -= M_PI_2;
> >> + if (flAngle < -M_PI)
> >> + flAngle += 2*M_PI;
> >> }
> >> TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan);
> >>
> >> --
> >> 2.0.5
> >>
> >
> >>
> >
>
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=12490
Your paranoid android.
=== w2000pro (32 bit d3drm) ===
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0.
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4.
d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5.
d3drm: unhandled exception c0000005 at 780273CD
=== wxppro (32 bit d3drm) ===
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0.
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4.
d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5.
d3drm: unhandled exception c0000005 at 77C46F07
=== w2003std (32 bit d3drm) ===
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0.
d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3.
d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4.
d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5.
d3drm: unhandled exception c0000005 at 77BD7D8D
On 03/29/2015 01:54 AM, Mark Harmstone wrote:
> This patch implements the class redirection feature of activation contexts, as
> used by version 6 of comctl32. Among other things, this is a necessary step in
> fixing the behaviour seen in bug 38124.
>
> ---
> dlls/user32/win.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
In principle it looks almost okay, except that I don't think we need it
right now, as long as comctl32 doesn't register versioned classes at
all. It will just wait time for every window creation requested looking
for something that can't be created. Comments on code itself to follow.
> + classatom = get_int_atom_value(className);
> + if (classatom)
> + GlobalGetAtomNameW(classatom, classNameStr, sizeof(classNameStr) / sizeof(*classNameStr));
> + else
> + strcpyW(classNameStr, className);
You don't need to copy in case of a string.
> + if (wcrd->name_len == 0)
> + return FALSE;
I don't think it can be 0, ever. Name comes from class name from module
manifest and assembly version string.
> + memcpy(redirClassName, (unsigned char*)askd.lpData + wcrd->name_offset, wcrd->name_len);
> + redirClassName[wcrd->name_len / sizeof(WCHAR)] = 0;
All strings in context data are null-terminated, so you don't need this
complexity. In fact you don't need to copy anything at all, you can just
use a (WCHAR*)((BYTE*)askd.lpData + wcrd->name_offset) as a ready-to-use
pointer, I think it's a preferred way, given that overhead of this
redirection lookup should be minimal.
So your helper only needs to return a pointer - original one or computed
from redirection data. And atoms should be resolved outside of it.
> + WCHAR redirClassName[256];
Is it defined somewhere to be limited to that?
> +
> + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode );
> +
> + if (GetLastError() == ERROR_INVALID_HANDLE && GetClassInfoW( 0, redirClassName, &wc ))
> + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode );
> +
I don't quite get what you're trying to do here? How does same call help
if called second time? Also last error check is strange.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
This patch has a few unrelated changes. The core change is that it
re-introduces a hack we once had in Wine and removed because it broke
newer mac GPUs. The CrossOver version of the hack works a bit better
than the unconditional Wine version, but it's still ugly.
Am 2015-03-28 um 06:15 schrieb Sergey Isakov:
> + /* Non-Apple GL vendors report uniforms correctly */
> + if (!match_apple(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return FALSE;
> + /* All dx9 cards are overreported on OSX */
> + if (!match_dx10_capable(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return TRUE;
> + /* Nvidia and Intel DX10 cards support > 256 uniforms */
> + if (card_vendor != HW_VENDOR_AMD) return FALSE;
It is terrible that OSX lies about the GPU capability and then forces
applications to have a crystal ball that tells them what the GPU can
actually do.
- From a pragmatic point of view I don't think OSX will ever change in
this regard. It was a design decision by Apple to do this, and they
stopped updating drivers for the old hardware a long time ago.
I am open to re-introducing the hack if we can find a way to detect the
bug more directly. E.g. try to declare a shader with 257 uniforms, read
them with indirect addressing so the driver can't optimize the access
and then check for software fallbacks. There's a CGL function for
checking that, but I don't remember from the top of my head how it works.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVFoC/AAoJEN0/YqbEcdMwcUIP/Rw24kSROYMK2Xvfe9vyEZ9S
NQd9RPHRQRNiXuXRfAmAUKm/PF17O7SUMKLAwjg90HGZySdDOH4MCb7rwaXryKYU
qV1ba75KR/JOi7db0r/WrZjf+mQ2+z1hES0SEg9jSYHxIcSNRhWvjB3H3rId7Och
TAEvsiT897rE7U/2GQmnw9popFPOPRm0Y2YY4f1XecF1XSdmBokpdmpcDzoRTxbX
8q11cWlPyqi3u6xiyX7SwEwoh7v/zpNd4c1yuL6kytSfV1w+sD4fMC4BitIvfd2X
OltqvQz5MfexglNlLJaeE1yplhrEKE2NHHdoIXhOhg7TdOeHYJfvrzgpjLWlUVnC
6BWsSkgge3OO3Pk7Fhi7Lht0EPhds+iq+7NCLwDV051Qi89kBlyJOY33bMMjryez
wHo+YEZEvk0IkkVQGkAjJfZzLFtxjMzIxcixijkJc3/aYwuF0ZyDVqFe3hj4gPTw
Ei1IThyWC4hdVqIuduD4t+5VH3GwU6JiYE6a16uHVTfoTSboN9te1WzV+lnhRFMf
P54xaJ+98sJrpq+670WU68jHzM/BmXXojyF+lxv8t0noXmHLJy7S4yskzDhowMMG
myjbDbeb/fB2O/oSdeOEXkskl2+XkotROM9qwF7a/yyaGe1/f47Y16gmrPyeCFD5
0Z68wLM5//XliOz91+hs
=1uP/
-----END PGP SIGNATURE-----
Hi,
original problem is described here:
https://bugs.winehq.org/show_bug.cgi?id=34825
I have the same problem with running Nanocad 5.1. The file open/import
dialog does not open with wine-1.7.39. I bisected the problem to
commit:
[bbf2cce16041e90d621a1f5889ea1bd760e21a0e] comdlg32: Do not modify
dialog resource directly.
I reverted this commit on latest wine and that fixed my issue with file open dialog.
--
Best regards,
Andrey Skvortsov
Secure eMail with gnupg: See http://www.gnupg.org/
PGP Key ID: 0x57A3AEAD
