January 2016 - Wine-devel - list.winehq.org

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