July 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] shell32: Disable WOW64 redirection when converting pidls to UNIX paths. (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12984 Your paranoid android. === WVISTAADM (32 bit shlfolder) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

July 28, 2011

Re: user32/tests: Don't treat a button as a dialog (valgrind)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12982 Your paranoid android. === WNT4WSSP6 (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W2KPROSP4 (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === WXPPROSP3 (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W2K3R2SESP2 (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === WVISTAADM (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W2K8SE (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W7PRO (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W7PROX64 (32 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON === W7PROX64 (64 bit dialog) === dialog.c:641: Test failed: Button1 style not set to BS_DEFPUSHBUTTON dialog.c:644: Test failed: Button2's style not changed to BS_PUSHBUTTON

July 28, 2011

Re: make "bisected" a keyword in bugzilla?

by Austin English

On Sun, May 23, 2010 at 22:45, Wolfram Sang <wolfram(a)the-dreams.de> wrote: >> Probably it would be better to add a field for commit id that caused >> a regression just like there is one for url/keywords instead of inventing >> new keywords. So a 'regression' with a commit id would automatically mean >> 'bisected'. That would also save time of finding the commit id by looking >> at every comment in the bug, and possibly avoiding finding incorrect >> bisect results. > > Yay, that would be even better! While doing some other bugzilla maintenance, I've found where to add custom fields, so a 'regression commit sha1-id' (or other preferred name) field is now a possibility. I'll wait a week for comments before adding it. -- -Austin

July 28, 2011

Re: [PATCH 2/8] ntdll: rework the handling of server ioctls a little bit to avoid a crash with later patches

by Bernhard Loos

On Thu, Jul 28, 2011 at 7:46 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bernhard Loos <bernhardloos(a)googlemail.com> writes: > >> @@ -1273,10 +1282,16 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, >> >> if (wait_handle) >> { >> - NtWaitForSingleObject( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT), NULL ); >> - status = io->u.Status; >> + status = NtWaitForSingleObject( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT), NULL ); >> + if (status == STATUS_USER_APC) >> + { >> + async->interrupted = TRUE; >> + status = STATUS_CANCELLED; /* not really, the ioctl completes and event and the handle >> + itself get signaled */ >> + } > > This looks wrong. You can't claim it was cancelled if it's still > running. > > -- > Alexandre Julliard > julliard(a)winehq.org > I'm not really sure, what to do at this point. I can't exactly return ERROR_SUCCESS because the operation is not completed yet. At best, I can reenter the wait, but this will break in places, where the caller depends on DeviceIoControl returning in case of a scheduled user apc. Bernhard Loos

July 28, 2011

Re: bugzilla: merge OS X/Windows OS versions

by Jerome Leclanche

On Thu, Jul 28, 2011 at 7:40 PM, Austin English <austinenglish(a)gmail.com> wrote: > This was mentioned a while back, though I can't find the reference on > wine-devel, perhaps it was in #winehackers... > > Anyway, would anyone be opposed to merging the Mac OS X versions (and > possibly the Windows versions) in the OS field in Bugzilla? We don't > differentiate any other OS, and for Windows, there are very few bugs > filed anyway (mostly against the test suite or building on cygwin). > > So, instead of: > Windows 3.1 > Windows 95 > Windows 98 > Windows ME > Windows 2000 > Windows NT > Windows XP > Windows Vista > Mac OS X 10.2 > Mac OS X 10.3 > Mac OS X 10.4 > Mac OS X 10.5 > Mac OS X 10.6 > > We'd have: > Windows (All versions) > Mac OS X > > I meant to do this a while ago, but forgot, and > http://bugs.winehq.org/show_bug.cgi?id=27930 reminded me > > -- > -Austin > > > http://www.winehq.org/pipermail/wine-devel/2008-November/070494.html While we're at it, can we take care of http://bugs.winehq.org/show_bug.cgi?id=24411 ? Priority / Difficulty / Whiteboard have to be disablable somewhere. Jerome

July 28, 2011

bugzilla: merge OS X/Windows OS versions

by Austin English

This was mentioned a while back, though I can't find the reference on wine-devel, perhaps it was in #winehackers... Anyway, would anyone be opposed to merging the Mac OS X versions (and possibly the Windows versions) in the OS field in Bugzilla? We don't differentiate any other OS, and for Windows, there are very few bugs filed anyway (mostly against the test suite or building on cygwin). So, instead of: Windows 3.1 Windows 95 Windows 98 Windows ME Windows 2000 Windows NT Windows XP Windows Vista Mac OS X 10.2 Mac OS X 10.3 Mac OS X 10.4 Mac OS X 10.5 Mac OS X 10.6 We'd have: Windows (All versions) Mac OS X I meant to do this a while ago, but forgot, and http://bugs.winehq.org/show_bug.cgi?id=27930 reminded me -- -Austin

July 28, 2011

Re: gsoc mentor summit

by Juan Lang

>> I'd be interested if there's a space going free. We just get to send 2 >> mentors though as I understand it? > Yes. I'd be interested as well, that's why I started this thread. I've been > there already in 2009, so if anyone else wants to go I'd be happy to yield. Whoever does go, I'll be happy to meet. I'm just down the road at Google. --Juan

July 28, 2011

Re: NtQuerySystemInformation needs a little bit more flesh for SystemProcessorPerformanceInformation

by Juan Lang

> This Reserved1[0] is the DPC Time but I'm wondering what values from > /proc/stat to use here (remainder[0] is I/O wait). We could always make up > something of course but being accurate would be nicer. DPC Time has no equivalent in /proc/stat. It's an NT thing. Making something up is the only appropriate thing, unless we start doing something special with DPCs someday. --Juan

July 28, 2011

Re: [PATCH 2/8] ntdll: rework the handling of server ioctls a little bit to avoid a crash with later patches

by Alexandre Julliard

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -1273,10 +1282,16 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, > > if (wait_handle) > { > - NtWaitForSingleObject( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT), NULL ); > - status = io->u.Status; > + status = NtWaitForSingleObject( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT), NULL ); > + if (status == STATUS_USER_APC) > + { > + async->interrupted = TRUE; > + status = STATUS_CANCELLED; /* not really, the ioctl completes and event and the handle > + itself get signaled */ > + } This looks wrong. You can't claim it was cancelled if it's still running. -- Alexandre Julliard julliard(a)winehq.org

July 28, 2011

Re: [5/7] cmd/tests: Add FOR /D tests

by Alexandre Julliard

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > --- > programs/cmd/tests/test_builtins.cmd | 6 ++++++ > programs/cmd/tests/test_builtins.cmd.exp | 11 +++++++++++ > 2 files changed, 17 insertions(+), 0 deletions(-) It fails here: ../../../tools/runtest -q -P wine -M cmd.exe -T ../../.. -p cmd.exe_test.exe.so batch.c && touch batch.ok batch.c:239: Test succeeded inside todo block: unexpected char 0x0 position -1 in line 225 (got 'baz', wanted 'baz') make: *** [batch.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

July 28, 2011