December 2007 - Wine-devel - list.winehq.org

re: ntdll: unload modules based on inter-module dependencies
by Dan Kegel 01 Dec '07

01 Dec '07

This patch seems to break wineprefixcreate.

2 1

None
by Darragh Bailey 01 Dec '07

01 Dec '07

Cc: Bcc: Subject: Re: xlviewer install cmdline passed from CreateProcessA to msiexec looks wrong Reply-To: In-Reply-To: <20071124025012.GA27234(a)compsoc.nuigalway.ie> After doing further debugging I've come to the conclusion that the behaviour found when I was looking at bug 9628 is indeed a bug and have logged a new one accordingly with as much detail as I thought was necessary. http://bugs.winehq.org/show_bug.cgi?id=10618 Basically it turns out that if a program is called via CreateProcessW, the command line used may not result in the same argv being passed to the target program as it was called directly. In this case there was a difference in the argv seen by msiexec depending on whether it was run directly or called by the setup exe. Traced the bug to a corner case in the function build_argv in dlls/kernel32/process.c. Basically it does not detect the end of the argument correctly when dealing with the following text. SETUPEXEPATH=\"C:\\windows\\temp\\IXP030.TMP\\\" Because of the escaped '\', which should be valid since it is part of a directory path, at the end followed by the escaped '"', the function thinks that it has just encountered an escaped '"' instead of the end of the argument. I'm not 100% sure how to solve this, so I will probably have to run some tests on windows using the CreateProcessW call and study the argv received by the target. I have a feeling that the rule is probably something like: If in quotes && text before slashes != whitespace && text after quote == whitespace: then found matching quote Hopefully I should be able to come up with test cases that will show the truth of this, and then be able to confirm what the function build_argv should be testing to catch cases like this. -- Darragh "Nothing is foolproof to a sufficiently talented fool."

1 0

Re: wininet: Add test for FtpGetCurrentDirectoryA
by James Hawkins 01 Dec '07

01 Dec '07

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

2 1

Visual C++ 5 works pretty well...
by Dan Kegel 01 Dec '07

01 Dec '07

For fun, I installed Visual C++ 5 and built a few things with it. Ran very nicely. Filed two bugs: http://bugs.winehq.org/show_bug.cgi?id=10623 (VC++ 5 doesn't know who registered it) http://bugs.winehq.org/show_bug.cgi?id=10622 (VC++ 5 hangs on exit) It complained a bit if I didn't install MFC40.DLL before building MFC apps. Also, the dialog to add include directories acted strangely; Tools / Options / Directories lets you insert a new directory, and pretends to let you browse for it, but it acts very oddly after navigating to the first folder; clicking on that doesn't open the folder as expected, but rather just selects that folder. (Not sure if that's different on Windows, but it sounds like a wine bug.) Debugging, compiling simple floating point apps, editing all worked smoothly. Nice! I don't know how stable it is on long use; all my sessions were short. - Dan

1 0