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

RE: dinput: Add mouse warp override config option (resend)
by Stefan Dösinger Aug. 19, 2008

Aug. 19, 2008

Just for the record, I think we really want this patch. XInput 2 is currently under development, so we cannot fix the issue properly right now. Even if we have XI2, there will still be old X servers around for ages. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Vitaliy Margolen > Sent: Monday, August 18, 2008 8:18 PM > To: wine-patches(a)winehq.org > Subject: dinput: Add mouse warp override config option (resend) > > > Set [HKCU\Software\Wine\DirectInput] (or application specific key) > "MouseWarpOverride" to: > "force" - always warp > "disable" - newer warp > "anything else" - warp when needed - current behavior (default) > --- > dlls/dinput/mouse.c | 39 ++++++++++++++++++++++++++++++++++----- > 1 files changed, 34 insertions(+), 5 deletions(-)

3 5

Translating kernel32/nls/winerr_eng
by Alexander Nicolaysen Sørnes Aug. 19, 2008

Aug. 19, 2008

Hello, I'm translating the winerr messages to Norwegian, but I'm not completely sure about the LanguageNames line. Should the code be the same as the language ID (0x414)? LanguageNames=(NOR=0x414:winerr) This seems to be the case for English, but not French & German. Alexander N. Sørnes

1 0

Re: winmm: Test opening the same device twice
by Eric Pouech Aug. 19, 2008

Aug. 19, 2008

Maarten Lankhorst a écrit : > Behavioral test to show that wine winmm needs fixing. > --- > ------------------------------------------------------------------------ > > this likely is going to fail on old boxes there's no requirement on MS side that a PCM renderer has to be opened twice so having it as a test is wrong some old cards with OSS as a driver forbid the card to be opened twice (especially in different processes). IIRC, there was a bit of support in the OSS driver (not sure about the ALSA one) to allow > 1 opening in the same process (and also opening one handle for sound capture and another one for sound rendering). but this didn't provide support for mixing the output from the two different handles, which is likely what part of what you're trying to do assumes (especially for dsound plus standard winmm output) the only way out is to have the Linux (or Unix) driver handle several opening including the mixing of the two streams if the driver doesn't provide this flexibility, I don't see a point of implementing it in Wine A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

patchwatcher and changes to configure.h.in [was: re: ntdll/file: Add sub-second resolution to NtQueryInformationFile]
by Dan Kegel Aug. 19, 2008

Aug. 19, 2008

>> Btw, how does patchwatcher handle that? >> Does it detect that in the case of changing config.h.in, >> dlls/Makefile.in, server/protocol.def it needs >> to regenerate the files by running autoconf, >> tools/make_requests, or tools/make_makefiles? > > Not at all. Patches gratefully accepted. Status: - posted note about two bugs in patch series handling, will fix tomorrow - "time baseline_tests" doesn't work (limitation of time cmd), need to fix borkage there. Sloppy. - Austin sent in a patch to install gecko - I'm close to having valgrind integration, but haven't looked at how to make it fast enough yet. - user32:monitor.c:262: Test failed: Failed to reset default resolution is happening lately; should probably restart X server between runs

2 2

re: msvcmaker: fix project file generation under MinGW32
by Dan Kegel Aug. 19, 2008

Aug. 19, 2008

Hi Hongbo, it looks like your patch failed to apply because you did not preserve whitespace exactly. Your patch uses all spaces for the context, but the file contains tabs, so it does not match, and patch fails. - Dan ---------- Forwarded message ---------- From: <patchwatcher(a)kegel.com> Date: Tue, Aug 19, 2008 at 10:16 AM Subject: Patchwatcher: failed to apply: msvcmaker: fix project file generation under MinGW32 To: dank(a)kegel.com Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "msvcmaker: fix project file generation under MinGW32" Result: the patch failed to apply. You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/3.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/3.txt See http://kegel.com/wine/patchwatcher/results for more info.

1 0

Patchwatcher status
by Dan Kegel Aug. 19, 2008

Aug. 19, 2008

