November 2007 - Wine-Devel - list.winehq.org

dlls/wintab32/context.c -- simpflication and HEADS UP!

by Gerald Pfeifer

This change of mine is obvious since InExt and OutExt are DWORD, thus unsigned, and thus always greater or equal zero so my patch should be fine in any case. However, looking at the else-part of the if-statement, I have some doubts this is working as designed, and in general the abs() invocations are bogus. Any expert who could help with a more extensive patch? Gerald ChangeLog: Simplify condition in ScaleForContext(). Index: dlls/wintab32/context.c =================================================================== RCS file: /home/wine/wine/dlls/wintab32/context.c,v retrieving revision 1.22 diff -u -3 -p -r1.22 context.c --- dlls/wintab32/context.c 21 Sep 2007 12:24:49 -0000 1.22 +++ dlls/wintab32/context.c 30 Nov 2007 23:53:47 -0000 @@ -176,7 +176,7 @@ int TABLET_PostTabletMessage(LPOPENCONTE static inline DWORD ScaleForContext(DWORD In, DWORD InOrg, DWORD InExt, DWORD OutOrg, DWORD OutExt) { - if (((InExt > 0 )&&(OutExt > 0)) || ((InExt<0) && (OutExt < 0))) + if ((InExt > 0) && (OutExt > 0)) return ((In - InOrg) * abs(OutExt) / abs(InExt)) + OutOrg; else return ((abs(InExt) - (In - InOrg))*abs(OutExt) / abs(InExt)) + OutOrg;

Nov. 30, 2007

Re: wininet: Add test for FtpGetCurrentDirectoryA

by James Hawkins

On Nov 30, 2007 3:47 PM, Zac Brown <zac(a)zacbrown.org> wrote: > Hi, > > Changelog: > * Add a test in dlls/wininet/tests/ftp.c for FtpGetCurrentDirectoryA > > Notes: > * This test passes fully without error on Windows XP, with the test compiled by Visual Studio Express C++ 2008. > * The functions this test call are currently broken in wine and I am in the process of fixing them myself. > > Patch is pasted below: > > > --- > dlls/wininet/tests/ftp.c | 84 +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 83 insertions(+), 1 deletions(-) > > diff --git a/dlls/wininet/tests/ftp.c b/dlls/wininet/tests/ftp.c > index 6d03fb8..f6517b0 100644 > --- a/dlls/wininet/tests/ftp.c > +++ b/dlls/wininet/tests/ftp.c > @@ -691,6 +691,85 @@ static void test_command(HINTERNET hFtp, HINTERNET hConnect) > } > } > > +static void test_get_current_dir(HINTERNET hFtp, HINTERNET hConnect) > +{ > + BOOL bRet; > + DWORD dwCurrentDirectory = MAX_PATH; > + CHAR lpszCurrentDirectory[MAX_PATH]; > + > + /* change directories to get a more interesting pwd */ > + bRet = FtpCommandA(hFtp, FALSE, FTP_TRANSFER_TYPE_ASCII, "CWD pub/", 0, NULL); > + if(bRet == FALSE) > + { > + trace("Failed to change directories in test_get_current_dir(HINTERNET hFtp).\n"); > + return; > + } > + > + /* test with all NULL arguments */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( NULL, NULL, 0 ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INVALID_HANDLE, "Expected ERROR_INVALID_HANDLE, got: %d\n", GetLastError()); > + > + /* test with NULL parameters instead of expected LPSTR/LPDWORD */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( hFtp, NULL, 0 ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INVALID_PARAMETER, "Expected ERROR_INVALID_PARAMETER, got: %d\n", GetLastError()); > + > + /* test with no valid handle and valid parameters */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( NULL, lpszCurrentDirectory, &dwCurrentDirectory ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INVALID_HANDLE, "Expected ERROR_INVALID_HANDLE, got: %d\n", GetLastError()); > + > + /* test with invalid dwCurrentDirectory and all other parameters correct */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( hFtp, lpszCurrentDirectory, 0 ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INVALID_PARAMETER, "Expected ERROR_INVALID_PARAMETER, got: %d\n", GetLastError()); > + > + /* test with invalid lpszCurrentDirectory and all other parameters correct */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( hFtp, NULL, &dwCurrentDirectory ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Expected ERROR_INSUFFICIENT_BUFFER, got: %d\n", GetLastError()); > + > + /* test to show it checks the handle type */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( hConnect, lpszCurrentDirectory, &dwCurrentDirectory ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n" ); > + ok ( GetLastError() == ERROR_INTERNET_INCORRECT_HANDLE_TYPE, > + "Expected ERROR_INTERNET_INCORRECT_HANDLE_TYPE, got: %d\n", GetLastError()); > + > + /* test for the current directory with legitimate values */ > + SetLastError(0xdeadbeef); > + bRet = FtpGetCurrentDirectoryA( hFtp, lpszCurrentDirectory, &dwCurrentDirectory ); > + ok ( bRet == TRUE, "Expected FtpGetCurrentDirectoryA to pass\n" ); > + ok ( lstrcmp(lpszCurrentDirectory, "/pub") == 0, "Expected returned value \"%s\" to match \"%s\" \n", (char*)lpszCurrentDirectory, "/pub"); > + ok ( GetLastError() == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got: %d\n", GetLastError()); > + > + > + /* test for the current directory with a size only large enough to > + * fit the string and not the null terminating character */ > + SetLastError(0xdeadbeef); > + dwCurrentDirectory = 4; > + lpszCurrentDirectory[4] = 'a'; /* set position 4 of the array to something else to make sure a leftover \0 isn't fooling the test */ > + bRet = FtpGetCurrentDirectoryA( hFtp, lpszCurrentDirectory, &dwCurrentDirectory ); > + ok ( bRet == FALSE, "Expected FtpGetCurrentDirectoryA to fail\n"); > + ok ( lstrcmp(lpszCurrentDirectory, "/pub") != 0, "Expected returned value \"%s\" to not match \"%s\" \n", (char*)lpszCurrentDirectory, "/pub"); > + ok ( GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Expected ERROR_INSUFFICIENT_BUFFER, got: %d\n", GetLastError()); > + > + /* test for the current directory with a size large enough to store > + * the expected string as well as the null terminating character */ > + SetLastError(0xdeadbeef); > + dwCurrentDirectory = 5; > + bRet = FtpGetCurrentDirectoryA( hFtp, lpszCurrentDirectory, &dwCurrentDirectory ); > + ok ( bRet == TRUE, "Expected FtpGetCurrentDirectoryA to pass\n"); > + ok ( lstrcmp(lpszCurrentDirectory, "/pub") == 0, "Expected returned value \"%s\" to match \"%s\" \n", (char*)lpszCurrentDirectory, "/pub"); > + ok ( GetLastError() == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got: %d\n", GetLastError()); > +} > + > START_TEST(ftp) > { > HANDLE hInternet, hFtp, hHttp; > @@ -733,7 +812,10 @@ START_TEST(ftp) > test_removedir(hFtp, hHttp); > test_renamefile(hFtp, hHttp); > test_command(hFtp, hHttp); > - > +todo_wine > +{ > + test_get_current_dir(hFtp, hHttp); > +} > InternetCloseHandle(hHttp); > InternetCloseHandle(hFtp); > InternetCloseHandle(hInternet); > You put the todo_wine around each block of ok's that fail, not around the whole test function. -- James Hawkins

Nov. 30, 2007

Note to packagers: choose gcc version carefully when building wine

by Dan Kegel

Attention packagers: the default version of gcc on many distros happens to generate Wine binaries which make some copy protection schemes unhappy. At the moment, gcc-3.3.x, gcc-3.4.x, and gcc-4.2.x are known to work; gcc-4.0.x is known to not work. Please check the compiler you use when building wine packages and make sure it's one of the good ones. To really check, find a retail copy of Photoshop CS or CS2 (not 7 or CS3) and install from cd-rom. If it aborts silently near the end without offering to activate the product, you have an unsupported compiler, and users of your packages might run into trouble with apps protected with safedisc. See http://bugs.winehq.org/show_bug.cgi?id=10273 for more info. - Dan

Nov. 30, 2007

Re: xdg_user_dirs patches

by Frank Richter

On 30.11.2007 18:50, Dimi Paun wrote: > I guess the preferred solution would be to teach GNOME & KDE > about .lnk files. Or write .desktop files to the Desktop dir. -f.r.

Nov. 30, 2007

d3dx8 dll

by David.Adam＠math.cnrs.fr

My second patch was not committed, because Alexandre wants all the functions to be implemented in d3dx9-36.dll. Then, the other d3dx9_xx dll forward their functions to d3dx9_36.dll. David

Nov. 30, 2007

d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by tony.wasserka＠freenet.de

Okay, then that has been discussed. By the way, what about David's second patch? Was there anything wrong about it or why isn't it in the tree, yet?

Nov. 30, 2007

Re: xdg_user_dirs patches

by Dimi Paun

On Fri, 2007-11-30 at 18:45 +0100, Francois Gouget wrote: > That's ok only because you don't care about the Windows desktop > shortcuts... I guess the preferred solution would be to teach GNOME & KDE about .lnk files. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Nov. 30, 2007

Re: xdg_user_dirs patches

by Juan Lang

> That's ok only because you don't care about the Windows desktop > shortcuts... Right, I know. My point is, there's no one-size-fits-all policy that's clearly better than any other, at least that I've seen. --Juan

Nov. 30, 2007

Re: xdg_user_dirs patches

by Francois Gouget

On Fri, 30 Nov 2007, Juan Lang wrote: [...] > While this is annoying, I find it confusing to go to the "Desktop" > directory and not find the files on my desktop there. I prefer having > the two desktops the same, and just delete the .lnk files myself. That's ok only because you don't care about the Windows desktop shortcuts... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Nov. 30, 2007

Re: d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by Francois Gouget

On Fri, 30 Nov 2007, tony.wasserka(a)freenet.de wrote: > > So, just to clarify, you propose to create a d3dx9.dll dll, putting its > > code in dlls/d3dx9. Does this dll exist on Windows? If not, then we > > should call it wined3dx9 (and its code would go in dlls/wined3dx9). > > Well, it shouldn't even be a dll, just a folder were put in all the d3dx9 code > and let the d3dx9_xx.dlls just export the functions they need. Then that code should not go in dlls/d3dx9 but in libs/d3dx9 or some such. > I don't know of how much the makefile system is capable, but maybe we can > put all the d3dx9_xx.spec files in the same directory to improve overviewability, > I don't like these 13 dlls/d3dx9 directories that much :D In the pas we've had multiple dlls in a single dlls/xxx sub-directory... but in sub-directories thereof. Anyway that's the past. Now it's all be standardised: * for each dll we implement there one and only one subdirectory in 'dlls' * conversely, each 'dlls' subdirectory implements one and only one dll That's quite practical to automate the generation of Makefiles, Visual Studio projects, automated code checking, etc. Besides, what's an 13 extra directories in a sea of already 233 dlls. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Nov. 30, 2007