June 2010 - Wine-devel - list.winehq.org

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.
by Henri Verbeet 16 Jun '10

16 Jun '10

I forgot to mention this, but this fixes a regression introduced by commit e6611e22fb037a879205f1330d1a3485f9f18705.

1 0

Re: [RESEND 2] Changes to enable the use of gcov and PGO
by Alexandre Julliard 16 Jun '10

16 Jun '10

Peter Davies <ultratwo(a)gmail.com> writes: > @@ -72,7 +72,7 @@ MAKECTESTS = $(TOOLSDIR)/tools/make_ctests$(TOOLSEXT) > WRC = $(TOOLSDIR)/tools/wrc/wrc$(TOOLSEXT) > WMC = $(TOOLSDIR)/tools/wmc/wmc$(TOOLSEXT) > WIDL = $(TOOLSDIR)/tools/widl/widl$(TOOLSEXT) > -WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ > +WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ $(LDFLAGS) LDFLAGS are already passed to winegcc where appropriate. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Anotated 'make test' log
by Max TenEyck Woodbury 16 Jun '10

16 Jun '10

Dan wrote: > OK. I'd suggest starting by looking at > http://bugs.winehq.org/show_bug.cgi?id=15435 > "Wine logs too verbose, quieter fixme's needed" and sending > in a patch to make one of the overly-verbose fixme's a bit > quieter. Thanks. I'll look at it. > Also, check your mail system; I can't email to you directly, > it bounces. And that's going to be a problem communicating > with other developers. A system disk failed this past weekend and I've been trying to get everything back up. I got test messages through starting about two hours ago. I've been checking the mailing list archive. (Yes, messages do not get properly threaded that way.) I'm also in the process of reinstalling much software. That machine is not very fast... - Max

1 1

Re: [2/9] setupapi: Validate the cabinet filename parameter in SetupIterateCabinetA.
by Alexandre Julliard 16 Jun '10

16 Jun '10

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > dlls/setupapi/setupcab.c | 7 ++- > dlls/setupapi/tests/Makefile.in | 1 + > dlls/setupapi/tests/setupcab.c | 121 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 128 insertions(+), 1 deletions(-) > create mode 100644 dlls/setupapi/tests/setupcab.c It doesn't work here: wine: Unhandled page fault on write access to 0x6864dd7b at address 0x686a1c89 (thread 003a), starting debugger... Unhandled exception: page fault on write access to 0x6864dd7b in 32-bit code (0x686a1c89). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686a1c89 ESP:0032f6e0 EBP:0032fa68 EFLAGS:00010246( R- -- I Z- -P- ) EAX:6864dd7b EBX:686b2cfc ECX:00000000 EDX:00000024 ESI:6865d68f EDI:0032f838 Stack dump: 0x0032f6e0: 0032f93c 6864dd7b 0032f838 0032fa4c 0x0032f6f0: 686a14e0 00000000 0032f724 ffffffff 0x0032f700: 0032fa40 0032f9e4 0032f768 7bc70be0 0x0032f710: 0000000e 00000002 00000001 0032f93c 0x0032f720: 00110060 acabfeed 00121100 00000000 0x0032f730: 00000000 00038080 2e366338 00706d74 Backtrace: =>0 0x686a1c89 SetupIterateCabinetA+0xc9(CabinetFile="", Reserved=0, MsgHandler=0x6864b9a0, Context=0x0(nil)) [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi (0x0032fd38) 1 0x6864bd95 test_invalid_parametersA+0x384() [/home/julliard/wine/wine/dlls/setupapi/tests/setupcab.c:108] in setupapi_test (0x0032fd88) 2 0x6864df0e run_test+0x14d(name=<is not available>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:557] in setupapi_test (0x0032fe48) 3 0x6864e0e2 main+0x131(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:607] in setupapi_test (0x0032fe90) 4 0x6864e27c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in setupapi_test (0x0032fea8) 5 0x7b854ebc call_process_entry+0xb() in kernel32 (0x0032fee8) 6 0x7b85756b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:996] in kernel32 (0x0032fef8) 7 0x7bc71a40 call_thread_func+0xb() in ntdll (0x0032ffc8) 8 0x7bc71c10 call_thread_entry_point+0x6f(entry=0x7b857510, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2466] in ntdll (0x0032ffe8) 9 0x7bc4d5ca start_process+0x29(kernel_start=0x7b857510) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x00000000) 0x686a1c89 SetupIterateCabinetA+0xc9 [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi: movb $0x0,0x0(%eax) 588 *p = '\0'; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: try to not raise exceptions when checking for atl thunks
by Alexandre Julliard 16 Jun '10

