- wine-devel - winehq.org

Re: [PATCH 1/2] d3drm: Fix QueryInterface for IDirect3DRMTexture*.
by Henri Verbeet 19 Jan '16

19 Jan '16

On 18 January 2016 at 19:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > - if (IsEqualGUID(riid, &IID_IDirect3DRMTexture2) > - || IsEqualGUID(riid, &IID_IDirect3DRMTexture) > + if (IsEqualGUID(riid, &IID_IDirect3DRMTexture) > + || IsEqualGUID(riid, &IID_IDirect3DRMVisual) > + || IsEqualGUID(riid, &IID_IDirect3DRMObject) > || IsEqualGUID(riid, &IID_IUnknown)) > { > + *out = &texture->IDirect3DRMTexture_iface; This isn't necessarily wrong, but it does seem weird. You return &texture->IDirect3DRMTexture_iface here for e.g. IUnknown, but the implementation then forwards to &texture->IDirect3DRMTexture3_iface. It seems more logical to return the IDirect3DRMTexture3 interface here directly. We also tend to check the "newest" IID first, in D3D code at least. I.e., IID_IDirect3DRMTexture3 before IID_IDirect3DRMTexture.

2 1

Re: winspool.drv: add EnumPrinterKeyA/W stubs
by Dmitry Timoshkov 19 Jan '16

19 Jan '16

Austin English <austinenglish(a)gmail.com> wrote: > +DWORD WINAPI EnumPrinterKeyW(HANDLE printer, const WCHAR *key, WCHAR *subkey, DWORD size, DWORD *ret); > +DWORD WINAPI EnumPrinterKeyW(HANDLE printer, const WCHAR *key, WCHAR *subkey, DWORD size, DWORD *ret); > +#define EnumPrinterKey WINELIB_NAME_AW(EnumPrinterKey) This doesn't look right. -- Dmitry.

2 1

Re: [PATCH 5/5] d3d8/tests: Block validation checks the surface size too.
by Marvin 18 Jan '16

18 Jan '16

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=19764 Your paranoid android. === w1064 (32 bit device) === device.c:2613: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2618: Test failed: The focus window is active. device.c:2626: Test failed: Got unexpected hr 0x88760869. device.c:2632: Test failed: Got unexpect screen size 800x600. device.c:2647: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2656: Test failed: Got unexpect screen size 800x600. device.c:2669: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2677: Test failed: Got unexpect width 640. device.c:2678: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 4/5] ddraw/tests: Port test_lockrect_invalid to other versions.
by Marvin 18 Jan '16

18 Jan '16

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=19763 Your paranoid android. === wxppro (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === w2003std (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === wvistau64 (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === w2008s64 (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === w7u (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === w7pro64 (32 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00461957 === w1064 (32 bit ddraw4) === ddraw4.c:2523: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === wvistau64 (64 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 0000000000457AC7 === w2008s64 (64 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 0000000000457AC7 === w7pro64 (64 bit ddraw4) === ddraw4.c:10352: Test failed: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 0000000000457AC7 === wxppro (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === w2003std (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === wvistau64 (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === w2008s64 (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === w7u (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === w7pro64 (32 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 0043A6FE === w1064 (32 bit ddraw2) === ddraw2.c:2338: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === wvistau64 (64 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00000000004356FB === w2008s64 (64 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00000000004356FB === w7pro64 (64 bit ddraw2) === ddraw2.c:9182: Test failed: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00000000004356FB === w1064 (32 bit dsurface) === dsurface.c:144: Test failed: Destination data after blitting is not correct dsurface.c:178: Test failed: Destination data after blitting is not correct dsurface.c:357: Test failed: Surface data after srckey blit does not match dsurface.c:382: Test failed: Surface data after src override key blit does not match dsurface.c:436: Test failed: Surface data after dest key blit does not match dsurface.c:462: Test failed: Surface data after dest key override blit does not match dsurface.c:524: Test failed: Surface data with src key and dest key blit does not match === wxppro (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === w2003std (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === wvistau64 (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === w2008s64 (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === w7u (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === w7pro64 (32 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 004147C8 === w1064 (32 bit ddraw1) === ddraw1.c:2187: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === wvistau64 (64 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0000000000413727 === w2008s64 (64 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0000000000413727 === w7pro64 (64 bit ddraw1) === ddraw1.c:8079: Test failed: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0000000000413727 === wxppro (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === w2003std (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === wvistau64 (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === w2008s64 (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === w7u (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === w7pro64 (32 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 004985FD === w8 (32 bit ddraw7) === ddraw7.c:10650: Test failed: Lock returned 0 for rect [68, 60]->[60, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 68]->[68, 60], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-8, 60]->[0, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -8]->[68, 0], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-16, 60]->[-8, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -16]->[68, -8], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[136, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[68, 136], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [136, 60]->[144, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 136]->[68, 144], type managed texture. === w864 (32 bit ddraw7) === ddraw7.c:10650: Test failed: Lock returned 0 for rect [68, 60]->[60, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 68]->[68, 60], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-8, 60]->[0, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -8]->[68, 0], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-16, 60]->[-8, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -16]->[68, -8], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[136, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[68, 136], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [136, 60]->[144, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 136]->[68, 144], type managed texture. === w1064 (32 bit ddraw7) === ddraw7.c:2254: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw7.c:10650: Test failed: Lock returned 0 for rect [68, 60]->[60, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 68]->[68, 60], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-8, 60]->[0, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -8]->[68, 0], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-16, 60]->[-8, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -16]->[68, -8], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[136, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[68, 136], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [136, 60]->[144, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 136]->[68, 144], type managed texture. === wvistau64 (64 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 000000000048753F === w2008s64 (64 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 000000000048753F === w7pro64 (64 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 000000000048753F === w864 (64 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10650: Test failed: Lock returned 0 for rect [68, 60]->[60, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 68]->[68, 60], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-8, 60]->[0, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -8]->[68, 0], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-16, 60]->[-8, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -16]->[68, -8], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[136, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[68, 136], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [136, 60]->[144, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 136]->[68, 144], type managed texture. === w1064 (64 bit ddraw7) === ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10616: Test failed: Failed to create surface, hr 0x80004002. ddraw7.c:10650: Test failed: Lock returned 0 for rect [68, 60]->[60, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 68]->[68, 60], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-8, 60]->[0, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -8]->[68, 0], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [-16, 60]->[-8, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, -16]->[68, -8], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[136, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 60]->[68, 136], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [136, 60]->[144, 68], type managed texture. ddraw7.c:10650: Test failed: Lock returned 0 for rect [60, 136]->[68, 144], type managed texture.

1 0

Re: [PATCH 6/7] wined3d: Recognize SM4 _sat instruction modifier.
by Henri Verbeet 18 Jan '16

18 Jan '16

On 18 January 2016 at 21:16, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -909,6 +919,7 @@ static void shader_sm4_read_instruction(void *data, const DWORD **ptr, struct wi > ins->handler_idx = WINED3DSIH_TABLE_SIZE; > return; > } > + priv->dst_param[i].modifiers |= instruction_dst_modifier; This is fine, although I wonder if you considered making saturation an instruction modifier on the wined3d_shader_instruction side instead?

2 1

steam web browsing on OS X
by Theodore Dubois 18 Jan '16

18 Jan '16

Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? ~Theodore

5 15

Re: [PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter.
by Alexandre Julliard 18 Jan '16

18 Jan '16

Christopher Thielen <cthielen(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=13683 > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. You'd need to review all places where we handle that message, I don't think we've taken that behavior into account. Because of this risk, I'm afraid it will have to wait until after code freeze. -- Alexandre Julliard julliard(a)winehq.org

4 7

Re: [PATCH v3] usp10: rewrite ScriptXtoCP
by Marvin 18 Jan '16

18 Jan '16

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=19751 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH v2] usp10: rewrite ScriptXtoCP
by Huw Davies 18 Jan '16

18 Jan '16

On Fri, Jan 15, 2016 at 07:14:48AM -0600, Aric Stewart wrote: > diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c > index f0bbafe..f6bfcbf 100644 > --- a/dlls/usp10/usp10.c > +++ b/dlls/usp10/usp10.c > + > +/* > + To handle multi-glyph clusters we need to find all the glyphs that are > + represented in the cluster. This involves finding the glyph whose > + index is the cluster index as well as whose glyph indices are greater than > + our cluster index but not part of a new cluster. > + > + Then we sum all those glyphs' advances. > +*/ > +static inline int get_cluster_advance(const int* piAdvance, const SCRIPT_VISATTR *psva, const WORD *pwLogClust, int cGlyphs, int cChars, int cluster, int direction) I still think this line could do with wrapping. > HRESULT WINAPI ScriptXtoCP(int iX, > int cChars, > @@ -2587,16 +2663,10 @@ HRESULT WINAPI ScriptXtoCP(int iX, > int *piCP, > int *piTrailing) > { > - int item; > - float iPosX; > - float iLastPosX; > - int iSpecial = -1; > - int iCluster = -1; > - int clust_size = 1; > - int cjump = 0; > - int advance; > - float special_size = 0.0; > int direction = 1; > + int iPosX; > + int i; > + int glyph_index, cluster_index; > > TRACE("(%d,%d,%d,%p,%p,%p,%p,%p,%p)\n", > iX, cChars, cGlyphs, pwLogClust, psva, piAdvance, > @@ -2605,6 +2675,7 @@ HRESULT WINAPI ScriptXtoCP(int iX, > if (psa->fRTL && ! psa->fLogicalOrder) > direction = -1; > > + /* Looking for non-reversed clusters in a reversed string */ > if (direction<0) > { > int max_clust = pwLogClust[0]; > @@ -2616,14 +2687,15 @@ HRESULT WINAPI ScriptXtoCP(int iX, > return S_OK; > } > > - for (item=0; item < cChars; item++) > - if (pwLogClust[item] > max_clust) > + for (i=0; i< cChars; i++) > + if (pwLogClust[i] > max_clust) > { > ERR("We do not handle non reversed clusters properly\n"); > break; > } > } > > + /* Handle an iX < 0 */ > if (iX < 0) > { > *piCP = -1; I know most of this code was already like this, but since we're rewriting it anyway, I think it would be much clearer thus: /* Handle an iX < 0 */ if (iX < 0) { if (direction < 0) { *piCP = cChars; *piTrailing = 0; } else { *piCP = -1; *piTrailing = 1; } return S_OK; } /* Looking for non-reversed clusters in a reversed string */ if (direction < 0) { for (i=0; i< cChars; i++) if (pwLogClust[i] > max_clust) { FIXME("We do not handle non reversed clusters properly\n"); break; } } (I also changed the ERR -> FIXME). > @@ -2631,102 +2703,134 @@ HRESULT WINAPI ScriptXtoCP(int iX, > return S_OK; > } > > - iPosX = iLastPosX = 0; > + /* find the glyph_index based in iX */ > if (direction > 0) > - item = 0; > + { > + for (glyph_index = -1, iPosX = iX; iPosX >=0 && glyph_index < cGlyphs; iPosX -= piAdvance[glyph_index+1], glyph_index++) > + ; > + } > else > - item = cChars - 1; > - for (; iPosX <= iX && item < cChars && item >= 0; item+=direction) > - { > - iLastPosX = iPosX; > - if (iSpecial == -1 && > - (iCluster == -1 || > - (iCluster != -1 && > - ((direction > 0 && iCluster+clust_size <= item) || > - (direction < 0 && iCluster-clust_size >= item)) > - ) > - ) > - ) > + { > + for (glyph_index = -1, iPosX = iX; iPosX > 0 && glyph_index < cGlyphs; iPosX -= piAdvance[glyph_index+1], glyph_index++) > + ; > + } > + > + TRACE("iPosX %i -> glyph_index %i (%i)\n", iPosX, glyph_index, cGlyphs); > + > + *piTrailing = 0; > + if (glyph_index >= 0 && glyph_index < cGlyphs) > + { > + /* find the cluster */ > + if (direction > 0 ) > + for (i = 0, cluster_index = pwLogClust[0]; i < cChars && pwLogClust[i] <= glyph_index; cluster_index=pwLogClust[i++]) > + ; > + else > + for (i = 0, cluster_index = pwLogClust[0]; i < cChars && pwLogClust[i] >= glyph_index; cluster_index=pwLogClust[i++]) > + ; > + > + TRACE("cluster_index %i\n", cluster_index); > + > + if (direction < 0 && iPosX >= 0 && glyph_index != cluster_index) > { > - int check; > - int clust = pwLogClust[item]; > + /* We are off the end of the string */ > + *piCP = -1; > + *piTrailing = 1; > + return S_OK; > + } > > - iCluster = -1; > - cjump = 0; > - clust_size = get_cluster_size(pwLogClust, cChars, item, direction, > - &iCluster, &check); > - advance = get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, clust, direction); > + /* find the first character of the cluster */ > + for (i = 0; i < cChars && pwLogClust[i] != cluster_index; i++) > + ; I'm wondering whether instead of the above loop, you could modify get_cluster_charsize() to return the start char as well as the size. Then you'd call it here and wouldn't need to call it later on (in the else block below). That would save an extra loop through the string. > > - if (check >= cChars && direction > 0) > - { > - int glyph; > - for (glyph = clust; glyph < cGlyphs; glyph++) > - special_size += get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, glyph, direction); > - iSpecial = item; > - special_size /= (cChars - item); > - iPosX += special_size; > - } > - else > + TRACE("first char index %i\n",i); > + if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + { > + /* Check trailing */ > + if (glyph_index != cluster_index || > + (direction > 0 && abs(iPosX) <= (piAdvance[glyph_index] / 2)) || > + (direction < 0 && abs(iPosX) >= (piAdvance[glyph_index] / 2))) > + *piTrailing = get_cluster_charsize(pwLogClust,cChars,cluster_index); > + } > + else > + { > + int cluster_size; > + > + cluster_size = get_cluster_charsize(pwLogClust, cChars, cluster_index); > + > + if (cluster_size > 1) > { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + /* Be part way through the glyph cluster based on size and position */ > + int cluster_advance = get_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, cluster_index, direction); > + double cluster_part_width = cluster_advance / (float)cluster_size; > + double adv; > + int part_index; > + > + /* back up to the beginning of the cluster */ > + for (adv = iPosX, part_index = cluster_index; part_index <= glyph_index; part_index++) > + adv += piAdvance[part_index]; > + if (adv > iX) adv = iX; > + > + TRACE("Multi-char cluster, no snap\n"); > + TRACE("cluster size %i, pre-cluster iPosX %f\n",cluster_size, adv); > + TRACE("advance %i divides into %f per char\n", cluster_advance, cluster_part_width); > + if (direction > 0) > { > - if (!cjump) > - iPosX += advance; > - cjump++; > + for (part_index = 0; adv >= 0; adv-=cluster_part_width, part_index++) > + ; > + if (part_index) part_index--; > } > else > - iPosX += advance / (float)clust_size; > + { > + for (part_index = 0; adv > 0; adv-=cluster_part_width, part_index++) > + ; > + if (part_index > cluster_size) > + { > + adv += cluster_part_width; > + part_index=cluster_size; > + } > + } > + > + TRACE("base_char %i part_index %i, leftover advance %f\n",i, part_index, adv); > + > + if (direction > 0) > + i += part_index; > + else > + i += (cluster_size - part_index); > + > + /* Check trailing */ > + if ((direction > 0 && fabs(adv) <= (cluster_part_width / 2.0)) || > + (direction < 0 && adv && fabs(adv) >= (cluster_part_width / 2.0))) > + *piTrailing = 1; > } > - } > - else if (iSpecial != -1) > - iPosX += special_size; > - else /* (iCluster != -1) */ > - { > - int adv = get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, pwLogClust[iCluster], direction); > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + else > { > - if (!cjump) > - iPosX += adv; > - cjump++; > + /* Check trailing */ > + if ((direction > 0 && abs(iPosX) <= (piAdvance[glyph_index] / 2)) || > + (direction < 0 && abs(iPosX) >= (piAdvance[glyph_index] / 2))) > + *piTrailing = 1; > } > - else > - iPosX += adv / (float)clust_size; > - } > - } > - > - if (direction > 0) > - { > - if (iPosX > iX) > - item--; > - if (item < cChars && ((iPosX - iLastPosX) / 2.0) + iX >= iPosX) > - { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo && clust_size > 1) > - item+=(clust_size-1); > - *piTrailing = 1; > } > - else > - *piTrailing = 0; > } > else > { > - if (iX == iLastPosX) > - item++; > - if (iX >= iLastPosX && iX <= iPosX) > - item++; > + TRACE("Point falls outside of string\n"); > + if (glyph_index < 0) > + i = cChars-1; > + else /* (glyph_index >= cGlyphs) */ > + i = cChars; > > - if (iLastPosX == iX) > - *piTrailing = 0; > - else if (item < 0 || ((iLastPosX - iPosX) / 2.0) + iX <= iLastPosX) > + /* If not snaping in the reverse direction (such as Hebrew) Then 0 > + point flow to the next character */ > + if (direction < 0) > { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo && clust_size > 1) > - item-=(clust_size-1); > - *piTrailing = 1; > + if (!scriptInformation[psa->eScript].props.fNeedsCaretInfo && abs(iPosX) == piAdvance[glyph_index]) > + i++; > + else > + *piTrailing = 1; > } > - else > - *piTrailing = 0; > } > > - *piCP = item; > + *piCP = i; > > TRACE("*piCP=%d\n", *piCP); > TRACE("*piTrailing=%d\n", *piTrailing); > >

2 1

Re: bcrypt: Ensure we have gnutls_hash() available.
by Sebastian Lackner 18 Jan '16

18 Jan '16

On 18.01.2016 12:41, Huw Davies wrote: > Fixes compile failures with older versions of gnutls. > > Signed-off-by: Huw Davies <huw(a)codeweavers.com> > --- > configure.ac | 1 + > dlls/bcrypt/bcrypt_main.c | 10 +++++----- > 2 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 0766edf..0eedf43 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1270,6 +1270,7 @@ then > #include <gnutls/crypto.h>]], [[static typeof(gnutls_mac_get_key_size) *func; if (func) return 0;]])], > [WINE_CHECK_SONAME(gnutls,gnutls_global_init,,[GNUTLS_CFLAGS=""],[$GNUTLS_LIBS],[[libgnutls\$-deb0\$\\{0,1\\}]])])], > [GNUTLS_CFLAGS=""])]) > + WINE_CHECK_LIB_FUNCS(gnutls_hash,[$GNUTLS_LIBS]) > fi > WINE_WARNING_WITH(gnutls,[test "x$ac_cv_lib_soname_gnutls" = "x"], > [libgnutls ${notice_platform}development files not found, no schannel support.]) Wouldn't it be useful to warn a bit more explicit at compile-time? Otherwise packagers will have a hard time to find out if its supported by their build.

2 2

Re: shell32/tests: Model the okChildXxx() shlexec macros after the standard ok() macro.
by Marvin 18 Jan '16

18 Jan '16

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=19704 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:141: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtE2DF.tmp\test file.noassoc.shlexec") WaitForSingleObject returned 258 shlexec.c:1576: Test failed: argvA3 expected 'QuotedUpperL', got 'Open' shlexec.c:1584: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtE2DF.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtE2DF.tmp\test file.noassoc.shlexec' === w1064 (32 bit shlexec) === shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt11AE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt11AE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt11AE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt11AE.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2311: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde")]' shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtC4FE.tmp\test file.sde") failed: rc=29 err=2

2 1

Re: shell32/tests: Use the shell_execute{_ex}() call site for its traces and error messages.
by Marvin 18 Jan '16

18 Jan '16

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=19743 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2311: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde")]' shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt25AF.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt9B02.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt9B02.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt9B02.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2299: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt9B02.tmp\test file.sde") failed: rc=29 err=2

2 1

Re: [PATCH] comctl32/trackbar: Update thumb immediately on key press (try 2)
by Nikolay Sivov 18 Jan '16

18 Jan '16

On 18.01.2016 11:43, Alistair Leslie-Hughes wrote: > From: Nikolay Sivov <nsivov(a)codeweavers.com> > > Changed the key press to use VK_END, since moving one value may not > change the thumb position on screen. > That makes sense, thanks.

1 0

compile wine problem
by SMLR 17 Jan '16

17 Jan '16

configure: WARNING: gst/gstpad.h: present but cannot be compiled configure: WARNING: gst/gstpad.h: check for missing prerequisite headers? configure: WARNING: gst/gstpad.h: see the Autoconf documentation configure: WARNING: gst/gstpad.h: section "Present But Cannot Be Compiled" configure: WARNING: gst/gstpad.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## help solve the problem. if you need any of the files - write and I will send them.

3 2

Re: [2/2] kernel32: add tests for GetSystemPreferredUILanguages (try2)
by Marvin 17 Jan '16

17 Jan '16

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=19735 Your paranoid android. === w1064 (32 bit locale) === locale.c:2339: Test failed: LCMapStringEx should fail with bad locale name locale.c:2340: Test failed: unexpected error code -559038737 locale.c:2431: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4154: Test failed: IsValidLocaleName should have failed locale.c:4156: Test failed: IsValidLocaleName should have failed locale.c:4521: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4523: Test failed: For id 7, Expected IVC, got ''

1 0

Re: user32: add DisplayConfigGetDeviceInfo stub
by Alexandre Julliard 17 Jan '16

17 Jan '16

Austin English <austinenglish(a)gmail.com> writes: > diff --git a/include/winuser.h b/include/winuser.h > index 50821f4..189953b 100644 > --- a/include/winuser.h > +++ b/include/winuser.h > @@ -30,6 +30,7 @@ > #endif > #include <winuser.rh> > > +#include <wingdi.h> You can't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] mpr: Implement WNetUseConnectionA(). (resend)
by Nikolay Sivov 16 Jan '16

16 Jan '16

On 16.01.2016 12:19, Pierre Schweitzer wrote: > This just implements WNetUseConnectionA() by forwarding it to > WNetUseConnectionW() using appropriate conversions when required. > > > +static PWSTR convert_stringa_to_w( LPCSTR strA ) > +{ > + int len; > + PWSTR strW; > + > + if (!strA) > + return NULL; > + > + len = MultiByteToWideChar(CP_ACP, 0, strA, -1, NULL, 0); > + if (!len) > + return NULL; > + > + strW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!strW) > + return NULL; > + > + if (MultiByteToWideChar(CP_ACP, 0, strA, len, strW, len)) > + return strW; > + > + HeapFree(GetProcessHeap(), 0, strW); > + return NULL; > +} Second mbtowc is wrong - you're using 'len' as strA length, and it should be -1 like on first call. Also it's safe to assume that second call never fails it first one returned non-zero length. Take a look how it's done it more compact way in various dlls, search for strdupWtoA names (and probably for mpr.dll it should use similar name for consistency).

1 0

Re: USER32: Remove unused variables xoffset, yoffset in SCROLL_TrackScrollBar
by Carlo Bramini 16 Jan '16

16 Jan '16

Hi, thank you very much for your courtesy! I do not know why the bits changed... I remember that I modified the source with Pelles C and not with a native editor, perhaps it could have some connections with that. Sincerely, Carlo Bramini. >----Messaggio originale---- >Da: Nikolay Sivov <bunglehead(a)gmail.com> >Data: 16/01/2016 13.16 >A: <wine-devel(a)winehq.org> >Cc: <carlo.bramix(a)libero.it> >Ogg: Re: USER32: Remove unused variables xoffset, yoffset in SCROLL_TrackScrollBar > >On 16.01.2016 14:07, Carlo Bramini wrote: >> Hi dear friends, >> I'm replying here because I have not understood the assigned status as >> "Formatting" to the attached patch. >> Thank you very much for your time. > >Hi, Carlo. > >In your original patch you had this: > >--- >diff --git a/dlls/user32/scroll.c b/dlls/user32/scroll.c >old mode 100644 >new mode 100755 >--- > >so scroll.c file was given exec bit for some reason, I don't know how >that happened, but it did happen on your side, and git picked that change. > >Next problem is missing Signed-of-by signature, you should have it for >all patches you send to wine-patches. No need to manually do so every >time, just configure git to include it automatically. > >At the end what happened is that I re-submitted your patch with those >things fixed under your name and mine. > >> >> Sincerely, >> >> Carlo Bramini. >> >>> ----Messaggio originale---- >>> Da: Marvin <testbot(a)winehq.org> >>> Data: 11/01/2016 15.22 >>> A: "Carlo Bramini"<carlo.bramix(a)libero.it> >>> Ogg: Re: USER32: Remove unused variables xoffset, yoffset in >> SCROLL_TrackScrollBar >>> >>> Thank you for your contribution to Wine! >>> >>> This is an automated notification to let you know that your patch has >>> been reviewed and its status set to "Formatting". >>> >>> This means that there are some formatting issues with your >>> patch. Either the author's full name, email address, or Signed-off-by >>> headers are missing, indentation is messed up (usually from editing >>> with a non-standard tab size), or there are gratuitous formatting >>> changes to the code. You need to resend a fixed patch. >>> >>> If you do not understand the reason for this status, disagree with our >>> assessment, or are simply not sure how to proceed next, please ask for >>> clarification by replying to this email. >> >> >> >> > >

1 0

Re: USER32: Remove unused variables xoffset, yoffset in SCROLL_TrackScrollBar
by Carlo Bramini 16 Jan '16

16 Jan '16

Hi dear friends, I'm replying here because I have not understood the assigned status as "Formatting" to the attached patch. Thank you very much for your time. Sincerely, Carlo Bramini. >----Messaggio originale---- >Da: Marvin <testbot(a)winehq.org> >Data: 11/01/2016 15.22 >A: "Carlo Bramini"<carlo.bramix(a)libero.it> >Ogg: Re: USER32: Remove unused variables xoffset, yoffset in SCROLL_TrackScrollBar > >Thank you for your contribution to Wine! > >This is an automated notification to let you know that your patch has >been reviewed and its status set to "Formatting". > >This means that there are some formatting issues with your >patch. Either the author's full name, email address, or Signed-off-by >headers are missing, indentation is messed up (usually from editing >with a non-standard tab size), or there are gratuitous formatting >changes to the code. You need to resend a fixed patch. > >If you do not understand the reason for this status, disagree with our >assessment, or are simply not sure how to proceed next, please ask for >clarification by replying to this email.

2 1

Re: [PATCH 1/1] d3drm/tests: Add texture loading tests.
by Aaryaman Vasishta 15 Jan '16

15 Jan '16

On Fri, Jan 15, 2016 at 5:25 PM, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > + for (i = 0; i < img->palette_size; ++i) > + { > + unsigned int idx = upside_down ? (h - 1) * w - i + (i % w) * > 2 : > How did you come up with that equation? Would be nice to know :) > > + > + hr = IDirect3DRM_LoadTexture(d3drm1, filename, &texture1); > + ok(SUCCEEDED(hr), "Test %u: Failed to load texture, hr %#x.\n", > i, hr); > + d3drm_img = IDirect3DRMTexture_GetImage(texture1); > + todo_wine ok(!!d3drm_img, "Test %u: Failed to get image.\n", i); > Why the '!!' ? How's that better than using a single negation? Other than all that, I've mostly understood the changes you made. Patch looks great :) I'll reply if I have any more queries on the same. Cheers, Aaryaman

2 1

Re: [PATCH] ddraw: Fix use of uninitialized memory.
by Stefan Dösinger 15 Jan '16

15 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-14 um 20:49 schrieb Thomas Faller: > + if ((desc->dwFlags & DDSD_LPSURFACE) > + && ((desc->ddsCaps.dwCaps & DDSCAPS_ALLOCONLOAD) || !desc->lpSurface)) > desc->dwFlags &= ~DDSD_LPSURFACE; I'd say report this to valgrind as well. If DDSD_LPSURFACE isn't set in the first place then randomly unsetting it doesn't really hurt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWmBWcAAoJEN0/YqbEcdMwuuoP/R/psF/dtrnIb0tQH/JP9Ikg kbDNd1NUuwx8QEOKNevopq/ii24whN0VpgJRSKMslY3PvSH6WnWDq9VT3PxSECsc dhfESXJBPSHDfuyzRhVrtwNQvwKrotpUXQ1bIW3AKKsJRr8yOxS3QkYMbt9zMItO YMqy1MP1315Kp6o51LW3iMANipqpmSUfTIjPWrHj7nMKgNTcTbrqOpGHKezxw1u7 ox10hCEwVj5429drUej/Q/nQ1OoAluWAdH0hWZhAF4zi5O+1wwH7I+KwqbL6a/zK 7djvDv+V3EeHxuax3ljwtMoa6Vxwna1vpGSCTHN8N/gNZcFR5v2ne+i+rkGoFQ3V 8u5Lhb1CMaAsTrzBnw+jX2JKSsbpgzFO8nVlDEr2G/cSvf/wq1DaNRpjmFMCExYP 0fs1PzHf4jBubqVChycSbCT1AGEq29s2msn6ucomoTdM1kctRFKjoxPk76iJKE86 mSWBkcmjRSaDBuHt76xjpL9NPEO3CO6lJbtLslEo33kCbsdrv8i+AVGBBvWMf9Oj /bVieoGqk5djdi0bggrhspKGCsVZURYrfpgFv/FIq66Vs7SzEgZoXABoPkjugwtB DLPF2s1WjUqAq0CYWzgLOprvbFI2DPz/VtbaBoJ0GYr3bZJca+ZV8njXsQUMi52b PtFvXa2A4KJOm18CrCm4 =gjon -----END PGP SIGNATURE-----

3 2

Re: shell32/tests: Arrange for the shell_execute{_ex}() calls to set the test line.
by Alexandre Julliard 15 Jan '16

15 Jan '16

Francois Gouget <fgouget(a)codeweavers.com> writes: > This makes it possible to attribute their internal test results to the relevant test_xxx() function. > This implies that they must not make calls that would reset the test line. This is fragile. It would be better to explicitly pass the line number, like most other tests do. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH v2 2/5] wined3d: Recognize SM4 resinfo opcode.
by Henri Verbeet 15 Jan '16

15 Jan '16

On 14 January 2016 at 12:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +#define WINED3D_SM4_OPCODESPECIFICCONTROL_SHIFT 11 > +#define WINED3D_SM4_OPCODESPECIFICCONTROL_MASK (0x3u << WINED3D_SM4_OPCODESPECIFICCONTROL_SHIFT) > + I guess the naming derives from shader_sm1.c, but I think I'd prefer something like WINED3D_SM4_INSTRUCTION_FLAGS_MASK. The shader_sm1.c naming for the various masks and shifts is inconsistent in general, I'd like to clean it up to be more like shader_sm4.c at some point. I suspect the mask is actually at least 0xfu (because of WINED3D_SM4_RESOURCE_TYPE_MASK), but we'll find out as soon as we run into an instruction that uses the extra bits. > ins->handler_idx = opcode_info->handler_idx; > - ins->flags = 0; > + ins->flags = (opcode_token & WINED3D_SM4_OPCODESPECIFICCONTROL_MASK) >> WINED3D_SM4_OPCODESPECIFICCONTROL_SHIFT; I think it would be better to do this inside the last else-block of the function. It probably doesn't hurt to have nonsense in the flags field for DCL opcodes, but I think it's best avoided.

1 0

Re: [PATCH] d3d11.idl: Add ID3D11VideoContext interface (try 2)
by Józef Kucia 15 Jan '16

15 Jan '16

On Wed, Jan 13, 2016 at 8:08 AM, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > UINT Usage:1; It would preferably be written as "UINT Usage : 1;". This applies to other bit fields. > + void VideoProcessorSetOutputConstriction( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + BOOL Enable, > + SIZE Size); > + void VideoProcessorSetOutputStereoMode( > + [in] ID3D11VideoProcessor *pVideoProcessor, > + BOOL Enable); The Enable and Size parameters should be annotated as input parameters. Ideally, the method parameters would be renamed and written in lower_case_with_underscores.

4 5

Re: [PATCH v2] usp10: rewrite ScriptXtoCP
by Marvin 15 Jan '16

15 Jan '16

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=19719 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

1 0

Re: [PATCH] usp10: rewrite ScriptXtoCP
by Huw Davies 15 Jan '16

15 Jan '16

Hi Aric, Just some comments to keep the ball rolling on this. In general I can now at least understand the algorithm, so it's a vast improvement over the one it replaces :-) On Mon, Jan 04, 2016 at 07:52:59AM -0600, Aric Stewart wrote: > diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c > +/* Count the number of characters in a cluster */ > +static inline int get_cluster_charsize(const WORD *pwLogClust, int cChars, int index) > +{ > + int size = 0; > + int i; > + for (i = 0; i < cChars; i++) > + if (pwLogClust[i] == index) size++; > + return size; Does it make sense to break out of this loop if (size && pwLogClust[i] != index) ? > +} > + > +/* > + To handle multi-glyph clusters we need to find all the glyphs that are > + represented in by the cluster. This involves finding the glyph whose "in by" > + index is the cluster index as well as whose glyph indices are greater than > + our cluster index but not part of a new cluster. > + > + Then we sum all those glyph's advances. glyphs' > +*/ > +static inline int get_cluster_advance(const int* piAdvance, const SCRIPT_VISATTR *psva, const WORD *pwLogClust, int cGlyphs, int cChars, int cluster, int direction) Some of these lines are getting awfully long. > +{ > + int glyph_start; > + int glyph_end; > + int i, advance; > + > + if (direction > 0) > + i = 0; > + else > + i = (cChars - 1); > + > + for (glyph_start = -1, glyph_end = -1; i < cChars && i >= 0 && (glyph_start < 0 || glyph_end < 0); i+=direction) > + { > + if (glyph_start < 0 && pwLogClust[i] != cluster) continue; > + if (pwLogClust[i] == cluster && glyph_start < 0) glyph_start = pwLogClust[i]; > + if (glyph_start >= 0 && glyph_end < 0 && pwLogClust[i] != cluster) glyph_end = pwLogClust[i]; > + } > + if (glyph_end < 0) > + { > + if (direction > 0) > + glyph_end = cGlyphs; > + else /* Don't understand multi-glyph reversed clusters yet, do they occur for real? */ Should we add a FIXME for this? > + glyph_end = glyph_start + 1; > + } > + > + /* Check for fClusterStart, finding this generally would mean a malformed set of data */ > + for (i = glyph_start+1; i< glyph_end; i++) > + { > + if (psva[i].fClusterStart) > + { > + glyph_end = i; > + break; > + } > + } > + > + for ( advance = 0, i = glyph_start; i < glyph_end; i++) Odd leading space before advance. > + advance += piAdvance[i]; > + > + return advance; > +} > + > + > /*********************************************************************** > * ScriptXtoCP (USP10.@) > * > + * Basic algorithm : > + * use piAdvance to find the cluster we are looking at > + * Find the character that is the first character of the cluster > + * That is our base piCP > + * If the script snaps to cluster boundries (Hebrew, Indic, Thai) then we are good > + * Otherwise if the cluster is larger than 1 glyph we need to determin how far through the cluster determine. > + * to advance the cursor. > */ > HRESULT WINAPI ScriptXtoCP(int iX, > int cChars, > @@ -2587,16 +2655,10 @@ HRESULT WINAPI ScriptXtoCP(int iX, > int *piCP, > int *piTrailing) > { > - int item; > - float iPosX; > - float iLastPosX; > - int iSpecial = -1; > - int iCluster = -1; > - int clust_size = 1; > - int cjump = 0; > - int advance; > - float special_size = 0.0; > int direction = 1; > + int iPosX; > + int i; > + int glyph_index, cluster_index; > > TRACE("(%d,%d,%d,%p,%p,%p,%p,%p,%p)\n", > iX, cChars, cGlyphs, pwLogClust, psva, piAdvance, > @@ -2605,6 +2667,7 @@ HRESULT WINAPI ScriptXtoCP(int iX, > if (psa->fRTL && ! psa->fLogicalOrder) > direction = -1; > > + /* Looking for non-reversed clusters in a reversed string */ > if (direction<0) > { > int max_clust = pwLogClust[0]; > @@ -2616,14 +2679,15 @@ HRESULT WINAPI ScriptXtoCP(int iX, > return S_OK; > } > > - for (item=0; item < cChars; item++) > - if (pwLogClust[item] > max_clust) > + for (i=0; i< cChars; i++) > + if (pwLogClust[i] > max_clust) > { > ERR("We do not handle non reversed clusters properly\n"); > break; > } > } > > + /* Handle an iX < 0 */ > if (iX < 0) > { > *piCP = -1; > @@ -2631,102 +2695,134 @@ HRESULT WINAPI ScriptXtoCP(int iX, > return S_OK; > } > > - iPosX = iLastPosX = 0; > + /* find the glyph_index based in iX */ > if (direction > 0) > - item = 0; > + { > + for (glyph_index = -1, iPosX = iX; iPosX >=0 && glyph_index < cGlyphs; iPosX -= piAdvance[glyph_index+1], glyph_index++) > + ; > + } > else > - item = cChars - 1; > - for (; iPosX <= iX && item < cChars && item >= 0; item+=direction) > - { > - iLastPosX = iPosX; > - if (iSpecial == -1 && > - (iCluster == -1 || > - (iCluster != -1 && > - ((direction > 0 && iCluster+clust_size <= item) || > - (direction < 0 && iCluster-clust_size >= item)) > - ) > - ) > - ) > + { > + for (glyph_index = -1, iPosX = iX; iPosX > 0 && glyph_index < cGlyphs; iPosX -= piAdvance[glyph_index+1], glyph_index++) > + ; > + } > + > + TRACE("iPosX %i -> glyph_index %i (%i)\n", iPosX, glyph_index, cGlyphs); > + > + *piTrailing = 0; > + if (glyph_index >= 0 && glyph_index < cGlyphs) > + { > + /* find the cluster */ > + if (direction > 0 ) > + for (i = 0, cluster_index = pwLogClust[0]; i < cChars && pwLogClust[i] <= glyph_index; cluster_index=pwLogClust[i++]) > + ; > + else > + for (i = 0, cluster_index = pwLogClust[0]; i < cChars && pwLogClust[i] >= glyph_index; cluster_index=pwLogClust[i++]) > + ; > + > + TRACE("cluster_index %i\n", cluster_index); > + > + if (direction < 0 && iPosX >= 0 && glyph_index != cluster_index) > { > - int check; > - int clust = pwLogClust[item]; > + /* We are off the end of the string */ > + *piCP = -1; > + *piTrailing = 1; > + return S_OK; > + } > > - iCluster = -1; > - cjump = 0; > - clust_size = get_cluster_size(pwLogClust, cChars, item, direction, > - &iCluster, &check); > - advance = get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, clust, direction); > + /* find the first character of the cluster */ > + for (i = 0; i < cChars && pwLogClust[i] != cluster_index; i++) > + ; > > - if (check >= cChars && direction > 0) > - { > - int glyph; > - for (glyph = clust; glyph < cGlyphs; glyph++) > - special_size += get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, glyph, direction); > - iSpecial = item; > - special_size /= (cChars - item); > - iPosX += special_size; > - } > - else > + TRACE("first char index %i\n",i); > + if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + { > + /* Check trailing */ > + if (glyph_index != cluster_index || > + (direction > 0 && abs(iPosX) <= (piAdvance[glyph_index] / 2)) || > + (direction < 0 && abs(iPosX) >= (piAdvance[glyph_index] / 2))) > + *piTrailing = get_cluster_charsize(pwLogClust,cChars,cluster_index); > + } > + else > + { > + int cluster_size; > + > + cluster_size = get_cluster_charsize(pwLogClust, cChars, cluster_index); > + > + if (cluster_size > 1) > { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + /* Be part way through the glyph cluster based on size and position */ > + int cluster_advance = get_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, cluster_index, direction); > + double cluster_part_width = cluster_advance / (float)cluster_size; > + double adv; > + int part_index; > + > + /* back up to the beginning of the cluster */ > + for (adv = iPosX, part_index = cluster_index; part_index <= glyph_index; part_index++) > + adv += piAdvance[part_index]; > + if (adv > iX) adv = iX; > + > + TRACE("Multi-char cluster, no snap\n"); > + TRACE("cluster size %i, pre-cluster iPosX %f\n",cluster_size, adv); > + TRACE("advance %i divides into %f per char\n", cluster_advance, cluster_part_width); > + if (direction > 0) > { > - if (!cjump) > - iPosX += advance; > - cjump++; > + for (part_index = 0; adv >= 0; adv-=cluster_part_width, part_index++) > + ; > + if (part_index) part_index--; > } > else > - iPosX += advance / (float)clust_size; > + { > + for (part_index = 0; adv > 0; adv-=cluster_part_width, part_index++) > + ; > + if (part_index > cluster_size) > + { > + adv += cluster_part_width; > + part_index=cluster_size; > + } > + } > + > + TRACE("base_char %i part_index %i, leftover advance %f\n",i, part_index, adv); > + > + if (direction > 0) > + i += part_index; > + else > + i += (cluster_size - part_index); > + > + /* Check trailing */ > + if ((direction > 0 && fabs(adv) <= (cluster_part_width / 2.0)) || > + (direction < 0 && adv && fabs(adv) >= (cluster_part_width / 2.0))) > + *piTrailing = 1; > } > - } > - else if (iSpecial != -1) > - iPosX += special_size; > - else /* (iCluster != -1) */ > - { > - int adv = get_glyph_cluster_advance(piAdvance, psva, pwLogClust, cGlyphs, cChars, pwLogClust[iCluster], direction); > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo) > + else > { > - if (!cjump) > - iPosX += adv; > - cjump++; > + /* Check trailing */ > + if ((direction > 0 && abs(iPosX) <= (piAdvance[glyph_index] / 2)) || > + (direction < 0 && abs(iPosX) >= (piAdvance[glyph_index] / 2))) > + *piTrailing = 1; > } > - else > - iPosX += adv / (float)clust_size; > } > } > - > - if (direction > 0) > - { > - if (iPosX > iX) > - item--; > - if (item < cChars && ((iPosX - iLastPosX) / 2.0) + iX >= iPosX) > - { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo && clust_size > 1) > - item+=(clust_size-1); > - *piTrailing = 1; > - } > - else > - *piTrailing = 0; > - } > else > { > - if (iX == iLastPosX) > - item++; > - if (iX >= iLastPosX && iX <= iPosX) > - item++; > + TRACE("Point falls outside of string\n"); > + if (glyph_index < 0) > + i = cChars-1; > + else /* (glyph_index >= cGlyphs) */ > + i = cChars; > > - if (iLastPosX == iX) > - *piTrailing = 0; > - else if (item < 0 || ((iLastPosX - iPosX) / 2.0) + iX <= iLastPosX) > + /* If not snaping in the reverse direction (such as Hebrew) Then 0 > + point flow to the next character */ > + if (direction < 0) > { > - if (scriptInformation[psa->eScript].props.fNeedsCaretInfo && clust_size > 1) > - item-=(clust_size-1); > - *piTrailing = 1; > + if (!scriptInformation[psa->eScript].props.fNeedsCaretInfo && abs(iPosX) == piAdvance[glyph_index]) > + i++; > + else > + *piTrailing = 1; > } > - else > - *piTrailing = 0; > } > > - *piCP = item; > + *piCP = i; > > TRACE("*piCP=%d\n", *piCP); > TRACE("*piTrailing=%d\n", *piTrailing); > >

2 1

Re: [v4 1/2] ole32: OleGetClipboard(): zero output interface pointer on error ole32/tests: OleGetClipboard fails on locked clipboard; out iface ptr is zeroed
by Huw Davies 15 Jan '16

15 Jan '16

On Fri, Jan 15, 2016 at 02:33:07PM +0300, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/clipboard.c | 1 + > dlls/ole32/tests/clipboard.c | 20 ++++++++++++++++++++ > 2 files changed, 21 insertions(+) One more thing (sorry, I should have noticed earlier), in the subject don't add a second bit referring to the tests. For this patch something like: ole32: OleGetClipboard(): zero output interface pointer on error. will be fine. While you're at it, replace the word 'natively' with 'should' in the second patch's subject. Thanks, Huw.

1 0

Re: [PATCH v2] ole32/tests: OleGetClipboard natively succeeds when COM/OLE is not inited
by Huw Davies 15 Jan '16

15 Jan '16

On Fri, Jan 15, 2016 at 01:56:29PM +0300, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/tests/clipboard.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c > index 02097ea..c6ef736 100644 > --- a/dlls/ole32/tests/clipboard.c > +++ b/dlls/ole32/tests/clipboard.c > @@ -455,6 +455,17 @@ static HRESULT DataObjectImpl_CreateComplex(LPDATAOBJECT *lplpdataobj) > return S_OK; > } > > +static void test_get_clipboard_unitialized(void) > +{ > + HRESULT hr; > + IDataObject *pDObj; > + > + pDObj = (IDataObject *)0xdeadbeef; > + hr = OleGetClipboard(&pDObj); > + todo_wine ok(hr == S_OK, "OleGetClipboard() got 0x%08x instead of 0x%08x\n", hr, S_OK); > + if (pDObj && pDObj != (IDataObject *)0xdeadbeef) IUnknown_Release((IUnknown*)pDObj); Use IDataObject_Release to avoid a cast. Huw.

1 0

Re: [PATCH 2/2] dnsapi: DnsQueryEx partial implementation (ver.3)
by Hans Leidekker 15 Jan '16

15 Jan '16

On Fri, 2016-01-15 at 11:35 +0300, Donat Enikeev wrote: >+ TRACE("DNS address to use %hhu.%hhu.%hhu.%hhu (%u) \n", >+ p_sockaddr->sin_addr.WS_s_impno, p_sockaddr->sin_addr.WS_s_lh, >+ p_sockaddr->sin_addr.WS_s_host, p_sockaddr->sin_addr.WS_s_net, p_sockaddr->sin_addr.WS_s_addr); %hhu is not needed here (and would not be allowed in Wine because it's a C99 feature). You can use %u.

1 0

Re: [PATCH v3] ole32: OleGetClipboard(): zero output interface pointer on error ole32/tests: OleGetClipboard fails on locked
by Marvin 15 Jan '16

15 Jan '16

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=19708 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] ole32/tests: OleGetClipboard natively succeeds when COM/OLE is not inited
by Huw Davies 15 Jan '16

15 Jan '16

On Thu, Jan 14, 2016 at 01:49:39PM +0300, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/tests/clipboard.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c > index 83994f3..48ca891 100644 > --- a/dlls/ole32/tests/clipboard.c > +++ b/dlls/ole32/tests/clipboard.c > @@ -455,6 +455,17 @@ static HRESULT DataObjectImpl_CreateComplex(LPDATAOBJECT *lplpdataobj) > return S_OK; > } > > +static void test_get_clipboard_unitialized() You're missing a 'void'. clipboard.c:1574:13: warning: function declaration isn’t a prototype > +{ > + HRESULT hr; > + IDataObject *pDObj; > + > + pDObj = (IDataObject *)0xdeadbeef; > + hr = OleGetClipboard(&pDObj); > + todo_wine ok(hr == S_OK, "OleGetClipboard() got 0x%08x instead of 0x%08x\n", hr, S_OK); > + if (pDObj && pDObj != (IDataObject *)0xdeadbeef) IUnknown_Release((IUnknown*)pDObj); > +} > + > static void test_get_clipboard(void) > { > HRESULT hr; > @@ -1592,6 +1603,7 @@ static void test_get_clipboard_locked() > > START_TEST(clipboard) > { > + test_get_clipboard_unitialized(); > test_set_clipboard(); > test_consumer_refs(); > test_flushed_getdata(); > -- > 2.5.0 > > >

1 0

Re: [PATCH v2] ole32: better match native behaviour in OLE init/uninit ole32/tests: check COM/OLE init state after mixed COM/OLE init/uninit
by Huw Davies 15 Jan '16

15 Jan '16

On Wed, Jan 13, 2016 at 01:16:42PM +0300, Paul Gofman wrote: > Native OleUnitialize never uninits apartment inited by CoInitializeEx. > CoUnitialize after OleInitialize uninits apartment, but Ole is still considered > inited. > > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/compobj.c | 2 ++ > dlls/ole32/ole2.c | 7 +++++ > dlls/ole32/tests/compobj.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 79 insertions(+) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index 90b049a..78fc30d 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -1972,6 +1972,8 @@ void WINAPI DECLSPEC_HOTPATCH CoUninitialize(void) > > if (!--info->inits) > { > + if (info->ole_inits) > + ERR("uninitializing apartment while Ole is still initialized\n"); This should be a WARN since it's likely to be an application, not a Wine, error. > apartment_release(info->apt); > info->apt = NULL; > } > diff --git a/dlls/ole32/ole2.c b/dlls/ole32/ole2.c > index 7929d3d..f078fb6 100644 > --- a/dlls/ole32/ole2.c > +++ b/dlls/ole32/ole2.c > @@ -186,6 +186,8 @@ HRESULT WINAPI DECLSPEC_HOTPATCH OleInitialize(LPVOID reserved) > > if (!COM_CurrentInfo()->ole_inits) > hr = S_OK; > + else > + hr = S_FALSE; > > /* > * Then, it has to initialize the OLE specific modules. > @@ -229,6 +231,11 @@ void WINAPI DECLSPEC_HOTPATCH OleUninitialize(void) > { > TRACE("()\n"); > > + if (COM_CurrentInfo()->ole_inits == 0) > + { > + WARN("ole_inits is already 0\n"); > + return ; > + } > /* > * If we hit the bottom of the lock stack, free the libraries. > */ > diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c > index 5fe9876..3ee5470 100644 > --- a/dlls/ole32/tests/compobj.c > +++ b/dlls/ole32/tests/compobj.c > @@ -2181,6 +2181,75 @@ static void test_CoInitializeEx(void) > OleUninitialize(); > } > > +static void test_OleInitialize_InitCounting(void) > +{ > + HRESULT hr; > + HANDLE thread; > + IUnknown *pUnk; > + REFCLSID rclsid = &CLSID_InternetZoneManager; > + IDataObject *pDObj; compobj.c: In function ‘test_OleInitialize_InitCounting’: compobj.c:2190: warning: unused variable ‘pDObj’ compobj.c:2187: warning: unused variable ‘thread’

2 1

Re: [PATCH 2/2] ntdll: Make avail_mode always TRUE for serial ports.
by Alexandre Julliard 15 Jan '16

15 Jan '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Cc: Eric Pouech <eric.pouech(a)orange.fr> > Cc: Sebastian Lackner <sebastian(a)fds-team.de> > > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > avail_mode controls whether a read operation is considered a success as > long as at least one byte can be read, or whether the operation is > considered pending until the total number of requested bytes has been > received. For serial ports, avail_mode was TRUE if read operations > always finished immediately, and FALSE if read operations did not finish > until data was available or the request timed out.[1] However, whether > or not a zero-byte read is considered a success has nothing to do with > whether or not a one-byte read is considered a success. > > Since serial ports are essentially hardware-based pipes, it makes sense > that they behave the same as software pipes and sockets. Pipes and sockets don't have comm timeouts, it's not at all obvious that they should be identical. This will need tests; at the very least a test app, if using the testbot isn't possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/3] bcrypt: Add support for SHA hashes on Linux using GnuTLS.
by Francois Gouget 15 Jan '16

15 Jan '16

FreeBSD 8.1 is getting old and it shows up in the form of this error: gcc -c -o bcrypt_main.o bcrypt_main.c -I. -I../../include -I/usr/local/include -D__WINESRC__ -D_REENTRANT \ -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes \ -Wwrite-strings -Wpointer-arith -gdwarf-2 -fno-omit-frame-pointer -I/usr/local/include -g -O2 ../../tools/wrc/wrc -o version.res --nostdinc -I. -I../../include -I/usr/local/include -D__WINESRC__ \ version.rc bcrypt_main.c:55: error: 'gnutls_hash' undeclared here (not in a function) bcrypt_main.c:55: warning: type defaults to 'int' in declaration of 'pgnutls_hash' bcrypt_main.c:56: error: 'gnutls_hash_deinit' undeclared here (not in a function) bcrypt_main.c:56: warning: type defaults to 'int' in declaration of 'pgnutls_hash_deinit' bcrypt_main.c:57: error: 'gnutls_hash_init' undeclared here (not in a function) bcrypt_main.c:57: warning: type defaults to 'int' in declaration of 'pgnutls_hash_init' bcrypt_main.c:346: error: expected specifier-qualifier-list before 'gnutls_hash_hd_t' bcrypt_main.c: In function 'hash_init': bcrypt_main.c:378: error: 'struct hash' has no member named 'handle' bcrypt_main.c:378: error: called object 'pgnutls_hash_init' is not a function bcrypt_main.c: In function 'hash_update': bcrypt_main.c:384: error: 'struct hash' has no member named 'handle' bcrypt_main.c:384: error: called object 'pgnutls_hash' is not a function bcrypt_main.c: In function 'hash_finish': bcrypt_main.c:390: error: 'struct hash' has no member named 'handle' bcrypt_main.c:390: error: called object 'pgnutls_hash_deinit' is not a function In other words its gnutls 2.8.6 library is missing the gnutls_hash_xxx() functions. So this should probably be checked in the autoconf script. This should probably be a separate check as secur32 still compiles fine with gnutls support. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.

1 0

Re: shell32/tests: Arrange for the shell_execute{_ex}() calls to set the test line.
by Marvin 15 Jan '16

15 Jan '16

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=19703 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2306: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde")]' shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtFF9.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2294: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt10F3.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: d3dx9_36: Fix a typo
by Matteo Bruni 14 Jan '16

14 Jan '16

2016-01-13 1:19 GMT+01:00 Andrey Gusev <andrey.goosev(a)gmail.com>: Hi Andrey, - TRACE("Created ID3DBuffer %p\n", *buffer); + TRACE("Created ID3DXBuffer %p\n", *buffer); While you're there, can you also add a period at the end of the message? Also please use the "d3dx9:" prefix in the commit title.

1 0

Re: [PATCH 3/3] d3dx9: Add D3DXCreateAnimationController tests (try 3)
by Nikolay Sivov 14 Jan '16

14 Jan '16

On 12.01.2016 10:34, Alistair Leslie-Hughes wrote: > +if (0) /* Windows crashes when animation is Released */ > +{ > + hr = D3DXCreateAnimationController(0, 0, 0, 0, &animation); > + ok(hr == D3D_OK, "Got unexpected hr returned %#x.\n", hr); > + animation->lpVtbl->Release(animation); > +} Is 'animation' NULL at this point by any chance?

3 2

Re: [PATCH 2/5] wined3d: Recognize SM4 resinfo opcode.
by Henri Verbeet 14 Jan '16

14 Jan '16

On 12 January 2016 at 23:51, Józef Kucia <jkucia(a)codeweavers.com> wrote: > The _uint and _rcpFloat modifiers seems to be specific to the resinfo > instruction. AFAIK, there is one other instruction, SM 4.1 sampleinfo, > which also has _uint modifier. I think it may be better to store those as instruction flags in "ins->flags", the way e.g. WINED3DSI_TEXLD_PROJECT and WINED3DSI_TEXLD_BIAS are.

1 0

Wiki is being hammered by spammers
by Rosanne DiMesio 13 Jan '16

13 Jan '16

In the past hour, I've restored the Front Page three times, and deleted over two dozen newly created spam pages. Earlier, Alexandre deleted many more spam pages. Something needs to be done now. -- Rosanne DiMesio dimesio(a)earthlink.net

9 10

Re: [PATCH] ole32: OleGetClipboard(): zero output interface pointer on error
by Nikolay Sivov 13 Jan '16

13 Jan '16

On 13.01.2016 13:23, Paul Gofman wrote: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/ole32/clipboard.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/dlls/ole32/clipboard.c b/dlls/ole32/clipboard.c > index ca9520f..b871bbc 100644 > --- a/dlls/ole32/clipboard.c > +++ b/dlls/ole32/clipboard.c > @@ -2201,6 +2201,7 @@ HRESULT WINAPI OleGetClipboard(IDataObject **obj) > TRACE("(%p)\n", obj); > > if(!obj) return E_INVALIDARG; > + *obj = NULL; > > if(FAILED(hr = get_ole_clipbrd(&clipbrd))) return hr; > Hi, Paul. This is to handle a case when OLE was not initialized, right? If so, it should be easy to add a test for it. It makes sense to zero it as a common convention for out interface pointers, but a test won't hurt.

2 4

Re: [2/4] gdi32: Fix the advance width in synthetic bold glyphs with scaling. (try 3)
by Marvin 13 Jan '16

13 Jan '16

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=19662 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: shell32/tests: Trace the effective ShellExecuteEx() flags.
by Marvin 13 Jan '16

13 Jan '16

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=19657 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:141: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec") WaitForSingleObject returned 258 shlexec.c:1570: Test failed: argvA3 expected 'Open', but key not found or empty shlexec.c:1578: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec', but key not found or empty shlexec.c:1570: Test failed: argvA3 expected 'QuotedLowerL', got 'Open' shlexec.c:1578: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.shlexec', got 'C:\Users\winetest\AppData\Local\Temp\wtDB9E.tmp\test file.noassoc.shlexec' === w1064 (32 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wt1B82.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2305: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde")]' shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x8540", file="C:\Users\winetest\AppData\Local\Temp\wtF82E.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: shell32/tests: Tweak some overly optimistic ok() messages.
by Marvin 13 Jan '16

13 Jan '16

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=19656 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2305: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde")]' shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtD923.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2293: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1102.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: regsvr32/tests: Add initial tests
by Francois Gouget 13 Jan '16

13 Jan '16

On Tue, 12 Jan 2016, Hugh McMaster wrote: [...] > diff --git a/programs/regsvr32/tests/Makefile.in b/programs/regsvr32/tests/Makefile.in > new file mode 100644 > index 0000000..61d25fe > --- /dev/null > +++ b/programs/regsvr32/tests/Makefile.in [...] > +ifneq (,$(filter crosstest mingw,$(MAKECMDGOALS) $(findstring mingw,$(CC)))) > + TARGET_DLLS = $(addsuffix .dll, $(DLL_BASENAMES)) I believe the syntax on these last two lines is specific to GNU make which is something that Wine has tried to avoid so far. Note that more generally getting a dll into this test will be pretty tricky. Would it be possible to do the tests using an existing dll? Alternatively would it work to add the test's dll to dlls/ and grab and include it as a resource in programs/regsvr32/tests? This may help avoid makefile shenanigans. > diff --git a/programs/regsvr32/tests/regsvr32.c b/programs/regsvr32/tests/regsvr32.c > new file mode 100644 > index 0000000..746c81f > --- /dev/null > +++ b/programs/regsvr32/tests/regsvr32.c [...] > +#define run_test(...) run_test_(output, &r, __VA_ARGS__) A macro with a variable argument list? That does not seem portable (or maybe is a > C99 feature). > +static BOOL __cdecl run_test_(char *output, DWORD *r, const char *fmt, ...) > +{ > + __ms_va_list va_args; Shouldn't this be using something like __winetest_va_list? To be checked... > +#define CMP(s) !strcmp(output, s) This macro is totally unnecessary. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 3

Re: [PATCH] comctl32/trackbar: Update thumb immediately on key press
by Marvin 13 Jan '16

13 Jan '16

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=19639 Your paranoid android. === wvistau64 (32 bit trackbar) === trackbar.c:682: Test failed: got 36, expected 36 === wvistau64 (64 bit trackbar) === trackbar.c:682: Test failed: got 36, expected 36

2 1

Re: [PATCH 1/2] dnsapi: migrating to res_nquery (try 2)
by Sebastian Lackner 13 Jan '16

13 Jan '16

On 12.01.2016 20:55, Donat Enikeev wrote: > @@ -597,7 +609,9 @@ static DNS_STATUS dns_do_query( PCSTR name, WORD type, DWORD options, PDNS_RECOR > > DNS_RRSET_INIT( rrset ); > > - len = res_query( name, ns_c_in, type, answer, sizeof(answer) ); > + TRACE("Performing res_nquery(%p, %s, %u, %u, %p)\n", rs, name, type, options, result); Please use debugstr_a() when tracing untrusted values of arbitrary size. > + > + len = res_nquery( rs, name, ns_c_in, type, answer, sizeof(answer) ); > if (len < 0) > { > ret = dns_map_h_errno( h_errno );

1 0

Re: [PATCH 2/2] dnsapi: DnsQueryEx partial implementation (try 2)
by Hans Leidekker 13 Jan '16

13 Jan '16

On Tue, 2016-01-12 at 22:55 +0300, Donat Enikeev wrote: This produces a warning on Mac OS: gcc -m32 -c -o query.o query.c -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 query.c:701:17: warning: format specifies type 'unsigned short' but the argument has type 'UCHAR' (aka 'unsigned char') [-Wformat] p_sockaddr->sin_addr.WS_s_impno, p_sockaddr->sin_addr.WS_s_lh, ^

1 0

Re: [PATCH 1/4] oleaut32: Add tests for safearray unmarshaling into passed variant
by Dmitry Timoshkov 13 Jan '16

13 Jan '16

Hi Piotr, Piotr Caban <piotr(a)codeweavers.com> wrote: > @@ -1316,11 +1316,19 @@ static void test_marshal_VARIANT(void) > ok(*wirev, "wv[6] %08x\n", *wirev); /* win2k: this is lpsa. winxp: this is (char*)lpsa + 1 */ > wirev++; > check_safearray(wirev, lpsa); > - VariantInit(&v2); > + mem = CoTaskMemAlloc(1024); > + lpsa_copy = lpsa2 = SafeArrayCreate(VT_I8, 1, &sab); > + CoTaskMemFree(mem); > + mem = lpsa2->pvData; > + V_VT(&v2) = VT_UI4 | VT_ARRAY | VT_BYREF; > + V_ARRAYREF(&v2) = &lpsa2; Looks like the result of CoTaskMemAlloc/CoTaskMemFree is not used. -- Dmitry.

2 3

why are WineWindows NSPanels
by Theodore Dubois 13 Jan '16

13 Jan '16

Hi, Why are WineWindows NSPanels, not NSWindows? I can see a disadvantage of this, which is that NSPanels don’t show up in Mission Control, but I can’t see the advantage. ~Theodore

2 1

Re: [PATCH 2/4] oleaut32: Set safearray pointer to NULL in LPSAFEARRAY_UserFree
by Marvin 12 Jan '16

12 Jan '16

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=19628 Your paranoid android. === w1064 (64 bit usrmarshal) === The test timed out

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel