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

Re: Move of the Bugzilla CVS to Git

by Alexandre Julliard

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > As long as the CVS servers will be still available, or alternatively a > windows port of git is available that doesn't require thousands of other > tools... I'm certainly not going to maintain a CVS mirror of the bugzilla git, it's not worth the trouble. I believe git should work on cygwin, but in the worst case you will be able to get tree snapshots using the gitweb interface. -- Alexandre Julliard julliard(a)winehq.org

June 27, 2007

Re: Direct3D Game test framework

by Francois Gouget

On Mon, 25 Jun 2007, Stefan Dösinger wrote: > > cxtest has already impressive infratructure (installation, creation of > > clean environment) and nice scripting. However, it requires Metacity WM > > and VNC. > The Metacity WM doesn't really concern me, the VNC thing however does. This > makes game testing harder since VNC isn't a part of the average game setup. > We don't have to transfer all the rendering screenshots over VNC though. I am > CCing Martin Pilka on this, maybe he can give us some more insight. cxtest's run.sh script has a --no-vnc option. I know I have once run a test outside of VNC so VNC is not a hard requirement. cxtest will probably complain about it though, and you might lose some functionality like automatic screenshots on failures. The best would be to try it out. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

June 27, 2007

Re: user32,wined3d: move refresh rate fallback to catch all cases

by Erik Inge Bolsø

On Wed, 27 Jun 2007, H. Verbeet wrote: > On 27/06/07, Erik Inge Bolsø <knan-wine(a)anduin.net> wrote: > > On 25/06/07, H. Verbeet wrote: > > >On 24/06/07, Erik Inge Bolsø <knan-wine at anduin.net> wrote: > > >> --- > > >> dlls/user32/sysparams.c | 13 ++++++++++++- > > >> dlls/wined3d/device.c | 10 +--------- > > >> 2 files changed, 13 insertions(+), 10 deletions(-) > > >> > > >What was the reason for writing this? > > > > See the comments on > > http://appdb.winehq.org/appview.php?iVersionId=5618 > > > > ... essentially, I have a game that's hardcoded to request 1024x768x50hz, > > which is not available on my monitor, and the existing fallback to > > any available refresh rate in wined3d didn't catch it. Haven't traced the > > exact sequence of calls - but figured that since there was an existing > > refresh rate fallback coded, I'd move that a step instead of duplicating. > > > Makes sense, I guess, although I'm a bit worried if that fallback is a > proper solution in the first place. I suspect the game would fail on > Windows as well if the refresh rate isn't available. Also, the 54Hz Tested on an equivalent machine with windows xp; same graphics card/monitor combo ... it doesn't fail. > that's mentioned in the appdb page typically means you're using nVidia > drivers with DynamicTwinView turned on (the default), which reports > fake refresh rates. Good point, thanks for that hint. Now the list of refresh rates looks much saner. Still no 50hz anywhere in sight, so I still need the patch. -- Erik perl: n. Programmeringsspråk best beskrevet som en noe elastisk gaffateip med pigger og skjærekanter.

June 27, 2007

Re: cabinent: add a comment about parm passing

by James Hawkins

On 6/27/07, Jeff Latimer <lats(a)yless4u.com.au> wrote: > Coverity CID 43 Forward_Null is false. This adds a comment explaining > the NULL pass is ok. > Why do we need a comment for that? -- James Hawkins

June 27, 2007

Re: user32:painting.c Add comment to function.[try2]

by Robert Shearman