16 Jun '10

Markus Amsler <markus.amsler(a)oribi.org> writes: > + * Windows checks the following conditions before emulating an ATL thunk: > + * - DEP policy allows emulating > + * - thunk has memory type MEM_PRIVATE and is readable > + * - jmp func is executable > + * - thunk signature (movl, jmp) matches > + * - a "secret" flag is set: > + * The flag gets set before calling WndProc and cleared after WndProc > + * or a thunk was emulated. > + * In Windows XP SP 3 this flag is located at TEB+0xfb4. > */ Where does that information come from? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: kernel32: stop CopyFile from overwriting a file with itself
by Alexandre Julliard 16 Jun '10

16 Jun '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > + if (h2 != INVALID_HANDLE_VALUE) > + { > + BY_HANDLE_FILE_INFORMATION info2; > + if (GetFileInformationByHandle( h2, &info2 )) > + { > + if (info.dwVolumeSerialNumber == info2.dwVolumeSerialNumber && > + info.nFileIndexLow == info2.nFileIndexLow && > + info.nFileIndexHigh == info2.nFileIndexHigh) The volume serial number is not the appropriate check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior
by testbot＠testbot.winehq.org 16 Jun '10

16 Jun '10

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=2695 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W7PROX64 (64 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

1 0

Re: winex11.drv: Post a WM_SYSCOMMAND SC_CLOSE when the Window Manager asks to close a window
by Vitaliy Margolen 16 Jun '10

16 Jun '10

On 06/15/2010 05:36 AM, Paul Chitescu wrote: > Changelog: > winex11.drv: Post a WM_SYSCOMMAND SC_CLOSE when the Window Manager asks to > close a window > + GetCursorPos( &pt ); > + PostMessageW( hwnd, WM_SYSCOMMAND, SC_CLOSE, MAKELPARAM( pt.x, pt.y ) ); You can't do that. Cursor can be anywhere, even outside Wine when WM decides to remove Wine's window. According to MSDN (which means it requires validation) you can pass either -1 or 0 for lparam here. Otherwise I think WM_SYSCOMMAN should be the correct behavior. Vitaliy.

1 0

Re: [PATCH] winspool: Return ERROR_MORE_DATA, when the app probe for the needed buffersize [BUG 19624]
by testbot＠testbot.winehq.org 16 Jun '10

16 Jun '10

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=2686 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: propsys: mention that the functions are stubs
by James Mckenzie 15 Jun '10

15 Jun '10

Hans Leidekker <hans(a)codeweavers.com> wrote: > >On Tue, 2010-06-15 at 10:25 +0200, Francois Gouget wrote: > >> Just to confirm what André said, if the FIXME does not contain the word >> 'stub', then apistats has no way to know it's a (pseudo-)stub. > >Wouldn't it be sufficient for our purposes to just count every first >fixme in a WINAPI function as a stub? As it is now there's a large >percentage of fixmes that don't include the 'stub' keyword. > I tend to disagree. Stubs should be identified, if possible, for each call. Some calls will not activate a specific sequence of FIXMEs and in some cases, users have become confused as they don't have the technical knowledge to determine why their program is failing. > >> I would further argue that even a human reading the log would have no >> way to know as quite a few implemented functions still dump their parameters. >> So even for humans it's better to add 'stub' to the FIXME message. > >I'd say we need turn those into traces and add fixmes for the >unimplemented parts, if needed. > This actually might be better, but don't TRACES only appear if you are running in debug mode? We do want to inform our user base that a failure happened due to partially implemented code rather than give them the impression that we don't care or only implement code to make certain programs work (hacky code...) Note: This is only a statement of opinion, not a request for direction within the project. If a fixme had 'stub' that means that we have implemented code to 'fake' windows functionality, whereas a real fixme means there is a problem with the code and it needs to be corrected. James McKenzie

2 1