Am Samstag, den 18.10.2008, 22:18 +0000 schrieb Louis. Lenders:
Spent loads of time for more than 3 years trying to help triaging bugs and helping out in appdb, only to find out that all my patches are ignored silently
Sorry, what do you mean by *all* of your patches?
This is from the wine git log:
2008-09-25 Louis Lenders msi: Add stub for MsiSetExternalUIRecord. 2008-09-25 Louis Lenders shdocvw: Create default App Paths key for iexplore... 2008-09-04 Louis Lenders wine.inf: Add default Directx registry key for InstalledVersion. 2008-08-28 Louis Lenders shobjidl.idl: Add Taskbarlist interface definitions. 2008-08-28 Louis Lenders shlwapi: Fix UrlUnEscape to expand URLs in-place even... 2008-08-28 Louis Lenders shlwapi: Add test showing UrlUnEscape should convert... 2008-06-23 Louis Lenders d3dx9_*: Add version resources. 2008-06-21 Louis Lenders advapi32: Add stub for GetAuditedPermissionsFromAcl... 2008-06-20 Louis Lenders kernel32: Fix typo in SetProcessAffinityMask. 2008-06-10 Louis Lenders mscoree: Add stub for CorBindToCurrentRuntime. 2008-05-29 Louis Lenders wine.inf: Add fake glu32. 2008-04-18 Louis Lenders wininet: Improve stub for FindNextUrlCacheEntryW a... 2008-04-17 Louis Lenders urlmon: Add stub for CoInternetSetFeatureEnabled. 2008-03-12 Louis Lenders oleacc: Add GetOleaccVersionInfo. 2008-03-07 Louis Lenders shdocvw: Return something more useful for WebBrowser_get_Rea... 2008-02-29 Louis Lenders programs: Add a stubbed out secedit.exe. 2008-02-21 Louis Lenders shdocvw: Pretend success in WebBrowser_get_RegisterAsDropTarget. 2008-01-11 Louis Lenders shdocvw: Change return value for PersistMemory_Load. 2008-01-10 Louis Lenders user32: Add stub for GetLayeredWindowAttributes. [further patches back to 2005-12-06]
If people spent quite an amount of time trying to get a patch written, it shouldn't be too much trouble to just drop a note on wine-devel, what the reason is the patch got rejected.
In the case of the FOF_MULTIDESTFILES test patch that Vitaly didn't get in, I don't see an obvious problem in the last version, although that patch could be extended.
I suspect (but I am definitely not an expert in this area), that the patch Vitaly Perov sent:
| + /* move many files into directory with FOF_MULTIDESTFILES */ | + set_curr_dir_path(from, "test?.txt\0"); | + set_curr_dir_path(to, "testdir2\0"); | + retval = SHFileOperationA(&shfo2); | + todo_wine | + { | + ok(retval == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", retval); | + ok(file_exists("testdir2\test2.txt"), "Expected the file 'test2.txt' to exist\n"); | + ok(file_exists("testdir2\test4.txt"), "Expected the directory 'test4.txt' to exist\n"); | + }
works because FOF_MULTIDESTFILES makes SHFileOperation pair from entries with to entries. As in this case, the from entry only has one component, namely "test?.txt" (even if it expands to multiple files), only one component of the destination is used regardless of FOF_MULTIDESTFILES.
It would interesting to see what happens in the case that from contains two wildcard patterns, like "test?.txt\0test_?.txt\0" and dest contains two destinations like "testdir2\0testdir2\nested\0". If my intuition is right, without FOF_MULTIDESTFILES everything is moved into testdir2, and with FOF_MULTIDESTFILES, test1.txt, test2.txt, test3.txt and the directory test4.txt is moved to testdir2, whereas test_5.txt is moved to testdir2\nested.
But in the issue that started the thread I have to agree with James. FOF_MULTIDESTFILES is not to be set just because the destination is a directory. I quote Vitaly quoting MSDN: | FOF_MULTIDESTFILES | The pTo member specifies multiple destination files (one for each source | file in pFrom) rather than one directory where all source files are to be | deposited.
In this sentence "rather than" is the same as "instead of". So FOF_MULTIDESTFILES indicates that the pTo member does *not* specify one destination directory, but a list of destination files instead. As the test that did not get committed seems to show (if it was tested in Windows, stating that helps getting a patch committed; sending a patch that does not work on any Windows version is risky, as it might put you on the infamous s**t list temporarily), the "multiple destination files" MSDN talks about might also be multiple destination directories.
Ok, I try to resend my old tests, and write tests to other patches. Also there are some functions and stubs implemented, wchich doesn't require (as I think) a tests.
Even if you submit a stub, you usually do that because an application needs that function. In this case, it might be helpfull for people trying to implement that function to find an example use case in the testcase, so adding a todo_wine test is a nice thing, even if you just add a stub (it also shows in the test statistics that something needs to be done).
The tests do not only serve the purpose to test that Wine does what we expect wine to do (in fact, that is only a minor point of the tests), but more importantly, they should show that Wine and Windows do the *same* thing, so writing a testcase that passes after your patch has been applied to wine is a no-brainer unless you tested that this test also passes on Windows.
If a patch that contains only a test did not get committed and you resubmit it, please add a note on which Windows version you tested it, if you didn't include it in your first try. General hint: If you can't test on windows for some reason (like you propose a direct3d test that needs a graphics card you don't own), do not send the testcase to wine-patches, but to wine-devel, and explain briefly why you can't test, and ask other developers to test it for you. This is usually not a problem.
Regards, Michael Karcher