January 2008 - Wine-Devel - list.winehq.org

Re: start.exe: Handle the process title argument (try2)

by Alexander Nicolaysen Sørnes

On Tuesday 29 January 2008 04:10:34 Dmitry Timoshkov wrote: > "Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > > - Use GlobalFree instead of LocalFree > > According to MSDN LocalFree is the correct one, as I asked before > you need to fix Wine implementation of CommandLineToArgvW. Sorry, I misread your previous post. THanks for point it out. Alexander

Jan. 29, 2008

Re: ddraw: ddrawmodes test failures (all platforms)

by Stefan Dösinger

Am Dienstag, 29. Januar 2008 19:16:38 schrieb Reece Dunn: > On 26/01/2008, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > > Stefan Dösinger wrote: > > > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: > > >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > > >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: > > >>>> Hi, > > >>>> > > >>>> Looking at the ddrawmode test failures, they are because the test is > > >>>> checking that if the DDSD_REFRESHRATE flag is set, then > > >>>> dwRefreshRate is not 0. However, on many of the test platforms at > > >>>> http://test.winehq.org/data/200801161000, they are reporting a > > >>>> refresh rate of 0. > > >>>> > > >>>> Are these bogus - due to them running on VM - or is this a valid > > >>>> case? > > >>> > > >>> I have never seen such failures on my real hardware(Windows XP or > > >>> Vista), so I think they fail due to VM drivers. I'll re-run the tests > > >>> to make sure the tests didn't break somewhen. > > >> > > >> I don't think so. My system (called xanlosch) is a real XP system with > > >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers > > >> (7.11er catalyst drivers). Maybe an ATI driver issue? > > > > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the > > same results: > > > > http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmode > >s.txt > > The options for this are: > > 1. Remove this test case. > > 2. Set the data member being checked to 0xdeadbeef or similar > value, then check if the data member has been set. Ideally, this would > need to be done before every call into the callback function where > this check is happening, but this may not be possible. > > I prefer option 2, as this tests if the data member is set (even if it > is set to 0) when the specified flag is set. I'll send a patch once Alexandre is back, as currently it doesn't make much sense flooding wine-patches. I actually intended option 1 first, but now that you mentioned it I think 2 is better.

Jan. 29, 2008

RE: d3dx: A few last questions...

by tony.wasserka＠freenet.de

> The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file to the 36 because D3DX_SDK_VERSION changes for each file. Thanks for your comment, though I don't know if this is needed: Comment from the d3dx9core.h of the DX SDK: > /////////////////////////////////////////////////////////////////////////// > // D3DX_SDK_VERSION: > // ----------------- > // This identifier is passed to D3DXCheckVersion in order to ensure that an > // application was built against the correct header files and lib files. > // This number is incremented whenever a header (or other) change would > // require applications to be rebuilt. If the version doesn't match, > // D3DXCheckVersion will return FALSE. (The number itself has no meaning.) > /////////////////////////////////////////////////////////////////////////// So this function is only needed to ensure that no header file changed between the last build of an application. As this won't be the case in our wine implementation we can let all dlls use the same function. Also, the D3DX_SDK_VERSION is declared in d3dx9core.h, which means we can only have one definition of it at a time which even prevents us from caring about this function. By the way, I think this function is just a leftover from the times, when microsoft released updates of their D3DX library without renaming the dlls, were using a more actual dll could really lead to conflicts. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

Jan. 29, 2008

Re: shell32:shlfileop - interactive dialogs on Windows Vista

by Reece Dunn

