April 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] winex11.drv: Use GMEM_FIXED memory for storing clipboard data.

by Alexandre Julliard

Rafał Harabień <rafalh1992(a)o2.pl> writes: > Tested behavior in Win 10. MSDN says clipboard uses GMEM_SHARED handles but its not true. > Some applications depends on GetClipboardData returning valid pointer to data instead of handle. > Commit fixes pasting from clipboard in Multi Theft Auto: San Andreas. > > Signed-off-by: Rafał Harabień <rafalh1992(a)o2.pl> > --- > dlls/user32/tests/clipboard.c | 58 ++++++++++++++++++++++++++++++++ > dlls/winex11.drv/clipboard.c | 77 +++++++++++++++++++++++++++++++++---------- > 2 files changed, 117 insertions(+), 18 deletions(-) This breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M ole32.dll -p ole32_test.exe.so clipboard && touch clipboard.ok clipboard.c:897: Test failed: got 0x145048 clipboard.c:914: Test failed: got 0x145048 Makefile:184: recipe for target 'clipboard.ok' failed -- Alexandre Julliard julliard(a)winehq.org

April 21, 2016

Re: [PATCH 2/2] gdi32/enhmfdrv: Don't drop viewport/window transformation in StretchBlt

by Huw Davies

On Wed, Apr 20, 2016 at 06:35:19PM +0200, Piotr Caban wrote: > diff --git a/dlls/gdi32/enhmfdrv/bitblt.c b/dlls/gdi32/enhmfdrv/bitblt.c > index d6d0fe7..ed03c1f 100644 > --- a/dlls/gdi32/enhmfdrv/bitblt.c > +++ b/dlls/gdi32/enhmfdrv/bitblt.c > @@ -122,7 +122,7 @@ BOOL EMFDRV_StretchBlt( PHYSDEV devDst, struct bitblt_coords *dst, > pEMR->dwRop = rop; > pEMR->xSrc = src->log_x; > pEMR->ySrc = src->log_y; > - GetWorldTransform(devSrc->hdc, &pEMR->xformSrc); > + GetTransform(devSrc->hdc, 0x204, &pEMR->xformSrc); > pEMR->crBkColorSrc = GetBkColor(devSrc->hdc); > pEMR->iUsageSrc = DIB_RGB_COLORS; > pEMR->offBmiSrc = emrSize; > This really needs a test, particularly as the docs say it should be the World -> Page transform. I agree, World -> Device makes more sense though. Huw.

April 21, 2016

Re: [1/2] shell32: Check IsWow64Process() before calling Wow64 functions.

by Alexandre Julliard

"Olivier F. R. Dierick" <o.dierick(a)piezo-forte.be> writes: > I don't know if resetting last error in SHFileOperation() is conformant. > That's why I took the route to fix one error at a time until there were > none left. More errors may be introduced later, but for now this patch > is the last one needed to fix bug 36838. > > I find forcing ERROR_SUCCESS in SHFileOperation() a brute and lazy way > to fix things. It may hide other errors. Fixing the internal code itself > may avoid bugs in other functions and is the way to go in my opinion. If the application depends on this, setting it explicitly is better than depending on side effects of internal code paths. -- Alexandre Julliard julliard(a)winehq.org

April 21, 2016

Re: [1/2] shell32: Check IsWow64Process() before calling Wow64 functions.

by Nikolay Sivov

On 21.04.2016 7:04, Olivier F. R. Dierick wrote: > Le jeudi 21 avril 2016 à 03:28 +0300, Nikolay Sivov a écrit : >> On 21.04.2016 3:12, Olivier F. R. Dierick wrote: >>> See bug 36838 for comments and discussion. >>> >>> Supersedes patch submission 121402. >>> >>> Better version of the patch. Call IsWow64Process() only once on dll >>> initialization and setup a global variable. >>> >> Like I said in bug comment, doing this is depending on a side effect. >> SHFileOperation() could do anything internally, if you want to have >> consistent ERROR_SUCCESS last error (even though it's kind of wrong to >> check it, since it returns error code already), why not force it in >> SHFileOperation() directly? Changing internal path is wrong in my opinion. > > I don't know if resetting last error in SHFileOperation() is conformant. > That's why I took the route to fix one error at a time until there were > none left. More errors may be introduced later, but for now this patch > is the last one needed to fix bug 36838. > > I find forcing ERROR_SUCCESS in SHFileOperation() a brute and lazy way > to fix things. It may hide other errors. Fixing the internal code itself > may avoid bugs in other functions and is the way to go in my opinion. > Well, it's clearly an application bug to check it in a first place. Fixing it this way you're now depending on implementation details, and like you said it can affect more than you tested.

April 21, 2016

Re: [1/2] shell32: Check IsWow64Process() before calling Wow64 functions.

by Olivier F. R. Dierick

Le jeudi 21 avril 2016 à 03:28 +0300, Nikolay Sivov a écrit : > On 21.04.2016 3:12, Olivier F. R. Dierick wrote: > > See bug 36838 for comments and discussion. > > > > Supersedes patch submission 121402. > > > > Better version of the patch. Call IsWow64Process() only once on dll > > initialization and setup a global variable. > > > Like I said in bug comment, doing this is depending on a side effect. > SHFileOperation() could do anything internally, if you want to have > consistent ERROR_SUCCESS last error (even though it's kind of wrong to > check it, since it returns error code already), why not force it in > SHFileOperation() directly? Changing internal path is wrong in my opinion. I don't know if resetting last error in SHFileOperation() is conformant. That's why I took the route to fix one error at a time until there were none left. More errors may be introduced later, but for now this patch is the last one needed to fix bug 36838. I find forcing ERROR_SUCCESS in SHFileOperation() a brute and lazy way to fix things. It may hide other errors. Fixing the internal code itself may avoid bugs in other functions and is the way to go in my opinion. -- Olivier F. R. Dierick o.dierick(a)piezo-forte.be

April 20, 2016

Re: [2/2] shell32/tests: Check if error status is reset after successful file copy

by Olivier F. R. Dierick

Le mercredi 20 avril 2016 à 19:41 -0500, Marvin a écrit : > 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=22410 > > Your paranoid android. > > > === wvistau64 (32 bit shlfileop) === > shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 > shlfileop.c:2439: Test failed: SHGetNewLinkInfoA failed, err=0 > shlfileop.c:2448: Test failed: SHGetNewLinkInfoA failed, err=0 > shlfileop.c:2452: Test failed: does not start with C:\Users\Public\Documents\testdir2 > shlfileop.c:2455: Test failed: does not end with .lnk > shlfileop.c:83: Test failed: Failure to open file > shlfileop.c:2461: Test failed: SHGetNewLinkInfoA failed, err=0 > shlfileop.c:2465: Test failed: s does not start with C:\Users\Public\Documents\testdir2 > shlfileop.c:2468: Test failed: s does not end with .lnk > > === wvistau64 (64 bit shlfileop) === > shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 > shlfileop.c:2439: Test failed: SHGetNewLinkInfoA failed, err=1008 > shlfileop.c:2448: Test failed: SHGetNewLinkInfoA failed, err=1008 > shlfileop.c:2452: Test failed: does not start with C:\Users\Public\Documents\testdir2 > shlfileop.c:2455: Test failed: does not end with .lnk > shlfileop.c:83: Test failed: Failure to open file > shlfileop.c:2461: Test failed: SHGetNewLinkInfoA failed, err=1008 > shlfileop.c:2465: Test failed: does not start with C:\Users\Public\Documents\testdir2 > shlfileop.c:2468: Test failed: does not end with .lnk > shlfileop.c:2470: Test failed: and are the same Those errors are unrelated to my patch. -- Olivier F. R. Dierick o.dierick(a)piezo-forte.be

April 20, 2016

Re: [2/2] shell32/tests: Check if error status is reset after successful file copy

by Marvin

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=22410 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 shlfileop.c:2439: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2448: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2452: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2455: Test failed: does not end with .lnk shlfileop.c:83: Test failed: Failure to open file shlfileop.c:2461: Test failed: SHGetNewLinkInfoA failed, err=0 shlfileop.c:2465: Test failed: s does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2468: Test failed: s does not end with .lnk === wvistau64 (64 bit shlfileop) === shlfileop.c:297: Test failed: SHGetFileInfoA(test4.txt/) should return 1, got 0x0 shlfileop.c:2439: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2448: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2452: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2455: Test failed: does not end with .lnk shlfileop.c:83: Test failed: Failure to open file shlfileop.c:2461: Test failed: SHGetNewLinkInfoA failed, err=1008 shlfileop.c:2465: Test failed: does not start with C:\Users\Public\Documents\testdir2 shlfileop.c:2468: Test failed: does not end with .lnk shlfileop.c:2470: Test failed: and are the same

April 20, 2016

Re: [1/2] shell32: Check IsWow64Process() before calling Wow64 functions.

by Nikolay Sivov

On 21.04.2016 3:12, Olivier F. R. Dierick wrote: > See bug 36838 for comments and discussion. > > Supersedes patch submission 121402. > > Better version of the patch. Call IsWow64Process() only once on dll > initialization and setup a global variable. > >>From e7b7317755faff75b960f9143b2195344113a9a4 Mon Sep 17 00:00:00 2001 > From: "Olivier F. R. Dierick" <o.dierick(a)piezo-forte.be> > Date: Wed, 20 Apr 2016 06:45:38 +0200 > Subject: shell32: Check IsWow64Process() before calling Wow64 functions. > > Signed-off-by: Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> > --- > dlls/shell32/shell32_main.c | 3 +++ > dlls/shell32/shell32_main.h | 1 + > dlls/shell32/shfldr_unixfs.c | 6 ++++-- > 3 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shell32_main.c b/dlls/shell32/shell32_main.c > index 74deecd..98e7fbf 100644 > --- a/dlls/shell32/shell32_main.c > +++ b/dlls/shell32/shell32_main.c > @@ -1255,6 +1255,7 @@ HRESULT WINAPI DllGetVersion (DLLVERSIONINFO > *pdvi) > * > */ > HINSTANCE shell32_hInstance = 0; > +BOOL is_wow64 = FALSE; > > > /************************************************************************* > @@ -1277,6 +1278,8 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD > fdwReason, LPVOID fImpLoad) > GetModuleFileNameW(hinstDLL, swShell32Name, MAX_PATH); > swShell32Name[MAX_PATH - 1] = '\0'; > > + if (!IsWow64Process( GetCurrentProcess(), &is_wow64 )) is_wow64 > = FALSE; > + > InitChangeNotifications(); > break; > > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index 492f79f..7a4d9b2 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -42,6 +42,7 @@ > */ > extern HMODULE huser32 DECLSPEC_HIDDEN; > extern HINSTANCE shell32_hInstance DECLSPEC_HIDDEN; > +extern BOOL is_wow64 DECLSPEC_HIDDEN; > > /* Iconcache */ > #define INVALID_INDEX -1 > diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c > index be1ba81..d9b1320 100644 > --- a/dlls/shell32/shfldr_unixfs.c > +++ b/dlls/shell32/shfldr_unixfs.c > @@ -414,7 +414,8 @@ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, > char *pszCanonicalPath) > dospath_end = dospath + lstrlenW(dospath); > /* search for the most valid UNIX path possible, then append > missing > * path parts */ > - Wow64DisableWow64FsRedirection(&redir); > + if(is_wow64) > + Wow64DisableWow64FsRedirection(&redir); > while(!(pszUnixPath = wine_get_unix_file_name(dospath))){ > if(has_failed){ > *dospath_end = '/'; > @@ -428,7 +429,8 @@ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, > char *pszCanonicalPath) > } > *dospath_end = '\0'; > } > - Wow64RevertWow64FsRedirection(redir); > + if(is_wow64) > + Wow64RevertWow64FsRedirection(redir); > if(dospath_end < dospath) > return FALSE; > strcat(szPath, pszUnixPath + cDriveSymlinkLen); > Like I said in bug comment, doing this is depending on a side effect. SHFileOperation() could do anything internally, if you want to have consistent ERROR_SUCCESS last error (even though it's kind of wrong to check it, since it returns error code already), why not force it in SHFileOperation() directly? Changing internal path is wrong in my opinion.

April 20, 2016

Re: [2/2] shell32/tests: Check if error status is reset after successful file copy

by Marvin

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

April 20, 2016

Re: mmdevapi/tests: Use RegQueryValueExW() for compatibility with Windows XP.

by Andrew Eikum

On Wed, Apr 20, 2016 at 10:17:49PM +0200, Francois Gouget wrote: > On Wed, 20 Apr 2016, Andrew Eikum wrote: > > > mmdevapi doesn't exist on winxp. I'm not opposed to this change, but > > does it matter? > > It fixes this failure: > https://testbot.winehq.org/JobDetails.pl?Key=22355 > > Arguably the TestBot should have realized that mmdevapi is missing and > skipped running the test altogether. But in the meantime this means > further mmdevapi patches will not return spurious failures. > Works for me. Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com>

April 20, 2016