Patchwatcher falsely complained that [2/17] richedit: Removed assumption about the order of rtf indent didn't apply because the regexp I used to detect the end of a patch series falsely matched the first patch in a series of 1x patches. Here's the fix: --- patchwatcher.sh (revision 150) +++ patchwatcher.sh (working copy) @@ -283,7 +283,7 @@ cat $PATCHES/$NEXT.log fi # Use a regexp with a back reference to detect last patch in a series and break out - if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && ! egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt + if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && ! egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt then echo In middle of patch series, not wiping tree NEXT=`expr $NEXT + 1` And it falsely complained that various of adam(a)tpetaccia.com's patches failed because it didn't handle the case of multiple patch series sent by the same author back to back and mixed together by email delays. Here's a fix: --- get-patches.pl (revision 150) +++ get-patches.pl (working copy) @@ -147,7 +147,7 @@ $series_num_patches = $num_patches; } - if ($series_sender ne $sender) { + if ($series_sender ne $sender || $series_num_patches != $num_patches) { #print "Ignoring series for now, will try later; sender $sender, num_patches $num_patches, subject ".$header->get('Subject')."\n"; # can't handle multiple series at once just yet, let it sit return; That still won't handle the case of two patch series of the same length being sent back to back by the same author, but that's ambiguous enough that even humans might be confused, so it should tide us over until I rewrite the patch series detector to handle incomplete series better. I'm on vacation so I can't apply these patches to the running instance, I'll do it on tuesday. - Dan

2 3

New kernel development guide might be good model for Wine...
by Dan Kegel Aug. 19, 2008

Aug. 19, 2008

This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar.

6 10

Re: Raising exception for SC_RPC_HANDLE being NULL
by Rob Shearman Aug. 19, 2008

Aug. 19, 2008

2008/8/18 Michael Martin <martinmnet(a)hotmail.com>: > > In widl code generated for services an > exception is raised for null string with RPC_X_NULL_REF_POINTER > In windows calls made to for example CreateService with all NULL's > checks are made on the handle being null and its checked first before null strings. > > Windows documentation on RPC_X_ exceptions say that > RPC_X_SS_IN_NULL_CONTEXT is raised for null handles. > > suggested patch > > Index: widl/client.c > =================================================================== > --- widl/client.c (trunk) > +++ widl/client.c (working copy) > @@ -67,6 +67,15 @@ > indent--; > print_client("}\n\n"); > } > + else if ((var->type->name) && (strncmp(var->type->name,"SC_RPC_HANDLE", 13)==0)) How on earth do you think it is the right fix to hard-code a services type into widl? Did you not notice that SC_RPC_LOCK also needs the right treatment and that renaming SC_RPC_HANDLE to XXXFOOBAR shouldn't make any difference to the generated code? The correct fix is to check for context handles and the output the below code. > + { > + print_client("if (!%s)\n",var->name); > + print_client("{\n"); > + indent++; > + print_client("RpcRaiseException(RPC_X_SS_IN_NULL_CONTEXT);\n"); > + indent--; > + print_client("}\n\n"); > + } > } > } -- Rob Shearman

1 0

Re: ole32 [2/2] (msi [9.5/13]): Storage sharing should be implemented inole32, not the lower-level file API
by Dmitry Timoshkov Aug. 18, 2008

Aug. 18, 2008

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > - { FALSE, ERROR_SHARING_VIOLATION, FALSE }, > - { TRUE, ERROR_SUCCESS, TRUE } > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS } > }; You forgot to remove 'BOOL todo;' from struct access_res definition. Also making the arrays of structures 'static const' while you are at it won't hurt (same for other similar tests). -- Dmitry.

1 0

Re: kernel32: Test the file access and share modes of CreateFile
by Dmitry Timoshkov Aug. 18, 2008

Aug. 18, 2008

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > Changelog: > * Test the file access and share modes of CreateFile. Of course, the more tests - the better, but isn't that a duplicate of existing test_file_sharing()? Besides win9x will require fixing it all over the place... -- Dmitry.

2 1