On 27/01/2008, Reece Dunn <msclrhd(a)googlemail.com> wrote: > Hi, > > One of the new features of Windows Vista is to bring up dialogs > whenever you are copying files, moving files, etc. to ask the user > what behaviour they want (e.g. move and replace; don't move; move, but > keep both files). > > This makes it more user friendly, but for the Wine tests, it means that: > - on XP the shlfileop tests run and pass eithout any user interaction; > - on Vista, the shlfileop tests bring up several of those dialog prompts. > > I haven't yet looked at the tests to see what they are doing, or at > the MSDN documentation to see if this would break things (i.e. if the > program selected copy & replace, but the user said don't copy). > > Does anyone have any ideas how to get these working without user > interaction (or if that is at all possible)? Any ideas? Also, the length of the timeout period in the Wine Test Shell should be increased to cater for the timeout in several tests that do eventually pass (see the previous e-mail sent about this). - Reece

Jan. 29, 2008

Re: Wine Wiki spam users

by Michael Stefaniuc

Vitaliy Margolen wrote: > Does anyone have a power to block / remove those users that spam Wine wiki? > It seems just 2-3 users keep creating more and more spam. Can't we just > remove them and permanently block an IP range? I wonder if we should enable moderation of account creations and spread the load of deleting rogue users on many shoulders. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111

Jan. 29, 2008

Re: user32: understanding the HiliteMenuItem failures (all platforms)... call for help

by Reece Dunn

On 26/01/2008, Reece Dunn <msclrhd(a)googlemail.com> wrote: > Hi, > > I am currently looking at the user32: menu (HiliteMenuItem) test failures: > > menu.c:1884: Test failed: HiliteMenuItem: Item 1 is not hilited > menu.c:1891: Test failed: HiliteMenuItem: Item 3 is not hilited > > 1. These are failing consistently on all platforms (see > http://test.winehq.org/data/200801161000 - you may need to search for > HiliteMenuItem to find the failures!). > > 2. It appears (backed up with tests in the attached patch) that the > API fails when the HWND parameter is NULL. > > 3. The tests are not comprehensive enough. > > The patch I have attached here is still a work in progress: see previous e-mail for the patch. > 1. I have not tested it on Wine - it is likely that this will require > todo_wine markers to make it run successfully. > > 2. The tests are still failing on Windows (both XP and Vista). > > Here is where I get stuck. According to the MDSN documentation (which > is likely to be wrong) this appears to be correct. > > Does anyone know how to get HiliteMenuItem to work?! Any ideas? - Reece

Jan. 29, 2008

Re: ddraw: ddrawmodes test failures (all platforms)

by Reece Dunn

On 26/01/2008, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Stefan Dösinger wrote: > > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: > >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: > >>>> Hi, > >>>> > >>>> Looking at the ddrawmode test failures, they are because the test is > >>>> checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate > >>>> is not 0. However, on many of the test platforms at > >>>> http://test.winehq.org/data/200801161000, they are reporting a refresh > >>>> rate of 0. > >>>> > >>>> Are these bogus - due to them running on VM - or is this a valid case? > >>> I have never seen such failures on my real hardware(Windows XP or Vista), > >>> so I think they fail due to VM drivers. I'll re-run the tests to make > >>> sure the tests didn't break somewhen. > >> I don't think so. My system (called xanlosch) is a real XP system with > >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers > >> (7.11er catalyst drivers). Maybe an ATI driver issue? > > > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the same > results: > > http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmodes.… The options for this are: 1. Remove this test case. 2. Set the data member being checked to 0xdeadbeef or similar value, then check if the data member has been set. Ideally, this would need to be done before every call into the callback function where this check is happening, but this may not be possible. I prefer option 2, as this tests if the data member is set (even if it is set to 0) when the specified flag is set. Any takers? - Reece

Jan. 29, 2008

Re: Mail flood from the uncoordinated bugzilla cleanup

by Dan Kegel

On Jan 29, 2008 8:36 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > The flood was to fast to stop Mail-delivery in wine-bugs. > After i stopped Mail-delivery in wine-bugs, the sending queue was still > so full, that my Mailbox got flood again and the bounce rate reached the > limit and mailman disabled Mail-delivery for all wine groups. Sorry. Hopefully there won't be a next time, but if there is, we should give people a few days warning so they can unsubscribe. Or we should disable sending mail when doing bulk changes. - Dan

Jan. 29, 2008

Mail flood from the uncoordinated bugzilla cleanup

by Detlef Riekenberg

Grrr. Please remember, that some Free Mail accounts have a limit in the numbers of Mails. The flood was to fast to stop Mail-delivery in wine-bugs. After i stopped Mail-delivery in wine-bugs, the sending queue was still so full, that my Mailbox got flood again and the bounce rate reached the limit and mailman disabled Mail-delivery for all wine groups. Not nice. -- By by ... Detlef

Jan. 29, 2008

re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING

by Dan Kegel

James McKenzie wrote: > Please submit a git diff not a UNIX diff. Now, hang on there. Jens submitted a perfectly good unified diff patch taken from the right directory. There is no reason to turn up our noses at it. It will apply using patch in exactly the same way as a diff generated by git. Jens, you're fine, I wouldn't bother rediffing. You might however resend your patch next week when Alexandre the maintainer is back from vacation! - Dan

Jan. 29, 2008