Anatoly Lyutin wrote: > /*********************************************************************** > * LockWindowUpdate (USER32.@) > + * > + * Enables or disables choosen window. > This isn't quite correct. LockWindowUpdate prevents or allows painting to the window. It doesn't prevent user input, which is what "disable" suggests (c.f. EnableWindow). -- Rob Shearman

June 27, 2007

Re: [advapi32/tests] Add some service related tests

by Paul Vriens

Paul Vriens wrote: > On 6/26/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Hi, >> >> While playing with native crypt32/wintrust I added a service >> (CryptSvc) to the >> registry (seems needed for native and XP+). With a full trace I get >> some crashes >> which made me start to write some tests for services. (Rolf >> Kalbermatter was >> already busy with services stuff, but said he doesn't have the time >> currently). >> >> Changelog >> Add some service related tests >> >> Cheers, >> >> Paul. >> > Ignore this one. I'll come up with something else as I've started > fixing things first. > > Cheers, > > Paul. > Never mind (it's committed). Cheers, Paul.

June 27, 2007

RE: [PATCH try2 2/2] winemenubuilder: Wait for application icons to be created instead of adding a RunOnce entry that may never run.

by Koshelev, Misha Vladislavo

>From: Alexandre Julliard [mailto:julliard(a)winehq.org] >Sent: Wed 6/27/2007 8:42 AM >To: Koshelev, Misha Vladislavo >Cc: Hans Leidekker; wine-devel(a)winehq.org >Subject: Re: [PATCH try2 2/2] winemenubuilder: Wait for application icons to be created instead of adding a >RunOnce entry that may never run. >Misha Koshelev <mk144210(a)bcm.edu> writes: > >> Hmm... I was not aware of this (that means that make change.ok in >> dlls/kernel32/tests fails on non-Linux systems?). What happens in these >> other non-Linux systems... does FindFirstChangeNotification return >> INVALID_HANDLE_VALUE or succeed and just never satisfy the wait >> condition? > >It will never satisfy the wait. That can happen on older Linux kernels >too, or on network file systems. You can't rely on change >notifications, they are just a hint. > >> The good thing about the __wine_make_system_process wait we are also >> waiting for is that it will get satisfied when all user processes have >> closed and create links then as well. This is actually sufficient in >> itself for some installers (Vector NTI), but not others that launch apps >> while installing (iTunes). Perhaps I can add a long timeout to the wait >> to account for these other non-Linux platforms... > >A better approach would probably be to simply wait for the parent >process to exit. Good point. This would probably avoid the __wine_make_system_process call altogether too. Will resubmit again prob sometime tonight. Misha

June 27, 2007

Re: [PATCH try2 2/2] winemenubuilder: Wait for application icons to be created instead of adding a RunOnce entry that may never run.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > Hmm... I was not aware of this (that means that make change.ok in > dlls/kernel32/tests fails on non-Linux systems?). What happens in these > other non-Linux systems... does FindFirstChangeNotification return > INVALID_HANDLE_VALUE or succeed and just never satisfy the wait > condition? It will never satisfy the wait. That can happen on older Linux kernels too, or on network file systems. You can't rely on change notifications, they are just a hint. > The good thing about the __wine_make_system_process wait we are also > waiting for is that it will get satisfied when all user processes have > closed and create links then as well. This is actually sufficient in > itself for some installers (Vector NTI), but not others that launch apps > while installing (iTunes). Perhaps I can add a long timeout to the wait > to account for these other non-Linux platforms... A better approach would probably be to simply wait for the parent process to exit. -- Alexandre Julliard julliard(a)winehq.org

June 27, 2007

Re: [3/3] gdi32: improved PolyDraw

by Alexandre Julliard

"Evan Stade" <estade(a)gmail.com> writes: > + for( i = dc->path.numEntriesUsed-1; i >= 0; i-- ){ > + if(dc->path.pFlags[i] == PT_MOVETO){ > + lastmove = dc->path.pPoints[i]; > + break; > + } > + } > + if(i < 0){ > + lastmove.x = 0; > + lastmove.y = 0; > + } This can't work, i is unsigned. -- Alexandre Julliard julliard(a)winehq.org

June 27, 2007

Re: [PATCH try2 2/2] winemenubuilder: Wait for application icons to be created instead of adding a RunOnce entry that may never run.

by Misha Koshelev

On Wed, 2007-06-27 at 12:37 +0200, Hans Leidekker wrote: > On Wednesday 27 June 2007, Misha Koshelev wrote: > > + /* Now watch the directory for our path to be created */ > + if ((*handles = FindFirstChangeNotificationW(dir, subtree, FILE_NOTIFY_CHANGE_FILE_NAME)) == > + INVALID_HANDLE_VALUE) > > I'm not sure if file change notifications are the right solution here > but since they are only supported on Linux you should at least keep the > run once key as a fallback strategy. > > -Hans Hmm... I was not aware of this (that means that make change.ok in dlls/kernel32/tests fails on non-Linux systems?). What happens in these other non-Linux systems... does FindFirstChangeNotification return INVALID_HANDLE_VALUE or succeed and just never satisfy the wait condition? The good thing about the __wine_make_system_process wait we are also waiting for is that it will get satisfied when all user processes have closed and create links then as well. This is actually sufficient in itself for some installers (Vector NTI), but not others that launch apps while installing (iTunes). Perhaps I can add a long timeout to the wait to account for these other non-Linux platforms... Anyhow, please let me know about the behavior of FindFirstChangeNotification on these other systems or where I can find this documented... Misha

June 27, 2007