October 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 1/5] shlwapi: Improved SHGetShellKey implementation

by testbot＠testbot.winehq.org

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=6117 Your paranoid android. === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1789: Test failed: got 29 ordinal.c:1839: Test failed: got 29 ordinal.c:1847: Test failed: got 29 ordinal.c:1855: Test failed: got 40, length 41 ordinal.c:1866: Test failed: got 43 === W7PROX64 (64 bit ordinal) === ordinal.c:1783: Test failed: got 10 ordinal.c:1804: Test failed: got 7 ordinal.c:1817: Test failed: got 10 ordinal.c:1825: Test failed: got 10 ordinal.c:1855: Test failed: got 36, length 37 ordinal.c:1866: Test failed: got 39 ordinal.c:1877: Test failed: got 21 ordinal.c:1888: Test failed: got 24

Oct. 12, 2010

Accessibility in wine

by Seth Shelnutt

I can't seem to find much info on this. What is wine's support for MSAA or the newer UIAutomation? I see that there is the oleacc dll which is the main dll for MSAA. According to the API site, is seems there are still 10 stubs. Looking at the source code there hasn't been any updates in over a year. We don't have the UIAutomation dll yet. Does anyone know the status of MSAA/UIAutomation support in wine? I'm trying to get NVDA working and still running into some issues with it requiring UIAutomation.dll, when according to them, that dll is optional. After I get that worked out I'm hoping to see what needs to be done to get MSAA supported under wine. Thanks, Seth Shelnutt

Oct. 12, 2010

Re: [PATCH 1/5] ddraw: Use a linear filter in ddraw_surface7_Blt().

by Stefan Dösinger

Am 12.10.2010 um 14:39 schrieb Henri Verbeet: > On 12 October 2010 14:34, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> >> Am 12.10.2010 um 13:40 schrieb Henri Verbeet: >>> + hr = IWineD3DSurface_Blt(This->WineD3DSurface, DestRect, Src ? Src->WineD3DSurface : NULL, >>> + SrcRect, Flags, (WINEDDBLTFX *)DDBltFx, WINED3DTEXF_LINEAR); >> Why do you think a linear filter is correct? I was under the impression that ddraw only uses point filters. >> > http://bugs2.winehq.org/attachment.cgi?id=31177 Ok

Oct. 12, 2010

Re: [PATCH 1/5] ddraw: Use a linear filter in ddraw_surface7_Blt().

by Henri Verbeet

On 12 October 2010 14:34, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am 12.10.2010 um 13:40 schrieb Henri Verbeet: >> + hr = IWineD3DSurface_Blt(This->WineD3DSurface, DestRect, Src ? Src->WineD3DSurface : NULL, >> + SrcRect, Flags, (WINEDDBLTFX *)DDBltFx, WINED3DTEXF_LINEAR); > Why do you think a linear filter is correct? I was under the impression that ddraw only uses point filters. > http://bugs2.winehq.org/attachment.cgi?id=31177

Oct. 12, 2010

Re: [PATCH 1/5] ddraw: Use a linear filter in ddraw_surface7_Blt().

by Stefan Dösinger

Am 12.10.2010 um 13:40 schrieb Henri Verbeet: > + hr = IWineD3DSurface_Blt(This->WineD3DSurface, DestRect, Src ? Src->WineD3DSurface : NULL, > + SrcRect, Flags, (WINEDDBLTFX *)DDBltFx, WINED3DTEXF_LINEAR); Why do you think a linear filter is correct? I was under the impression that ddraw only uses point filters.

Oct. 12, 2010

Re: setupapi/tests: Fix wow64 failures

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > This removes problems on wow64 on windows platforms (wine can't even handle the normal case yet) > See http://test.winehq.org/data/tests/setupapi:devinst.html > --- > dlls/setupapi/tests/devinst.c | 44 +++++++++++++++++++++++++++-------------- > 1 files changed, 29 insertions(+), 15 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M setupapi.dll -T ../../.. -p setupapi_test.exe.so devinst.c && touch devinst.ok devinst.c:1120: Test succeeded inside todo block: Unexpected path \\?\ROOT#LEGACY_BOGUS#0001#{6A55B5A4-3F65-11DB-B704-0011955C2BDB} make[1]: *** [devinst.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2010

Re: [1/2] d3dx9/tests: Fix a failure on 64 bits.

by Alexandre Julliard

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > @@ -131,7 +131,9 @@ static void test_get_shader_constant_table_ex(void) > > /* With invalid CTAB data */ > hr = D3DXGetShaderConstantTableEx(shader_with_invalid_ctab, 0, &constant_table); > - ok(hr == D3DXERR_INVALIDDATA, "Got result %x, expected %x (D3DXERR_INVALIDDATA)\n", hr, D3DXERR_INVALIDDATA); > + /* Native on 64 bit doesn't check for invalid data */ > + ok(hr == D3DXERR_INVALIDDATA || (hr == D3D_OK && sizeof(DWORD) != sizeof(DWORD_PTR)), > + "Got result %x, expected %x (D3DXERR_INVALIDDATA)\n", hr, D3DXERR_INVALIDDATA); This doesn't seem to have much to do with 64-bit, it looks more like a broken implementation. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2010

Re: libs/wine: make lack of LDT support an #error

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > Nothing runs without it. The error is pretty obvious, I don't think there's a need to break the build. Besides, you don't need LDT for 32-bit apps if you have GDT support. -- Alexandre Julliard julliard(a)winehq.org

Oct. 12, 2010

Re: LLVM compilation

by Ricardo Filipe

2010/10/12 Austin English <austinenglish(a)gmail.com>: > On Mon, Oct 11, 2010 at 8:18 AM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> On 10/11/10 8:54 AM, Jeff Cook wrote: >>> Just wondering if anyone has experimented building WINE with LLVM >>> instead of GCC. >> I have. It's how I got involved in LLVM in the first place :). My very >> first post to cfe-dev (the Clang development mailing list) was, in fact, >> asking about building Wine with Clang. >>> If so, what results were gotten? >> After I fixed Clang (yes, I fixed Clang; I even have commit access to >> their repository), it was able to build Wine, but the resulting Wine >> didn't behave quite right compared to GCC-compiled Wine. Clang and LLVM >> have come a long way since then--this was about a year ago, just so you >> know--so I'm going to try again right now. >> >> You can ask Austin English, too. He builds Wine with Clang and sends >> patches to fix the warnings Clang reports. >>> My understanding is that WINE tries hard >>> to be pretty portable and non-GCC-specific, so I would expect good >>> results... > > Charles would be the one to thank for most of the fixes (to Clang and > Wine). Henri Verbeet and Ricardo Filipe sent quite a few patches as > well. All of them can be found here: > > http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=llvm|cla… > > For its current status, my test scripts builds wine daily with gcc and > clang and submits test results. You can compare them here (for today's > results): > http://test.winehq.org/data/9d18f10a0d1f2d39f6f47fd4b0f439e9fffd20b2/index_… > > look for 'ae-ub1004' for the plain gcc versus 'ae-ub1004-clang' for > clang. Currently, gcc fails 8 tests for me, clang fails 15. > > -- > -Austin > > > to be clear, my patches and henri's were mostly cleanups and wine bug fixes found with clang's analysis tool. not really fixes to build with llvm/clang.

Oct. 11, 2010

Re: LLVM compilation

by Austin English

On Mon, Oct 11, 2010 at 8:18 AM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On 10/11/10 8:54 AM, Jeff Cook wrote: >> Just wondering if anyone has experimented building WINE with LLVM >> instead of GCC. > I have. It's how I got involved in LLVM in the first place :). My very > first post to cfe-dev (the Clang development mailing list) was, in fact, > asking about building Wine with Clang. >> If so, what results were gotten? > After I fixed Clang (yes, I fixed Clang; I even have commit access to > their repository), it was able to build Wine, but the resulting Wine > didn't behave quite right compared to GCC-compiled Wine. Clang and LLVM > have come a long way since then--this was about a year ago, just so you > know--so I'm going to try again right now. > > You can ask Austin English, too. He builds Wine with Clang and sends > patches to fix the warnings Clang reports. >> My understanding is that WINE tries hard >> to be pretty portable and non-GCC-specific, so I would expect good >> results... Charles would be the one to thank for most of the fixes (to Clang and Wine). Henri Verbeet and Ricardo Filipe sent quite a few patches as well. All of them can be found here: http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=llvm|cla… For its current status, my test scripts builds wine daily with gcc and clang and submits test results. You can compare them here (for today's results): http://test.winehq.org/data/9d18f10a0d1f2d39f6f47fd4b0f439e9fffd20b2/index_… look for 'ae-ub1004' for the plain gcc versus 'ae-ub1004-clang' for clang. Currently, gcc fails 8 tests for me, clang fails 15. -- -Austin

Oct. 11, 2010

Re: IDE for Wine Development?

by Frédéric Delanoy

2010/10/10 André Hentschel <nerv(a)dawncrow.de> > Am 10.10.2010 13:01, schrieb GOUJON Alexandre: > > On 10/09/2010 11:50 PM, Evil Jay wrote: > >> My question is: Which IDE/editors do you "real" devs prefer for your > >> work on Wine? > > It depends on you. > True! > I didn't want a heavy IDE nor a "complicated" console app. So i did all my > Wine work (small and big changes) with Geany. Yeah, geany is pretty neat. Although I find scite a good choice, especially with its simple "code folding" feature (which you can't do in geany TMK)

Oct. 11, 2010

Re: [1/2] kernel32: Implement GetSystemRegistryQuota as a semi-stub.

by Andrew Nguyen

On 10/11/2010 09:52 AM, (Marvin) wrote: > 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=6079 > > Your paranoid android. > > > === W98SE (32 bit process) === > Failure running script in VM: Exceeded timeout limit of 315 sec I don't see a crash in the W98SE log. For whatever reason, the W98SE VM doesn't seem to recognize that the process tests have completed.

Oct. 11, 2010

Re: LLVM compilation

by Charles Davis

On 10/11/10 8:54 AM, Jeff Cook wrote: > Just wondering if anyone has experimented building WINE with LLVM > instead of GCC. I have. It's how I got involved in LLVM in the first place :). My very first post to cfe-dev (the Clang development mailing list) was, in fact, asking about building Wine with Clang. > If so, what results were gotten? After I fixed Clang (yes, I fixed Clang; I even have commit access to their repository), it was able to build Wine, but the resulting Wine didn't behave quite right compared to GCC-compiled Wine. Clang and LLVM have come a long way since then--this was about a year ago, just so you know--so I'm going to try again right now. You can ask Austin English, too. He builds Wine with Clang and sends patches to fix the warnings Clang reports. > My understanding is that WINE tries hard > to be pretty portable and non-GCC-specific, so I would expect good > results... This was my experience of about a year ago: Wine uses--uh, used (does it still use?)--the 'static inline' extension of GCC, which I had to implement in Clang because it claims to be GCC. The other Clang devs were not pleased that I had to do that. I also had to fix Clang to respect function pointers' declared calling convention. Before then, you got tons of warnings when you compiled Wine with Clang, because Clang would ignore the numerous __stdcall keywords in the function pointer declarations. And that was a symptom of a bigger problem where Clang wouldn't code-gen calls through those function pointers right. It took me a while to get that one right. Another time, I implemented the 'force_align_arg_pointer' attribute in Clang (as well as the backend stuff in LLVM), which Wine needs to work right on Mac OS X. The other Clang devs all pressured me ("+1! That's an excellent idea!") to warn when the attribute was used on a function pointer, where it is useless. So I did. Then I sent a patch to Wine to disable it, but AJ stepped in and pressured me to take it out. After explaining his position to the other Clang devs (basically, it boiled down to "warning about this is stupid, especially if GCC doesn't warn and Clang claims to be GCC"), they let me take it out. Also, for a short time you had to tell Clang to compile in gnu89 mode instead of gnu99; Wine was not yet C99 compliant then. Chip

Oct. 11, 2010

Re: LLVM compilation

by Detlef Riekenberg

On Mon, 2010-10-11 at 08:54 -0600, Jeff Cook wrote: > Just wondering if anyone has experimented building WINE with LLVM > instead of GCC. Yes, several people used LLVM/CLANG for Wine and send patches. >From the commits: http://source.winehq.org/git/wine.git/?a=search&st=commit&s=CLANG&sr=1 You are welcome to Help. -- By by ... Detlef

Oct. 11, 2010

Re: LLVM compilation

by Damjan Jovanovic

On Mon, Oct 11, 2010 at 4:54 PM, Jeff Cook <jeff(a)deserettechnology.com> wrote: > Just wondering if anyone has experimented building WINE with LLVM > instead of GCC. For those who haven't been following it closely, > LLVM/Clang is fairly mature now and can now build some really mammoth > projects. Has anyone experimented in building WINE with LLVM/Clang? If > so, what results were gotten? My understanding is that WINE tries hard > to be pretty portable and non-GCC-specific, so I would expect good > results... Wine is mostly used and developed on Linux, so parts of it were fairly GCC specific, but I think most of it has been fixed by now so its compatible with LLVM/clang. Have a look at the Wiki page as well: http://wiki.winehq.org/Clang > Thanks > From > Jeff > > > Damjan Jovanovic

Oct. 11, 2010

LLVM compilation

by Jeff Cook

Just wondering if anyone has experimented building WINE with LLVM instead of GCC. For those who haven't been following it closely, LLVM/Clang is fairly mature now and can now build some really mammoth projects. Has anyone experimented in building WINE with LLVM/Clang? If so, what results were gotten? My understanding is that WINE tries hard to be pretty portable and non-GCC-specific, so I would expect good results... Thanks From Jeff

Oct. 11, 2010

Re: [1/2] kernel32: Implement GetSystemRegistryQuota as a semi-stub.

by testbot＠testbot.winehq.org

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=6079 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

Oct. 11, 2010

Re: [6/6] msi/tests: Reduce the UI level for a couple of tests.

by testbot＠testbot.winehq.org

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=6078 Your paranoid android. === W2K8SE (32 bit install) === Timeout

Oct. 11, 2010

Re: [2/3] msxml3/httprequest: Implement POST support with supplied body data

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Implement POST support with supplied body data It crashes here: ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok wine: Unhandled page fault on read access to 0x00610054 at address 0x556c7d55 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00610054 in 32-bit code (0x556c7d55). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:556c7d55 ESP:0032fad0 EBP:0032fb28 EFLAGS:00010202( R- -- I - - - ) EAX:00130f98 EBX:5570b4ec ECX:0061004c EDX:000401e8 ESI:68f31924 EDI:0032fbd4 Stack dump: 0x0032fad0: 00130f98 001259d8 00000000 68f31924 0x0032fae0: 0032fb0c 0012b0a4 0032fb08 687e878b 0x0032faf0: 68894798 00000000 7bc49ceb 000401e8 0x0032fb00: 001329b8 00000000 0032fb68 00130f98 0x0032fb10: 001329b8 55704230 0032fbd8 5570b4ec 0x0032fb20: 68f31924 001329b8 0032fb88 556de570 Backtrace: =>0 0x556c7d55 bind_to_storage+0x145(url="http://crossover.codeweavers.com/xmltest.xml", pbc=0x1259d8, riid=0x68f31924, ppv=0x32fbd4) [/home/julliard/wine/wine/dlls/urlmon/binding.c:1623] in urlmon (0x0032fb88) 1 0x556de570 URLMoniker_BindToStorage+0x7f(iface=0x1329b8, pbc=0x1259d8, pmkToLeft=(nil), riid=0x68f31924, ppvObject=0x32fbd4) [/home/julliard/wine/wine/dlls/urlmon/umon.c:226] in urlmon (0x0032fbf8) 2 0x68f0ac2f httprequest_send+0x29e(iface=0x132560, body={n1={n2={vt=0, wReserved1=0, wReserved2=0x549f, wReserved3=0x7bc3, n3={cVal=-92, uiVal=0x25a4, ulVal=0x1325a4, intVal=0x1325a4, uintVal=0x1325a4, bVal=-92, iVal=0x25a4, lVal=0x1325a4, fltVal=0.000000, dblVal=115829032902964642774731102830373123138357386478391680597607917204841224939855876815354089977900578056271309531616954000897843059241707444154521072387433862091187643543289869583516710016022354436402931544267598795367270420594576483624868777837530808994684936908624353063660385789867458560.000000, boolVal=0x25a4, scode=0x1325a4, date=115829032902964642774731102830373123138357386478391680597607917204841224939855876815354089977900578056271309531616954000897843059241707444154521072387433862091187643543289869583516710016022354436402931544267598795367270420594576483624868777837530808994684936908624353063660385789867458560.000000, bstrVal="GET", cyVal={={Lo=0x1325a4, Hi=0x7b88577c}, int64=0x7b88577c001325a4}, punkVal=0x1325a4, pdispVal=0x1325a4, parray=0x1325a4, llVal=0x7b88577c001325a4, ullVal=0x7b88577c001325a4, pcVal="G", puiVal="GET", pulVal=0x1325a4, pintVal=0x1325a4, puintVal=0x1325a4, pbVal="G", piVal=0x1325a4, plVal=0x1325a4, pfltVal=0x1325a4, pdblVal=0x1325a4, pboolVal=0x1325a4, pscode=0x1325a4, pdate=0x1325a4, pbstrVal=0x1325a4, pvarVal=0x1325a4, byref=0x1325a4, pcyVal=0x1325a4, pdecVal=0x1325a4, ppunkVal=0x1325a4, ppdispVal=0x1325a4, pparray=0x1325a4, pllVal=0x1325a4, pullVal=0x1325a4, brecVal={pvRecord=0x1325a4, pRecInfo=0x7b88577c}}}, decVal={wReserved=0, u={={scale=0, sign=0}, signscale=0}, Hi32=0x7bc3549f, u1={={Lo32=0x1325a4, Mid32=0x7b88577c}, Lo64=0x7b88577c001325a4}}}}) [/home/julliard/wine/wine/dlls/msxml3/httprequest.c:472] in msxml3 (0x0032fd38) 3 0x6868d935 func_domdoc+0x1104() [/home/julliard/wine/wine/dlls/msxml3/tests/domdoc.c:3370] in msxml3_test (0x0032fd88) 4 0x6869e92e run_test+0x15d(name=<is not available>) [/home/julliard/wine/wine/dlls/msxml3/tests/../../../include/wine/test.h:556] in msxml3_test (0x0032fe48) 5 0x6869eb27 main+0x156(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/msxml3/tests/../../../include/wine/test.h:624] in msxml3_test (0x0032fe90) 6 0x6869f6ac __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msxml3_test (0x0032fea8) 7 0x7b856cfc call_process_entry+0xb() in kernel32 (0x0032fee8) 8 0x7b8591fb start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:994] in kernel32 (0x0032fef8) 9 0x7bc72d30 call_thread_func+0xb() in ntdll (0x0032ffc8) 10 0x7bc72f00 call_thread_entry_point+0x6f(entry=0x7b8591a0, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0032ffe8) 11 0x7bc4db1a start_process+0x29(kernel_start=0x7b8591a0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2610] in ntdll (0x00000000) 0x556c7d55 bind_to_storage+0x145 [/home/julliard/wine/wine/dlls/urlmon/binding.c:1623] in urlmon: call *0x8(%ecx) 1623 IBinding_Release(BINDING(binding)); -- Alexandre Julliard julliard(a)winehq.org

Oct. 11, 2010

Re: d3dx9: Fix D3DXPlaneNormalize on 64 bits.

by Marcus Meissner

On Mon, Oct 11, 2010 at 03:53:21PM +0200, Matteo Bruni wrote: > 2010/10/11 Henri Verbeet <hverbeet(a)gmail.com>: > > On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > >> This patch changes D3DXPlaneNormalize to behave as native on 64 bits, > >> returning infinity in the fourth plane component when the norm is 0. > >> If this is not appropriate, I can resend without the implementation > >> changes, just fixing the tests. > >> > > I can't say this is necessarily wrong, but I do think it looks suspicious. > > > > It looked strange to me too. But that is what I get here with native > dlls and what 64 bit testbot machines return, so I assumed it to be > some sort of "bug" of native 64 bit d3dx9_36.dll. > Then I checked today's winetest results and it seems like native > actually doesn't always have this broken behavior: > http://test.winehq.org/data/0cc9c52f8c5ad5e1f821177f165fbb72be90d2d9/index_… > shows that Wylda's 64 bits machines don't fail the math test (while > still failing the shader test fixed by my other patch). A peek into > the version informations of these tests shows that d3dx9_36.dll > version matches the one used in testbot virtual machines (as expected) > but there is no d3dcompiler_43.dll, so probably Wylda has an older > version of the DX SDK installed. > That said, I don't know why this could happen. Given that the current > output of our D3DXPlaneNormalize is arguably the best one, I'd just > send a patch to accept both results in the tests without changing the > implementation. Unless you have some idea, of course... If you are passing floats or doubles as functions arguments, this might happen if the compiler is not yet fixed (there were some issues I vaguely remember). Ciao, Marcus

Oct. 11, 2010

Re: [5/6] msi/tests: Set the MSIFASTINSTALL property.

by testbot＠testbot.winehq.org

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=6077 Your paranoid android. === WXPPROSP3 (32 bit install) === Timeout

Oct. 11, 2010

Re: d3dx9: Fix D3DXPlaneNormalize on 64 bits.

by Matteo Bruni

2010/10/11 Henri Verbeet <hverbeet(a)gmail.com>: > On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> This patch changes D3DXPlaneNormalize to behave as native on 64 bits, >> returning infinity in the fourth plane component when the norm is 0. >> If this is not appropriate, I can resend without the implementation >> changes, just fixing the tests. >> > I can't say this is necessarily wrong, but I do think it looks suspicious. > It looked strange to me too. But that is what I get here with native dlls and what 64 bit testbot machines return, so I assumed it to be some sort of "bug" of native 64 bit d3dx9_36.dll. Then I checked today's winetest results and it seems like native actually doesn't always have this broken behavior: http://test.winehq.org/data/0cc9c52f8c5ad5e1f821177f165fbb72be90d2d9/index_… shows that Wylda's 64 bits machines don't fail the math test (while still failing the shader test fixed by my other patch). A peek into the version informations of these tests shows that d3dx9_36.dll version matches the one used in testbot virtual machines (as expected) but there is no d3dcompiler_43.dll, so probably Wylda has an older version of the DX SDK installed. That said, I don't know why this could happen. Given that the current output of our D3DXPlaneNormalize is arguably the best one, I'd just send a patch to accept both results in the tests without changing the implementation. Unless you have some idea, of course...

Oct. 11, 2010

Re: [1/6] msi/tests: Determine Wow64 mode just once.

by testbot＠testbot.winehq.org

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=6073 Your paranoid android. === W2K8SE (32 bit install) === Timeout === W7PROX64 (64 bit install) === install.c:10489: Test failed: key not created

Oct. 11, 2010

Re: [PATCH 1/5] d3dcompiler_43/tests: Added HLSL test suite

by Henri Verbeet

On 7 October 2010 19:49, Travis Athougies <iammisc(a)gmail.com> wrote: > +/* Draw a full screen quad */ > +static void draw_quad_with_shader9(IDirect3DDevice9 *device, IDirect3DVertexBuffer9 *quad_geometry) > +{ > + HRESULT hr; > + D3DXMATRIX projection_matrix; > + > + D3DXMatrixOrthoLH(&projection_matrix, 2.0f, 2.0f, 0.0f, 1.0f); > + IDirect3DDevice9_SetTransform(device, D3DTS_PROJECTION, &projection_matrix); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0); > + ok(hr == D3D_OK, "IDirect3DDevice9_Clear returned: %08x\n", hr); > + > + hr = IDirect3DDevice9_BeginScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_BeginScene returned: %08x\n", hr); > + > + hr = IDirect3DDevice9_SetStreamSource(device, 0, quad_geometry, 0, sizeof(struct vertex)); > + ok(hr == D3D_OK, "IDirect3DDevice9_SetStreamSource returned: %08x\n", hr); > + hr = IDirect3DDevice9_DrawPrimitive(device, D3DPT_TRIANGLESTRIP, 0, 2); > + ok(hr == D3D_OK, "IDirect3DDevice9_DrawPrimitive returned: %08x\n", hr); > + > + hr = IDirect3DDevice9_EndScene(device); > + ok(hr == D3D_OK, "IDirect3DDevice9_EndScene returned: %08x\n", hr); > + > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(hr == D3D_OK, "IDirect3DDevice9_Present returned: %08x\n", hr); > +} > + Backbuffer contents are undefined after present.

Oct. 11, 2010

Re: d3dx9: Fix D3DXPlaneNormalize on 64 bits.

by Henri Verbeet

On 8 October 2010 16:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > This patch changes D3DXPlaneNormalize to behave as native on 64 bits, > returning infinity in the fourth plane component when the norm is 0. > If this is not appropriate, I can resend without the implementation > changes, just fixing the tests. > I can't say this is necessarily wrong, but I do think it looks suspicious.

Oct. 11, 2010

Re: ddraw/test: Add more combinaison tests for SetCooperativeLevels

by testbot＠testbot.winehq.org

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=6071 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Oct. 11, 2010

Re: cabinet/tests: Reformated output in case of test failure (try 3)

by Alexandre Julliard

Marko Nikolic <grkoma(a)gmail.com> writes: > @@ -109,9 +109,9 @@ static void test_FDICreate(void) > ok(hfdi != NULL, "Expected non-NULL context\n"); > ok(GetLastError() == 0xdeadbeef, > "Expected 0xdeadbeef, got %d\n", GetLastError()); > - ok(erf.erfOper == 0x1abe11ed, "Expected 0x1abe11ed, got %d\n", erf.erfOper); > - ok(erf.erfType == 0x5eed1e55, "Expected 0x5eed1e55, got %d\n", erf.erfType); > - ok(erf.fError == 0x1ead1e55, "Expected 0x1ead1e55, got %d\n", erf.fError); > + ok(erf.erfOper == 0x1abe11ed, "Expected 0x1abe11ed, got %x\n", erf.erfOper); > + ok(erf.erfType == 0x5eed1e55, "Expected 0x5eed1e55, got %x\n", erf.erfType); > + ok(erf.fError == 0x1ead1e55, "Expected 0x1ead1e55, got %x\n", erf.fError); Most of these are error codes too, they should be in decimal. I don't see why you want to change this at all. If you think having the expected value printed in hex is confusing just get rid of it, it's useless anyway. -- Alexandre Julliard julliard(a)winehq.org

Oct. 11, 2010

Re: cmd: Add a space at the end of the first echo'ed batch line [try3]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -11,6 +25,8 @@ echo. > echo . > echo.word > echo .word > +echo word > +echo word You need some escaping mechanism for these trailing spaces too. -- Alexandre Julliard julliard(a)winehq.org

Oct. 11, 2010

Re: toolhelp: Document InterruptRegister16

by Alexandre Julliard

Thomas Bleher <ThomasBleher(a)gmx.de> writes: > @@ -593,6 +593,29 @@ BOOL16 WINAPI StackTraceNext16(STACKTRACEENTRY *ste) > > /*********************************************************************** > * InterruptRegister (TOOLHELP.75) > + * > + * Registers a callback to intercept certain special events from any process. > + * > + * The special events are (TODO: There may be other events not listed here; > + * these are the ones documented in the patent mentioned below): These are standard x86 traps, they don't need special constants or documentation. Besides, if there's really a patent about this we can't implement it anyway. -- Alexandre Julliard julliard(a)winehq.org

Oct. 11, 2010

Re: [PATCH] winealsa.drv: Count micelem in mixer chans, don't add spare capture input for half-duplex mics.

by Jeff Cook

On Wed, Sep 1, 2010 at 9:40 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > This statement wasn't exactly clear before, but now it's really > impossible to follow. Please rewrite this in a way that makes sense to a > casual reader. I have rewritten this in a more readable way and submitted the result to wine-patches. See http://source.winehq.org/patches/data/67063 . -Jeff

Oct. 11, 2010

Re: [PATCH] riched20/tests: Cleaned up ITextServices::TxGetNaturalSize test and fixed test failures. (try 2)

by Austin Lund

On 11 October 2010 13:46, Austin Lund <austin.lund(a)gmail.com> wrote: > > + todo_wine ok(result == S_OK || broken(result == E_FAIL), /* WINXP Arabic Language */ > + "TxGetNaturalSize gave unexpected return value (result = %x)\n", result); I know it's slightly unorthodox to reply to your own patch, but if anyone can throw any light on why this fails for this version of windows it would be much appreciated. My guess is a problem with RTL fonts, but I'm not sure.

Oct. 11, 2010

Re: iphlpapi: Use Windows rather than Unix values to determine family

by Lats

On 10/11/2010 04:40 AM, André Hentschel wrote: > Hi "lats", > you should please provide your real name in your mail, otherwise your patch has bad chances to get in. > Normally you can configure git, so that it reports your name in the "From:" field. Sorry about that but I have been building another machine and that bit slipped through Jeff Latimer

Oct. 11, 2010

RFC: Patch to implement WSARecvMsg and IP_PKTINFO

by Erich Hoover

While searching for something else I discovered a bug relevant to the interface-bound UDP broadcast patches I've been working on. Apparently, IP_PKTINFO does work on Windows when used with the WSARecvMsg function (Bug #19493). I've attached a patch to address this issue (including tests), and I would appreciate any comments on it. This patch approaches the problem by: 1) Implementing WSARecvMsg through WS2_recvfrom 2) Passing the control buffer as an additional WSABUF with an internal flag (cleared internally to prevent confusing applications) 3) Converting the returned Unix IP_PKTINFO data to the equivalent Windows version in WS2_recv() by utilizing a temporary buffer Thanks in advance for your feedback. Erich Hoover ehoover(a)mines.edu

Oct. 11, 2010

Re: urlmon: Added ProtocolStream_Stat implementation.

by testbot＠testbot.winehq.org

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=6022 Your paranoid android. === WVISTAADM (32 bit url) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Oct. 10, 2010

Re: user32/tests: Test FindWindowEx for empty window title (try 3)

by testbot＠testbot.winehq.org

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=6017 Your paranoid android. === W98SE (32 bit win) === win.c:2970: Test failed: message 000f available win.c:2982: Test failed: message 000f available win.c:2991: Test failed: message 000f available win.c:3000: Test failed: message 000f available === W7PROX64 (64 bit win) === win.c:2684: Test failed: GetActiveWindow() = 0000000000000000 win.c:2684: Test failed: GetFocus() = 0000000000000000 win.c:2710: Test failed: GetActiveWindow() = 0000000000000000 win.c:2710: Test failed: GetFocus() = 0000000000000000 win.c:2769: Test failed: GetActiveWindow() = 0000000000000000 win.c:2769: Test failed: GetFocus() = 0000000000000000

Oct. 10, 2010

Re: iphlpapi: Use Windows rather than Unix values to determine family

by André Hentschel

Hi "lats", you should please provide your real name in your mail, otherwise your patch has bad chances to get in. Normally you can configure git, so that it reports your name in the "From:" field. -- Best Regards, André Hentschel

Oct. 10, 2010

Re: IDE for Wine Development?

by André Hentschel

Am 10.10.2010 13:01, schrieb GOUJON Alexandre: > On 10/09/2010 11:50 PM, Evil Jay wrote: >> My question is: Which IDE/editors do you "real" devs prefer for your >> work on Wine? > It depends on you. True! I didn't want a heavy IDE nor a "complicated" console app. So i did all my Wine work (small and big changes) with Geany. -- Best Regards, André Hentschel

Oct. 10, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Rudolf Mayerhofer

On Sunday 10 October 2010 18:43:25 Vitaliy Margolen wrote: > On 10/10/2010 03:42 AM, Rudolf Mayerhofer wrote: > > I haven't found out how to do this properly yet and i think that i > > definitely need help on that one (like an example) as my skills in C are > > not that good and all i manage to get when trying to allocate the stuff > > from the heap is a segfault. > > That's not an excuse to create static structure of arbitrary size. It is not, but the size should be large enough to support all systems for some time. I already asked for help how to do this with heap properly since i simply can't figure it out, sorry. > > I figured that one out, although it took me a while. > > No, you didn't. Try again. You duplicated exactly the same code. Did you look at try 8 ? I'm pretty sure i changed that part to a single while loop and checked the part for adding a dummy on non-numa systems with a separate if. If that's not what you meant could you please explain where the problem is (again) ?

Oct. 10, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Vitaliy Margolen

On 10/10/2010 03:42 AM, Rudolf Mayerhofer wrote: > I haven't found out how to do this properly yet and i think that i definitely > need help on that one (like an example) as my skills in C are not that good > and all i manage to get when trying to allocate the stuff from the heap is a > segfault. That's not an excuse to create static structure of arbitrary size. > I figured that one out, although it took me a while. No, you didn't. Try again. You duplicated exactly the same code. Vitaliy.

Oct. 10, 2010

Re: shlwapi: Skip more tests on too old shlwapi.dll.

by testbot＠testbot.winehq.org

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=6009 Your paranoid android. === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1796: Test failed: got 13 ordinal.c:1832: Test failed: got 13 ordinal.c:1877: Test failed: got 23 ordinal.c:1888: Test failed: got 26 === W7PROX64 (32 bit ordinal) === ordinal.c:1796: Test failed: got 13 ordinal.c:1832: Test failed: got 13 ordinal.c:1877: Test failed: got 21 ordinal.c:1888: Test failed: got 24 === W7PROX64 (64 bit ordinal) === ordinal.c:1783: Test failed: got 10 ordinal.c:1789: Test failed: got 26 ordinal.c:1796: Test failed: got 13 ordinal.c:1804: Test failed: got 7 ordinal.c:1817: Test failed: got 10 ordinal.c:1825: Test failed: got 10 ordinal.c:1832: Test failed: got 13 ordinal.c:1839: Test failed: got 26 ordinal.c:1847: Test failed: got 26 ordinal.c:1877: Test failed: got 21 ordinal.c:1888: Test failed: got 24

Oct. 10, 2010

Re: IDE for Wine Development?

by GOUJON Alexandre

On 10/09/2010 11:50 PM, Evil Jay wrote: > My question is: Which IDE/editors do you "real" devs prefer for your > work on Wine? It depends on you. I mean, some devs like auto-completion and will use an IDE (Eclipse, Code::Blocks, Dec-C++, NetBeans ... GIYF !) whereas others will prefer good text editors with a simple console. Personally, I'm using Gedit with gnome-terminal, they provide both tabs; and VirtualBox with a share folder if I need to test a cross-compiled test. And that's enough for me. > This topic doesn't seem to be mentioned in the dev > faq/guides on WineHQ. > Again, I think it's because it really depends on your habits. Do you prefer the assisted way with a wizard or something like that ? Or do you like the console and make all the steps yourself ? NB: I don't belong to Codeweavers team : this is just my personal thoughts about the topic

Oct. 10, 2010

Re: IDE for Wine Development?

by Jerome Leclanche

KDevelop is a great IDE to work on C/++ code in general; if you get crashes, you can try to compile it yourself, most of the time it's outdated packages. For small things I generally use Kate personally, but I know most wine devs are emacs or vim addicts. J. Leclanche On Sat, Oct 9, 2010 at 10:50 PM, Evil Jay <evil(a)eternaldusk.com> wrote: > The small patches I've submitted previously have been very minor code > changes that I put together in a text editor. But today I've been > perusing the available bug list, and see a couple of more ambitious > things I would like to try to tackle. > > My question is: Which IDE/editors do you "real" devs prefer for your > work on Wine? This topic doesn't seem to be mentioned in the dev > faq/guides on WineHQ. I googled to see if others had asked before, but > if they did I must have not phrased my searches very well. > > I've been playing with KDevelop 4.0.2 for the last hour. It's > beautiful, but I haven't had the best experience with it: It randomly > crashed 3 times within a short period of first using it. Oddly, it's > not crashed since I restarted it from the command line so that I could > attempt to figure out what the problem is. > > -J > > >

Oct. 10, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Rudolf Mayerhofer

On Sunday 10 October 2010 00:26:45 you wrote: > On 10/09/2010 12:37 PM, Rudolf Mayerhofer wrote: > >>> +static SYSTEM_LOGICAL_PROCESSOR_INFORMATION cached_lpi[1024]; > >> > >> You think there are systems with that many CPUs running Wine? > > > > I honestly don't know the array is currently large enough to support > > 146 CPU's with 4 unique Caches (L1i,L1d,L2,L3), each in it's own > > processorpackage and numa node. This might be a bit of an overkill, > > any suggestions how many cpu's are used with wine in the worst case? > > Then you probably want to allocate it from the heap instead of creating a > static array. > I haven't found out how to do this properly yet and i think that i definitely need help on that one (like an example) as my skills in C are not that good and all i manage to get when trying to allocate the stuff from the heap is a segfault. For the time being i reduced the arraysize to 896, which should still be large enough to support 128 CPUs in SysFS in the worst case. > >> People already asked you not to do this. From looking at the code it > >> appears that there is always one node. So get rid of everything except > >> do{} while() block. It will do exactly what you want with extra if()s. > > > > This assumption is definitely wrong, on non-numa systems there is no node > > definition in SysFS. Windows on the same system shows one node and MSDN > > also hints that there should be a dummy node with number 0 and a > > processormask containing all known processors on the system in that > > case. > > I'm not talking about the content of the SysFS. I'm talking about what your > code does. If you remove that "if{} else{}" part and keep > "do{} while();" part as-is you will get exactly the same result. I figured that one out, although it took me a while.

Oct. 10, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Vitaliy Margolen

On 10/09/2010 12:37 PM, Rudolf Mayerhofer wrote: >>> +static SYSTEM_LOGICAL_PROCESSOR_INFORMATION cached_lpi[1024]; >> You think there are systems with that many CPUs running Wine? > I honestly don't know the array is currently large enough to support > 146 CPU's with 4 unique Caches (L1i,L1d,L2,L3), each in it's own > processorpackage and numa node. This might be a bit of an overkill, > any suggestions how many cpu's are used with wine in the worst case? Then you probably want to allocate it from the heap instead of creating a static array. >> People already asked you not to do this. From looking at the code it >> appears that there is always one node. So get rid of everything except >> do{} while() block. It will do exactly what you want with extra if()s. > > This assumption is definitely wrong, on non-numa systems there is no node > definition in SysFS. Windows on the same system shows one node and MSDN also > hints that there should be a dummy node with number 0 and a processormask > containing all known processors on the system in that case. I'm not talking about the content of the SysFS. I'm talking about what your code does. If you remove that "if{} else{}" part and keep "do{} while();" part as-is you will get exactly the same result. Vitaliy.

Oct. 9, 2010

IDE for Wine Development?

by Evil Jay

The small patches I've submitted previously have been very minor code changes that I put together in a text editor. But today I've been perusing the available bug list, and see a couple of more ambitious things I would like to try to tackle. My question is: Which IDE/editors do you "real" devs prefer for your work on Wine? This topic doesn't seem to be mentioned in the dev faq/guides on WineHQ. I googled to see if others had asked before, but if they did I must have not phrased my searches very well. I've been playing with KDevelop 4.0.2 for the last hour. It's beautiful, but I haven't had the best experience with it: It randomly crashed 3 times within a short period of first using it. Oddly, it's not crashed since I restarted it from the command line so that I could attempt to figure out what the problem is. -J

Oct. 9, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Rudolf Mayerhofer

>> +static SYSTEM_LOGICAL_PROCESSOR_INFORMATION cached_lpi[1024]; >You think there are systems with that many CPUs running Wine? I honestly don't know the array is currently large enough to support 146 CPU's with 4 unique Caches (L1i,L1d,L2,L3), each in it's own processorpackage and numa node. This might be a bit of an overkill, any suggestions how many cpu's are used with wine in the worst case? > > + if ((processormask = sysfs_numanode_cpumap(nodecount)) > 0) > > + { > > + /* Numa Nodes are already unique. just add them */ > > + do > > + { > > + } > > + while ((processormask = > > sysfs_numanode_cpumap(nodecount)) > 0); + } > > + else > > + { > > + } > > People already asked you not to do this. From looking at the code it > appears that there is always one node. So get rid of everything except > do{} while() block. It will do exactly what you want with extra if()s. This assumption is definitely wrong, on non-numa systems there is no node definition in SysFS. Windows on the same system shows one node and MSDN also hints that there should be a dummy node with number 0 and a processormask containing all known processors on the system in that case. I'll see that i can fix the rest of the things you mentioned and update the patch as soon as i can. Thanks for the quick review and sorry for the trouble.

Oct. 9, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)

by Vitaliy Margolen

On 10/08/2010 12:22 PM, Rudolf Mayerhofer wrote: > +static SYSTEM_LOGICAL_PROCESSOR_INFORMATION cached_lpi[1024]; You think there are systems with that many CPUs running Wine? > + for (i = 0; i < (sizeof(cached_lpi) / sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)); i++) To make it easier to understand what you doing here please calculate number of elements in cached_lpi array with: sizeof(cached_lpi) / sizeof(cached_lpi[0]); This way people don't need to look up what type cached_lpi is. > @@ -1069,6 +1193,160 @@ void fill_cpu_info(void) > } > } > fclose(f); > + > + /* Parse Logical Processor Information in SysFS */ > + { > + int coreflags = (cached_sci.FeatureSet & CPU_FEATURE_HTT) ? 1 : 0; > + int cpucount = 0, cachecount, nodecount, i; > + ULONG_PTR fullprocessormask = 0, processormask; > + Please don't do this. Don't create a block just so you can declare variables. Put variable declaration at the top of the outer block. > + while ((processormask = sysfs_cpu_topology_getmap(cpucount, "thread_siblings")) > 0) > + { > + /* Core information */ > + { > + /* Unique cores are found multiple times during iteration, add only once */ > + for (i = 0; i < (sizeof(cached_lpi) / sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)); i++) > + { ... > + } > + } ... > + } Same thing here. > +static int sysfs_cpucache_getint(int cpu, int cache, const char *type) > + /* Cache information */ > + cachecount = 0; > + while ((processormask = sysfs_cpucache_cpumap(cpucount, cachecount)) > 0) > + { > + /* Empty Processormasks are invalid, ignore them */ What does this comment refers too? If it's for the above while() condition, then please put comment above it, not inside the block. > + BYTE level = sysfs_cpucache_getint(cpucount, cachecount, "level"); > + BYTE associativity = sysfs_cpucache_getint(cpucount, cachecount, "ways_of_associativity"); > + WORD linesize = sysfs_cpucache_getint(cpucount, cachecount, "coherency_line_size"); > + DWORD size = sysfs_cpucache_getint(cpucount, cachecount, "size"); I've already told you before - do not mix signed and unsigned. If result of sysfs_cpucache_getint is always assigned to an unsigned variable then change it's return type to unsigned type too. > + /* Determine Cachetype */ > + if (typestring[0] == 'D') > + { > + type = CacheData; > + } > + else if (typestring[0] == 'I') > + { > + type = CacheInstruction; > + } > + else if (typestring[0] == 'U') > + { > + type = CacheUnified; > + } > + else if (typestring[0] == 'T') > + { > + type = CacheTrace; > + } Either use swith case construct here or use complete words and stricmp. > + if ((processormask = sysfs_numanode_cpumap(nodecount)) > 0) > + { > + /* Numa Nodes are already unique. just add them */ > + do > + { > + } > + while ((processormask = sysfs_numanode_cpumap(nodecount)) > 0); > + } > + else > + { > + } People already asked you not to do this. From looking at the code it appears that there is always one node. So get rid of everything except do{} while() block. It will do exactly what you want with extra if()s. Vitaliy.

Oct. 9, 2010

Re: cabinet/tests: Reformated output in case of test failure (try 2)

by Marko Nikolic

Alexandre Julliard wrote: > Marko Nikolic <grkoma(a)gmail.com> writes: > >> In case of test failure, expected and received values are traced. >> Format for the two values was different, corrected so both values >> are traced as hex. > > Error values are in general more useful in decimal. > You are right, I have removed format change for all error values.

Oct. 9, 2010

Re: Debugging 64-bit Wine Apps with winedbg

by Eric Pouech

Le 24/09/2010 05:12, Peter Urbanec a écrit : > > On 24/09/10 06:43, Eric Pouech wrote: >> sure send me the .exe+pdb (+source) I'll have a look at it > > Source and binaries sent to Eric in private, so that the list isn't > polluted with megabytes of binaries. If anyone else is interested in > having a copy, please let me know and I'll forward it in private. > > Cheers, > > Peter Urbanec > > > > with the patchset I've just sent, I get something like: > Thread 0x0021 sleeping 200ms > Thread 0x0022 sleeping 200ms > Thread 0x0020 sleeping 240ms > Thread 0x0023 sleeping 200ms > Thread 0x0021 *** C R A S H I N G *** > wine: Unhandled page fault on write access to 0x00000000 at address > 0x1400010b3 (thread 0021), starting debugger... > Thread 0x0022 *** C R A S H I N G *** > Thread 0x0023 *** C R A S H I N G *** > WineDbg starting on pid 001f > Thread 0x0020 *** C R A S H I N G *** > First chance exception: page fault on write access to 0x00000000 in > 64-bit code (0x00000001400010b3). > Register dump: > rip:00000001400010b3 rsp:00007feb8997fbb0 rbp:0000000140001a20 > eflags:00010202 ( R- -- I - - - ) > rax:0000000000000000 rbx:00007feb8bb55000 rcx:0000000140084478 > rdx:0000000140084480 > rsi:00007feb8b937401 rdi:00007feb8997fbe0 r8:0000000000000001 > r9:000000000010d640 r10:00007feb8997e850 > r11:00007feb8997e820 r12:0000000000000000 r13:000000007b86f590 > r14:00000001400000d8 r15:00007feb8bb50000 > Stack dump: > 0x00007feb8997fbb0: 000000014006ed20 0000000000000020 > 0x00007feb8997fbc0: 00007feb8997fa60 0000000000000028 > 0x00007feb8997fbd0: 00007feb8997fc30 cccccccc00000020 > 0x00007feb8997fbe0: 00007feb8997fce0 0000000140001223 > 0x00007feb8997fbf0: 00007feb8997fc30 0000000000000010 > 0x00007feb8997fc00: ccccccccffffffff 0000000140001014 > 0x00007feb8997fc10: cccccccc00000004 00007feb8997fc84 > 0x00007feb8997fc20: cccccccccccccccc cccccccccccccccc > 0x00007feb8997fc30: 000000f0cccccc01 0000000000000000 > 0x00007feb8997fc40: 000000c8cccccc01 0000000000000000 > 0x00007feb8997fc50: 000000c8cccccc01 0000000000000000 > 0x00007feb8997fc60: 000000c8cccccc01 0000000000000000 > Backtrace: > =>0 0x00000001400010b3 Boom::crash_func+0x83(void_ptr=0x7feb8997fc30, > arg_ref=0x7feb8997fc30, tid=32) > [z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29] > in multiplethreads (0x0000000140001a20) > 1 0x0000000140001223 main+0x142(argc=1, argv=0x7feb89771130, > thisThread=0xfffffffffffffffe, threadHandle={0x1c, 0x20, 0x24}, > threadID=35, oldpri=0, a={{cause_crash=true, delay=240, > pointer=0x0(nil)}, {cause_crash=true, delay=200, pointer=0x0(nil)}, > {cause_crash=true, delay=200, pointer=0x0(nil)}, {cause_crash=true, > delay=200, pointer=0x0(nil)}}) > [z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:63] > in multiplethreads (0x0000000140001a20) > 2 0x0000000140001c5c __tmainCRTStartup+0x21b(winver=1281, mainret=0, > osver=2600, winminor=1, posvi=0x7feb8ba24070, osplatform=2, > managedapp=0, initret=0, winmajor=5) > [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:327] in > multiplethreads (0x0000000140001a20) > 3 0x0000000140001a2e mainCRTStartup+0xd() > [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:195] in > multiplethreads (0x0000000140001a20) > 4 0x000000007b86f64f start_process+0xbe(peb=0x7feb8bb55000) > [/home/eric/work/wine/dlls/kernel32/process.c:963] in kernel32 > (0x0000000140001a20) > 5 0x00007feb8abfe43e call_thread_func+0x6d(entry=<is not available>, > arg=<is not available>, frame=<is not available>) > [/home/eric/work/wine/dlls/ntdll/signal_x86_64.c:3036] in ntdll > (0x0000000140001a20) > 6 0x00007feb8abfd73e call_thread_entry_point+0x29() in ntdll > (0x0000000140001a20) > 7 0x00007feb8abd0da6 start_process+0x15(kernel_start=0x7feb8997fec8) > [/home/eric/work/wine/dlls/ntdll/loader.c:2610] in ntdll > (0x0000000140001a20) > 8 0x00007feb8b611ea3 wine_call_on_stack+0x12() in libwine.so.1 > (0x0000000140001a20) > 9 0x00007feb8b611eb9 wine_switch_to_stack+0x8(func=0x7feb8997fec8, > arg=0x0(nil), stack=0x140084480) > [/home/eric/work/wine/libs/wine/port.c:83] in libwine.so.1 > (0x0000000140001a20) > 10 0x00007feb8abd5294 > LdrInitializeThunk+0x3d3(kernel_start=0x7b86f590, unknown2=<is not > available>, unknown3=<is not available>, unknown4=<is not available>) > [/home/eric/work/wine/dlls/ntdll/loader.c:2666] in ntdll > (0x0000000140001a20) > 11 0x000000007b874185 __wine_kernel_init+0x914() > [/home/eric/work/wine/dlls/kernel32/process.c:1163] in kernel32 > (0x0000000140001a20) > 12 0x00007feb8abd5824 __wine_process_init+0x253() > [/home/eric/work/wine/dlls/ntdll/loader.c:2876] in ntdll > (0x0000000140001a20) > 13 0x00007feb8b610a0f wine_init+0x28e(argc=<is not available>, > argv=0x7fff9949d238, error="", error_size=<is not available>) > [/home/eric/work/wine/libs/wine/loader.c:711] in libwine.so.1 > (0x0000000140001a20) > 14 0x000000007bf00cf1 main+0x80(argc=2, argv=0x7fff9949d238) > [/home/eric/work/wine/loader/main.c:218] in <wine-loader> > (0x0000000140001a20) > 15 0x00007feb8b087c4d __libc_start_main+0xfc(main=<is not > available>, argc=<is not available>, ubp_av=<is not available>, > init=<is not available>, fini=<is not available>, rtld_fini=<is not > available>, stack_end=0x7fff9949d228) > [/build/buildd/eglibc-2.11.1/csu/libc-start.c:226] in libc.so.6 > (0x0000000140001a20) > 16 0x000000007bf00ba9 _start+0x28() in <wine-loader> > (0x0000000140001a20) > 0x00000001400010b3 Boom::crash_func+0x83 > [z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29] > in multiplethreads: movq %rax,0x0000000000000000 > Unable to open file '' which is closer to what one should expect. A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Oct. 9, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 5)

by Rudolf Mayerhofer

>On Friday 08 October 2010 14:26:28 Alexandre Julliard wrote: >> Rudolf Mayerhofer <rm(a)eightyfive.net> writes: >> > +/*********************************************************************** >> > + * Several methods to retrieve data from SysFS (/sys) >> > + * used to retrieve cached_lpi in fill_cpu_info() >> > + */ >> > +static int sysfs_cpu_exists(int cpu) >> > +{ >> > + char buf[256]; >> > + >> > + sprintf(buf, "/sys/devices/system/cpu/cpu%d", cpu); >> > + return access(buf, F_OK) == 0; >> > +} >> > + >> > +static int sysfs_cpucache_exists(int cpu, int cache) >> > +{ >> > + char buf[256]; >> > + >> > + sprintf(buf, "/sys/devices/system/cpu/cpu%d/cache/index%d", cpu, >> > cache); + return access(buf, F_OK) == 0; >> > +} >> > + >> > +static int sysfs_numanode_exists(int node) >> > +{ >> > + char buf[256]; >> > + >> > + sprintf(buf, "/sys/devices/system/node/node%d", node); >> > + return access(buf, F_OK) == 0; >> > +} >> >> Don't do that sort of thing. You should handle failures to open the >> files at the point where you need them instead of doing redundant >> checks. >That's not the case here, these checks are simply to find out if a cpu,cpu >cache or numa node index exists in SysFS. It just makes no sense to try to >parse all of the stuff for a specific cpu index if it does not exist in the first >place and this is the check for that (it's done the same way as lscpu from >util-linux-ng does it). > >All the parsing functions have their own error handling as well. To clarify things a bit more, those checks are always on directories. For CPU/Cache/Numa Node there is on directory containing files and subdirectories with all the data belonging to that CPU/Cache/Numa Node. The indicies are always from 0 up to n (n=Max Number of Elements for each type). An error at the point where the data is parsed is not enough to determine if the CPU/Cache/Numa Node itself missing (which means we have already parsed all known elements) or the datafile is inaccessible/missing. Thus the additional check if the basedirectory for the CPU/Cache/Numa Node exists.

Oct. 8, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 5)

by Rudolf Mayerhofer

On Friday 08 October 2010 14:26:28 Alexandre Julliard wrote: > Rudolf Mayerhofer <rm(a)eightyfive.net> writes: > > +/*********************************************************************** > > + * Several methods to retrieve data from SysFS (/sys) > > + * used to retrieve cached_lpi in fill_cpu_info() > > + */ > > +static int sysfs_cpu_exists(int cpu) > > +{ > > + char buf[256]; > > + > > + sprintf(buf, "/sys/devices/system/cpu/cpu%d", cpu); > > + return access(buf, F_OK) == 0; > > +} > > + > > +static int sysfs_cpucache_exists(int cpu, int cache) > > +{ > > + char buf[256]; > > + > > + sprintf(buf, "/sys/devices/system/cpu/cpu%d/cache/index%d", cpu, > > cache); + return access(buf, F_OK) == 0; > > +} > > + > > +static int sysfs_numanode_exists(int node) > > +{ > > + char buf[256]; > > + > > + sprintf(buf, "/sys/devices/system/node/node%d", node); > > + return access(buf, F_OK) == 0; > > +} > > Don't do that sort of thing. You should handle failures to open the > files at the point where you need them instead of doing redundant > checks. That's not the case here, these checks are simply to find out if a cpu,cpu cache or numa node index exists in SysFS. It just makes no sense to try to parse all of the stuff for a specific cpu index if it does not exist in the first place and this is the check for that (it's done the same way as lscpu from util-linux-ng does it). All the parsing functions have their own error handling as well.

Oct. 8, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 5)

by Alexandre Julliard

Rudolf Mayerhofer <rm(a)eightyfive.net> writes: > +/*********************************************************************** > + * Several methods to retrieve data from SysFS (/sys) > + * used to retrieve cached_lpi in fill_cpu_info() > + */ > +static int sysfs_cpu_exists(int cpu) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/cpu/cpu%d", cpu); > + return access(buf, F_OK) == 0; > +} > + > +static int sysfs_cpucache_exists(int cpu, int cache) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/cpu/cpu%d/cache/index%d", cpu, cache); > + return access(buf, F_OK) == 0; > +} > + > +static int sysfs_numanode_exists(int node) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/node/node%d", node); > + return access(buf, F_OK) == 0; > +} Don't do that sort of thing. You should handle failures to open the files at the point where you need them instead of doing redundant checks. -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2010

Re: [PATCH 2/2 (try2)] shlwapi: Handle URL_WININET_COMPATIBLITY flag in UrlCanonicalize

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > try2: Rebase on top of [1/2]. > > dlls/shlwapi/tests/url.c | 4 ++++ > dlls/shlwapi/url.c | 6 ++++-- > 2 files changed, 8 insertions(+), 2 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M cryptnet.dll -T ../../.. -p cryptnet_test.exe.so cryptnet.c && touch cryptnet.ok cryptnet.c:353: Test failed: File URLs not supported make: *** [cryptnet.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 8, 2010

Re: crypt32: Avoid relying on PATH_MAX in import_certs_from_dir helper.

by Austin English

On Thu, Oct 7, 2010 at 6:56 PM, Andrew Nguyen <anguyen(a)codeweavers.com> wrote: > > PATH_MAX is not guaranteed to be available on all platforms, and it is > inadequate as a hardcoded buffer size anyway. Also fixes the first compiler error on GNU Hurd. Thanks Andrew! -- -Austin

Oct. 8, 2010

Re: New winetricks 20101008: new verbs abiword, dsound, nvidiasdk9, vd, xinput

by Austin English

On Thu, Oct 7, 2010 at 6:41 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > On Fri, Oct 8, 2010 at 1:51 AM, Dan Kegel <dank(a)kegel.com> wrote: >> - refuse to run in 64-bit WINEPREFIX's > > What's the reasoning behind this? (eg what's broken?) A lot of stuff is broken. E.g., it assumes that system32 is the proper place for 32-bit dlls, installers are always the 32-bit versions (some of which won't run on a 64-bit windows OS), etc. Until Dan or I have time to fix it, it's easier to disable it. Patches welcome, of course. -- -Austin

Oct. 8, 2010

Re: [4/4] msxml3/httprequest: Implement ::get_responseBody()

by testbot＠testbot.winehq.org

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=5972 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:3312: Test failed: got 1, expected 1 === W2KPROSP4 (32 bit domdoc) === domdoc.c:3312: Test failed: got 1, expected 1

Oct. 8, 2010

Re: New winetricks 20101008: new verbs abiword, dsound, nvidiasdk9, vd, xinput

by Jerome Leclanche

On Fri, Oct 8, 2010 at 1:51 AM, Dan Kegel <dank(a)kegel.com> wrote: > - refuse to run in 64-bit WINEPREFIX's What's the reasoning behind this? (eg what's broken?) J. Leclanche

Oct. 8, 2010

Re: [2/4] msxml3/httprequest: Implement ::abort()

by testbot＠testbot.winehq.org

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=5971 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:3311: Test failed: got 1, expected 1 === W2KPROSP4 (32 bit domdoc) === domdoc.c:3311: Test failed: got 1, expected 1

Oct. 8, 2010

New winetricks 20101008: new verbs abiword, dsound, nvidiasdk9, vd, xinput

by Dan Kegel

Another fortnight-and-a-half, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes since 20100917: Austin English: - add dsound verb. (Issue 175) - add xinput verb - dxsdk_nov2006, add support for quiet install. - fix dotnet installs for wine 1.2 (broken in recent winetricks release) - introduce $appdata_win/$appdata_unix variables, use it for Safari - refuse to run in 64-bit WINEPREFIX's - remove deprecated pbuffer option - update eadm sha1sum - update flash sha1sums - update kde to 0.9.7-0 - update utorrent sha1sum/url Dan Kegel: - add nvidiasdk9 - remove bogus msvcr80 installed by dotnet20; fixes issue 164. - use symbolic variable uniformly in set_videomemorysize - add abiword, ie6_full - fix two spots WINETRICKS_TMP wasn't quoted; this broke WINEPREFIXes containing spaces. Reported by Roberto Neri. - add vd=1024x768, vd=off options. Fixes bug 172. Scott Ritchie: - new verb cjkfonts (individual verb names may still change) - Add Quicktime 7.6, update quicktimes to depend on vcrun2005 Erik Inge Bolsø - reenable mscoree after directx9 install; fixes issue 25.

Oct. 8, 2010

Re: [PATCH 1/3] jscript: test that ActiveScriptSite_OnScriptError is called on script failure. (resend)

by Jacek Caban

On 10/7/10 4:22 PM, Reece Dunn wrote: > On 7 October 2010 14:35, Jacek Caban<jacek(a)codeweavers.com> wrote: >> Hi Reece, >> >> These tests need more thoughts. They should show how jscript exceptions are >> translated into IActiveScriptError. Your code doesn't provide mechanism to >> do so, so I would suggest to wait with sending patches that don't move us >> any forward until you have a clue how it should work. Otherwise you will >> have to deal with eventually bad decisions for no good reason. > Ok, so if I keep the current tests/ActiveScriptSite as they are and > have something like: > > test_script_error(source, scode, description, lineno, charpos, linesource) { > EXPECT CALL ActiveScriptSite_OnScriptError > hres = parse_script_with_error(source); > ok(hres == 0x8012345, ...) > > CHECK CALL ActiveScriptSite_OnScriptError > ok(script_excep.scode == scode, ...) > ok(script_excep.bstrDescription == description, ...) > ok(script_lineno == lineno, ...) > ok(script_charpos == charpos, ...) > ok(script_linesource == linesource, ...) > } > > test_script_errors() { > test_script_error("var foo = new Object();\nfoo.bar;", > 0x8012345, "Object does not support this property", 20, 11, > "foo.bar;") > test_script_error("new<>%^^;", 0x8012322, "Syntax error", 0, 0, > "new<>%^^;") > ... > } > > where parse_script_with_error does the same thing as parse_script, but > uses an ActiveScriptSite implementation that checks OnScriptError > calls and stores the IActiveScriptError object for testing within > test_script_error (like with my 3rd patch, but checking specific > values). > > 1/ Does this look like a sensible approach to you? Yes, this idea sounds good. > 2/ Do we care about the tests working on non-English locales (not > sure how to get the above working on other languages -- specifically > the description text)? Yes, we care. The easiest way to handle it is checking the locale and skipping tests on non-English locales. > 3/ Are we ok with making wine match the error description strings > exactly, given the above tests? We don't really care if strings are exactly the same. It would be nice, however, to test them and the only sane way I can see to achieve it is by making them exactly the same as native and comparing to expected value. I'd expect these values to be the same as in jscript *Error objects, so I'd prefer to extend api.js to check strings. In C part we could make this test optional and use it in very few places just to make sure it matches jscript-visible values. Jacek

Oct. 7, 2010

Re: [PATCH 1/2] shlwapi/tests: Mark Win98 failures as broken

by Jacek Caban

Hi Andrew, Can we please find a way to detect such old (broken) shlwapi and just skip the whole test (preferable all tests in the file)? Failing UrlGetPart would do the trick, hopefully there is better way. This will result in cleaner code and will save us time in future. Jacek

Oct. 7, 2010

Re: ntdll: fix compile on systems without termios.port.c_ispeed/termios.port.c_ospeed structs

by Austin English

On Thu, Oct 7, 2010 at 3:48 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Austin English <austinenglish(a)gmail.com> writes: > >> @@ -498,7 +498,7 @@ static NTSTATUS set_baud_rate(int fd, const SERIAL_BAUD_RATE* sbr) >> return STATUS_NOT_SUPPORTED; >> #endif /* Don't have linux/serial.h or lack TIOCSSERIAL */ >> } >> -#elif !defined(__EMX__) >> +#elif !defined(__EMX__) && defined (_HAVE_STRUCT_TERMIOS_C_ISPEED) && defined (_HAVE_STRUCT_TERMIOS_C_OSPEED) >> switch (sbr->BaudRate) >> { >> case 0: port.c_ospeed = B0; break; > > You'd want to use the cflag method in this case. Which platform needs this? Hm, I'll have to look into that. It's for GNU Hurd, compile is broken without it. I've got a few other patches for it as well, that need cleaning first. -- -Austin

Oct. 7, 2010

Mentor summit for Google Summer of Code - time sensitive

by Jeremy White

As a heads up, Bradley reminds me that the Mentor summit for GSOC: http://gsoc-wiki.osuosl.org/index.php/2010 is coming up; the registration deadline is tomorrow. Google may reimburse travel expenses, so if cost is an issue, we may be able to help with that. If you need such help, let me know, and I'll connect you with Bradley. Cheers, Jeremy

Oct. 7, 2010

Re: [6/6]strmbase: Implement BaseFilter in strmbase

by Aric Stewart

Ok I think I know what is going on. I have some later patches that i think need to be merged into this one and then separated at a different place. -aric On 10/7/10 9:07 AM, Alexandre Julliard wrote: > Aric Stewart<aric(a)codeweavers.com> writes: > >> --- >> dlls/qcap/vfwcapture.c | 134 +++++-------------------- >> dlls/quartz/acmwrapper.c | 20 ++-- >> dlls/quartz/avidec.c | 12 +- >> dlls/quartz/avisplit.c | 6 +- >> dlls/quartz/dsoundrender.c | 223 >> ++++++++++++------------------------------- >> dlls/quartz/filesource.c | 129 +++++-------------------- >> dlls/quartz/mpegsplit.c | 4 +- >> dlls/quartz/nullrenderer.c | 177 ++++++++-------------------------- >> dlls/quartz/parser.c | 156 ++++++++++-------------------- >> dlls/quartz/parser.h | 9 +-- >> dlls/quartz/transform.c | 201 ++++++++------------------------------- >> dlls/quartz/transform.h | 10 +-- >> dlls/quartz/videorenderer.c | 226 >> +++++++++++++------------------------------ >> dlls/quartz/waveparser.c | 4 +- >> dlls/strmbase/Makefile.in | 1 + >> dlls/strmbase/filter.c | 158 ++++++++++++++++++++++++++++++ >> include/wine/strmbase.h | 23 +++++ >> 17 files changed, 517 insertions(+), 976 deletions(-) >> create mode 100644 dlls/strmbase/filter.c > > I'm seeing occasional crashes in the qedit:mediadet test with this > patch. Unfortunately the debugger fails to get a backtrace. >

Oct. 7, 2010

Re: wine_call_on_stack Sparc Edition

by André Hentschel

Oops, wrong address, sry for the noise -- Best Regards, André Hentschel

Oct. 7, 2010

Re: ntdll: fix compile on systems without termios.port.c_ispeed/termios.port.c_ospeed structs

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > @@ -498,7 +498,7 @@ static NTSTATUS set_baud_rate(int fd, const SERIAL_BAUD_RATE* sbr) > return STATUS_NOT_SUPPORTED; > #endif /* Don't have linux/serial.h or lack TIOCSSERIAL */ > } > -#elif !defined(__EMX__) > +#elif !defined(__EMX__) && defined (_HAVE_STRUCT_TERMIOS_C_ISPEED) && defined (_HAVE_STRUCT_TERMIOS_C_OSPEED) > switch (sbr->BaudRate) > { > case 0: port.c_ospeed = B0; break; You'd want to use the cflag method in this case. Which platform needs this? -- Alexandre Julliard julliard(a)winehq.org

Oct. 7, 2010

Re: [PATCH 1/3] jscript: test that ActiveScriptSite_OnScriptError is called on script failure. (resend)

by Reece Dunn

On 7 October 2010 14:35, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi Reece, > > These tests need more thoughts. They should show how jscript exceptions are > translated into IActiveScriptError. Your code doesn't provide mechanism to > do so, so I would suggest to wait with sending patches that don't move us > any forward until you have a clue how it should work. Otherwise you will > have to deal with eventually bad decisions for no good reason. Ok, so if I keep the current tests/ActiveScriptSite as they are and have something like: test_script_error(source, scode, description, lineno, charpos, linesource) { EXPECT CALL ActiveScriptSite_OnScriptError hres = parse_script_with_error(source); ok(hres == 0x8012345, ...) CHECK CALL ActiveScriptSite_OnScriptError ok(script_excep.scode == scode, ...) ok(script_excep.bstrDescription == description, ...) ok(script_lineno == lineno, ...) ok(script_charpos == charpos, ...) ok(script_linesource == linesource, ...) } test_script_errors() { test_script_error("var foo = new Object();\nfoo.bar;", 0x8012345, "Object does not support this property", 20, 11, "foo.bar;") test_script_error("new <>%^^;", 0x8012322, "Syntax error", 0, 0, "new <>%^^;") ... } where parse_script_with_error does the same thing as parse_script, but uses an ActiveScriptSite implementation that checks OnScriptError calls and stores the IActiveScriptError object for testing within test_script_error (like with my 3rd patch, but checking specific values). 1/ Does this look like a sensible approach to you? 2/ Do we care about the tests working on non-English locales (not sure how to get the above working on other languages -- specifically the description text)? 3/ Are we ok with making wine match the error description strings exactly, given the above tests? NOTE: 2 and 3 can be avoided by just checking the scode and checking that the description is set and non-NULL (as per my 3rd patch). > Also merging parsing_htmlscript is not a good idea. Its purpose is different > than parse_script. Ok, I'll keep them separate. - Reece

Oct. 7, 2010

Re: [6/6]strmbase: Implement BaseFilter in strmbase

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/qcap/vfwcapture.c | 134 +++++-------------------- > dlls/quartz/acmwrapper.c | 20 ++-- > dlls/quartz/avidec.c | 12 +- > dlls/quartz/avisplit.c | 6 +- > dlls/quartz/dsoundrender.c | 223 > ++++++++++++------------------------------- > dlls/quartz/filesource.c | 129 +++++-------------------- > dlls/quartz/mpegsplit.c | 4 +- > dlls/quartz/nullrenderer.c | 177 ++++++++-------------------------- > dlls/quartz/parser.c | 156 ++++++++++-------------------- > dlls/quartz/parser.h | 9 +-- > dlls/quartz/transform.c | 201 ++++++++------------------------------- > dlls/quartz/transform.h | 10 +-- > dlls/quartz/videorenderer.c | 226 > +++++++++++++------------------------------ > dlls/quartz/waveparser.c | 4 +- > dlls/strmbase/Makefile.in | 1 + > dlls/strmbase/filter.c | 158 ++++++++++++++++++++++++++++++ > include/wine/strmbase.h | 23 +++++ > 17 files changed, 517 insertions(+), 976 deletions(-) > create mode 100644 dlls/strmbase/filter.c I'm seeing occasional crashes in the qedit:mediadet test with this patch. Unfortunately the debugger fails to get a backtrace. -- Alexandre Julliard julliard(a)winehq.org

Oct. 7, 2010

Re: psapi/tests: get rid of an ugly test macro

by testbot＠testbot.winehq.org

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=5941 Your paranoid android. === WVISTAADM (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=100 === W2K8SE (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=100 === W7PRO (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=96 === W7PROX64 (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=108

Oct. 7, 2010

Re: [PATCH] d3d9/tests: Fix test failure for IDirect3D9::CreateDevice in test_set_stream_source

by testbot＠testbot.winehq.org

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=5923 Your paranoid android. === W2K8SE (32 bit device) === device.c:2474: Test failed: Expected foreground window 00040182, got 0001004C. device.c:2612: Test failed: Expected foreground window 00030114, got 0001004C. === W7PROX64 (32 bit device) === device.c:2474: Test failed: Expected foreground window 0002019A, got 00010092. device.c:2612: Test failed: Expected foreground window 0003019A, got 00010092.

Oct. 7, 2010

Re: usp10: when checking font for shaping the font needs at least 1 of the features but does not need all.

by Dmitry Timoshkov

Aric Stewart <aric(a)codeweavers.com> wrote: > - while (ShapingData[psa->eScript].requiredFeatures[i]) > + while (ShapingData[psa->eScript].requiredFeatures[i] && !found) > { > feature = load_GSUB_feature(hdc, psa, psc, ShapingData[psa->eScript].requiredFeatures[i]); > - if (!feature) > - return USP_E_SCRIPT_NOT_IN_FONT; > + if (feature) > + found = TRUE; Why not return S_OK right away here, and return USP_E_SCRIPT_NOT_IN_FONT right after the while loop? That would eliminate a need for an intermediate variable and simplify the code. -- Dmitry.

Oct. 7, 2010

Test failures on Windows XP Japanese due to fonts selection differences

by Austin Lund

There are a number of test failures due to hardcoded sizes in test which fail for particular platforms, e.g. http://test.winehq.org/data/6e89a61446088dbe029913896dfae467bb8d37a1/xp_wtb… It seems the reason for this is that it is impossible to select the system font with height 16 on this platform. (No idea why, any ideas?) Should these tests be written so that a particular font selection is forced across platforms (e.g. ANSI, 16 point, System), or should the hardcoded values instead be computed for each particular instance?

Oct. 7, 2010

Re: New version of exe-thumbnailer (0.7)

by Nicholas van Oudtshoorn

On 10/04/2010 09:44 PM, Damjan Jovanovic wrote: > On Mon, Oct 4, 2010 at 4:07 AM, Nicholas van Oudtshoorn > <vanoudt(a)gmail.com> wrote: >> On 10/04/2010 08:39 AM, Octavian Voicu wrote: >>> >>> On Fri, Oct 1, 2010 at 11:18 PM, Scott Ritchie<scott(a)open-vote..org >>> <mailto:scott(a)open-vote.org>> wrote: >>> >>> Includes much prettier icons, support for Vista icons (with icoutils >>> 0.29.1) and more. >>> >>> Screenshots and a description are at: >>> http://wiki.winehq.org/exe-thumbnailer >>> >>> >>> Nice! Any plans for Kubuntu / KDE support? :) >>> >>> Octavian >>> >>> >>> >>> >> >> Nice! >> >> Just to note, KDE/Dolphin already has built-in support for thumnbailing exe >> files. (Although, in Fedora at least, it's not enabled by default; just tell >> dolphin to show previews for "Microsoft Windows Executables". >> >> I've also got code on the KDE reviewboard that'll take care of LNK files - >> if it gets picked up, that'll be natively supported by KDE too... >> >> Nicholas > > How does thumbnailing LNK files work? You get a Windows icon path out, > which you have to convert to a *nix path - you'd have to use > ~/.wine/dosdevices and do case-insensitive filename matching, and even > that would only work for LNK files created by Wine, those on a Windows > partition have Windows's idea of drive mappings which is probably > different from Wine. > > Damjan Jovanovic > > > Agreed - the gnome version does look much better at the moment. Thumbnailing LNK files is done by doing a simple parse of the LNK file, and then using wine's winepath command to convert that into a wine path. (Hence "winepath" :) ) Certainly, LNK files on Windows partitions wouldn't work at all (under the current way it's being done.) Nicholas

Oct. 7, 2010

Re: [PATCH 06/10] urlmon: Added IBinding::Abort and binding without callback tests.

by testbot＠testbot.winehq.org

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=5914 Your paranoid android. === W2K8SE (32 bit url) === url.c:1553: Test failed: binding failed: 800c0005, expected 00000000 url.c:2558: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:2559: Test failed: unk == NULL === W7PROX64 (32 bit url) === url.c:1553: Test failed: binding failed: 800c0005, expected 00000000 url.c:2558: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:2559: Test failed: unk == NULL

Oct. 7, 2010

Re: Translation patches for wine-1.2.1

by Michael Stefaniuc

On 10/06/2010 10:29 PM, Sven Baars wrote: > Michael Stefaniuc wrote: >> Hello Alexandre, >> >> attached is the list with the translation patches to cherry-pick for >> wine-1.2.1. The list was generated with the attached crud patch >> (modified from the version I used for 1.0.1) and then I have manually >> removed all my janitorial patches that didn't produce conflicts. >> >> Though the removal of the unneeded "Remove the ignored common resource >> attributes" patches makes "wrc --verify-translation" produce DIFF >> lines for resources that were added at a later time as those don't >> have the ignored common resource attributes. >> >> bye >> michael > This script doesn't check for updated mc files, so the kernel32 > translation patches didn't get in. This includes for example > > 7fe8c7202345ba04425e3dfefb534bcad8fe76fa > > which was the first commit after wine 1.2 and is a translation update. > Just thought you might want to know this. I know, I already pulled the list of mc file changes. Was busy with work and had no time to test and submit that list. bye michael

Oct. 6, 2010

Re: Translation patches for wine-1.2.1

by Sven Baars

Michael Stefaniuc wrote: > Hello Alexandre, > > attached is the list with the translation patches to cherry-pick for > wine-1.2.1. The list was generated with the attached crud patch > (modified from the version I used for 1.0.1) and then I have manually > removed all my janitorial patches that didn't produce conflicts. > > Though the removal of the unneeded "Remove the ignored common resource > attributes" patches makes "wrc --verify-translation" produce DIFF > lines for resources that were added at a later time as those don't > have the ignored common resource attributes. > > bye > michael This script doesn't check for updated mc files, so the kernel32 translation patches didn't get in. This includes for example 7fe8c7202345ba04425e3dfefb534bcad8fe76fa which was the first commit after wine 1.2 and is a translation update. Just thought you might want to know this. Sven

Oct. 6, 2010

Re: [PATCH 3/9] urlmon: Added IBinding::Abort implementation.

by Jacek Caban

On 10/6/10 4:07 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> --- >> dlls/urlmon/binding.c | 20 +++++++++++++++++--- >> 1 files changed, 17 insertions(+), 3 deletions(-) > It doesn't work here: Sorry about that. I had a hack in my tree that accidentally prevented the crash. I will send a proper fix. Jacek

Oct. 6, 2010

Re: cryptui: Fix a crash with certification path (resend)

by André Hentschel

Am 06.10.2010 18:08, schrieb Juan Lang: >>>> @@ -4051,8 +4050,8 @@ static void show_cert_chain(HWND hwnd, struct hierarchy_data *data) >>>> */ >>>> tvis.u.item.iImage = 2; >>>> } >>>> - else if (provSigner->pasCertChain[i - 1].pChainElement->TrustStatus. >>>> - dwErrorStatus == 0) >>>> + else if (i > 1 && >>>> + provSigner->pasCertChain[i - 1].pChainElement->TrustStatus.dwErrorStatus == 0) >>> >>> What is this change for? >>> >> there is no pasCertChain[0] for some reason, there is a similar check in show_dialog_for_selected_cert (same file, "selection" is checked for not being 0 and used as index for pasCertChain) > > That's a bit different. I wonder if there's a wintrust bug that leads > to this? Any chance of opening a bug and attaching the cert that > produces the crash to it? > --Juan sure, see http://bugs.winehq.org/show_bug.cgi?id=24649 (wasn't able to attach you...) -- Best Regards, André Hentschel

Oct. 6, 2010

Re: cryptui: Fix a crash with certification path (resend)

by Juan Lang

>>> @@ -4051,8 +4050,8 @@ static void show_cert_chain(HWND hwnd, struct hierarchy_data *data) >>> */ >>> tvis.u.item.iImage = 2; >>> } >>> - else if (provSigner->pasCertChain[i - 1].pChainElement->TrustStatus. >>> - dwErrorStatus == 0) >>> + else if (i > 1 && >>> + provSigner->pasCertChain[i - 1].pChainElement->TrustStatus.dwErrorStatus == 0) >> >> What is this change for? >> > there is no pasCertChain[0] for some reason, there is a similar check in show_dialog_for_selected_cert (same file, "selection" is checked for not being 0 and used as index for pasCertChain) That's a bit different. I wonder if there's a wintrust bug that leads to this? Any chance of opening a bug and attaching the cert that produces the crash to it? --Juan

Oct. 6, 2010

Re: cryptui: Fix a crash with certification path (resend)

by André Hentschel

Am 06.10.2010 17:41, schrieb Alexandre Julliard: > André Hentschel <nerv(a)dawncrow.de> writes: > >> @@ -4051,8 +4050,8 @@ static void show_cert_chain(HWND hwnd, struct hierarchy_data *data) >> */ >> tvis.u.item.iImage = 2; >> } >> - else if (provSigner->pasCertChain[i - 1].pChainElement->TrustStatus. >> - dwErrorStatus == 0) >> + else if (i > 1 && >> + provSigner->pasCertChain[i - 1].pChainElement->TrustStatus.dwErrorStatus == 0) > > What is this change for? > there is no pasCertChain[0] for some reason, there is a similar check in show_dialog_for_selected_cert (same file, "selection" is checked for not being 0 and used as index for pasCertChain) -- Best Regards, André Hentschel

Oct. 6, 2010

Re: [1/2] explorer: Do not set the caption for "Shell_TrayWnd", some applications depend on it being empty.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Shouldn't that be a separate thing not related to the problem fixed by > my patch? Sure it should be a separate change. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: cryptui: Fix a crash with certification path (resend)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -4051,8 +4050,8 @@ static void show_cert_chain(HWND hwnd, struct hierarchy_data *data) > */ > tvis.u.item.iImage = 2; > } > - else if (provSigner->pasCertChain[i - 1].pChainElement->TrustStatus. > - dwErrorStatus == 0) > + else if (i > 1 && > + provSigner->pasCertChain[i - 1].pChainElement->TrustStatus.dwErrorStatus == 0) What is this change for? -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [1/2] explorer: Do not set the caption for "Shell_TrayWnd", some applications depend on it being empty.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> This will cause the stand-alone tray window to not have a title, that > >> doesn't look nice. > > > > What would you suggest? > > Use a separate window for the stand-alone tray. Shouldn't that be a separate thing not related to the problem fixed by my patch? -- Dmitry.

Oct. 6, 2010

Re: [1/2] explorer: Do not set the caption for "Shell_TrayWnd", some applications depend on it being empty.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: >> This will cause the stand-alone tray window to not have a title, that >> doesn't look nice. > > What would you suggest? Use a separate window for the stand-alone tray. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [1/2] explorer: Do not set the caption for "Shell_TrayWnd", some applications depend on it being empty.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > The bug #20129 lists one of such applications. > > > > It does FindWindow("Shell_TrayWnd", "") and expects that it returns a valid > > tray window handle. Currently FindWindow() is broken, but my next patch makes > > the above call succeed. > > This will cause the stand-alone tray window to not have a title, that > doesn't look nice. What would you suggest? -- Dmitry.

Oct. 6, 2010

Re: cryptui: Fix a crash with certification path

by André Hentschel

Am 05.10.2010 00:04, schrieb Juan Lang: > Hi André, > I see your patch didn't get committed. In case it's waiting for a > comment from me, it looks fine: I assume you've imported a > certificate that isn't otherwise trusted, and viewing it results in a > crash? I don't see the crash here. > > Thanks, > --Juan Yes. So thanks for the positiv comment, i'll resend the patch. -- Best Regards, André Hentschel

Oct. 6, 2010

Re: [7/7] msi/tests: Fix some test failures on 64-bit.

by testbot＠testbot.winehq.org

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=5900 Your paranoid android. === W7PROX64 (64 bit install) === install.c:10500: Test failed: key not created

Oct. 6, 2010

Re: [1/2] explorer: Do not set the caption for "Shell_TrayWnd", some applications depend on it being empty.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > The bug #20129 lists one of such applications. > > It does FindWindow("Shell_TrayWnd", "") and expects that it returns a valid > tray window handle. Currently FindWindow() is broken, but my next patch makes > the above call succeed. This will cause the stand-alone tray window to not have a title, that doesn't look nice. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [2/6]strmbase: move enumpins from quartz to strmbase

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/qcap/Makefile.in | 1 - > dlls/qcap/enumpins.c | 186 ------------------------------------- > dlls/qcap/qcap_main.h | 8 -- > dlls/qcap/vfwcapture.c | 28 +++++- > dlls/quartz/Makefile.in | 1 - > dlls/quartz/dsoundrender.c | 26 ++++-- > dlls/quartz/enumpins.c | 211 > ------------------------------------------ > dlls/quartz/filesource.c | 32 +++++-- > dlls/quartz/nullrenderer.c | 25 +++-- > dlls/quartz/parser.c | 29 ++++-- > dlls/quartz/quartz_private.h | 3 - > dlls/quartz/transform.c | 27 ++++-- > dlls/quartz/videorenderer.c | 25 +++-- > dlls/strmbase/Makefile.in | 1 + > dlls/strmbase/enumpins.c | 207 > +++++++++++++++++++++++++++++++++++++++++ > include/wine/strmbase.h | 6 + > 16 files changed, 346 insertions(+), 470 deletions(-) > delete mode 100644 dlls/qcap/enumpins.c > delete mode 100644 dlls/quartz/enumpins.c > create mode 100644 dlls/strmbase/enumpins.c It doesn't work here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so avisplitter.c && touch avisplitter.ok avisplitter.c:164: Test failed: pins[1] = (nil) avisplitter.c:210: Tests skipped: Could not read test file "test.avi", skipping test make: *** [avisplitter.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [2/7] msi: Use strcmpW instead of lstrcmpW to compare database strings.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > An installer I have here uses \1 and \2 as delimiters in property strings. > It turns out that on Wine lstrcmp("\1", "\2") returns 0, not -1, which causes > the string table implementation to return the wrong value. This should be fixed, > but it's better if database string comparisons do not depend on thread locale. Yes, but isn't it supposed to follow Unicode sorting rules instead of simply comparing code point values? -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [4/7] msi: Add package validation tests.

by testbot＠testbot.winehq.org

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=5898 Your paranoid android. === W7PROX64 (64 bit install) === install.c:10164: Test failed: key not removed install.c:10174: Test failed: key not removed install.c:10185: Test failed: key not removed install.c:10476: Test failed: key not created

Oct. 6, 2010

Re: [PATCH 3/9] urlmon: Added IBinding::Abort implementation.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/urlmon/binding.c | 20 +++++++++++++++++--- > 1 files changed, 17 insertions(+), 3 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so htmllocation.c && touch htmllocation.ok wine: Unhandled page fault on read access to 0x00000110 at address 0x555d325a (thread 001f), starting debugger... Unhandled exception: page fault on read access to 0x00000110 in 32-bit code (0x555d325a). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:555d325a ESP:0032dfd0 EBP:0032e038 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00ed2bf4 EBX:5561bc84 ECX:002078c0 EDX:555d31c0 ESI:0126f400 EDI:00000000 Stack dump: 0x0032dfd0: 00ed2b98 0032e3a8 0032e008 6ad698bc 0x0032dfe0: 002078b0 00000001 00000001 0032e078 0x0032dff0: 6adbe4f5 002078b0 0032e018 00000000 0x0032e000: 002078b0 6b127f9c 0032e028 6ad697d8 0x0032e010: 002078b0 0032e074 00000001 00000000 0x0032e020: 002078a8 0032e074 0032e068 012ad758 Backtrace: =>0 0x555d325a handle_load+0x9a(iface=0x126f5c0, event=0x12ad758) [/home/julliard/wine/wine/dlls/mshtml/nsevents.c:226] in mshtml (0x0032e158) 1 0x6a02f1db in xul (+0x3ef1da) (0x0032e1d8) 2 0x6aca1e00 in xul (+0x1061dff) (0x0032e208) 3 0x6aca1fe1 in xul (+0x1061fe0) (0x0032e258) 4 0x6a047958 in xul (+0x407957) (0x0032e2a8) 5 0x6a04819c in xul (+0x40819b) (0x0032e378) 6 0x69dc9c12 in xul (+0x189c11) (0x0032e408) 7 0x6a53d3a0 in xul (+0x8fd39f) (0x0032e698) 8 0x6a53ced6 in xul (+0x8fced5) (0x0032e718) 9 0x6a5574c8 in xul (+0x9174c7) (0x0032e768) 10 0x6a556567 in xul (+0x916566) (0x0032e798) 11 0x6a556371 in xul (+0x916370) (0x0032e7e8) 12 0x6a555fa2 in xul (+0x915fa1) (0x0032e858) 13 0x69c66091 in xul (+0x26090) (0x0032e898) 14 0x555cbc1b on_stop_nsrequest+0x8a(This=0xed4da0, result=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:1011] in mshtml (0x0032e8d8) 15 0x555cbc1b on_stop_nsrequest+0x8a(This=0x10, result=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:1011] in mshtml (0x0032e8e8) 16 0x555cca5f nsChannelBSC_stop_binding+0x1e(bsc=0x126fe08, result=0x555d31c0) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:1184] in mshtml (0x0032e928) 17 0x555cb126 BindStatusCallback_OnStopBinding+0x35(iface=0x126fe08, hresult=0xffffffff80004004, szError=0x0(nil)) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:360] in mshtml (0x0032e968) 18 0x68f3f838 BindStatusCallback_OnStopBinding+0x87(iface=0x129b090, hresult=0xffffffff80004004, szError=0x0(nil)) [/home/julliard/wine/wine/dlls/urlmon/bindctx.c:178] in urlmon (0x0032e988) 19 0x68f40c5d stop_binding+0x3c(binding=0x129b118, hres=0xffffffff80004004, str=0x0(nil)) [/home/julliard/wine/wine/dlls/urlmon/binding.c:221] in urlmon (0x0032e9d8) 20 0x68f41dde InternetProtocolSink_ReportResult+0x8d(iface=0x129b11c, hrResult=0xffffffff80004004, dwError=0, szResult=0x0(nil)) [/home/julliard/wine/wine/dlls/urlmon/binding.c:1149] in urlmon (0x0032ea28) 21 0x68f47abd BPInternetProtocolSink_ReportResult+0xec(iface=0x129b578, hrResult=0xffffffff80004004, dwError=0, szResult=0x0(nil)) [/home/julliard/wine/wine/dlls/urlmon/bindprot.c:1184] in urlmon (0x0032ea48) 22 0x68f50b5d report_result+0x3c() in urlmon (0x0032ea58) 23 0x68f50c1d protocol_abort+0x2c(protocol=0x2078c0, reason=0xffffffff80004004) [/home/julliard/wine/wine/dlls/urlmon/protocol.c:439] in urlmon (0x0032ea98) 24 0x68f4cbd4 HttpProtocol_Abort+0x73(iface=0x129b764, hrReason=0xffffffff80004004, dwOptions=0) [/home/julliard/wine/wine/dlls/urlmon/http.c:445] in urlmon (0x0032eae8) 25 0x68f452b0 ProtocolHandler_Abort+0x5f(iface=0x129b580, hrReason=0xffffffff80004004, dwOptions=0) [/home/julliard/wine/wine/dlls/urlmon/bindprot.c:662] in urlmon (0x0032eb38) 26 0x68f459db BindProtocol_Abort+0x7a(iface=0x129b568, hrReason=0xffffffff80004004, dwOptions=0) [/home/julliard/wine/wine/dlls/urlmon/bindprot.c:429] in urlmon (0x0032eb68) 27 0x68f4140b Binding_Abort+0x5a(iface=0x129b118) [/home/julliard/wine/wine/dlls/urlmon/binding.c:892] in urlmon (0x0032eb88) 28 0x555ca834 set_window_bscallback+0x23(window=0xed2b98, callback=(nil)) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:1349] in mshtml (0x0032ebd8) 29 0x555c54a1 HTMLWindow2_Release+0x70(iface=0xed2ba8) [/home/julliard/wine/wine/dlls/mshtml/htmlwindow.c:228] in mshtml (0x0032ec18) 30 0x55580881 CustomDoc_Release+0x80(iface=0x129db0) [/home/julliard/wine/wine/dlls/mshtml/htmldoc.c:2021] in mshtml (0x0032ec38) 31 0x5557ea04 HTMLDocument_Release+0x13(iface=0x129ca8) [/home/julliard/wine/wine/dlls/mshtml/mshtml_private.h:376] in mshtml (0x0032fd08) 32 0x686a82f5 perform_test+0xd34(test=0x686c24c3) [/home/julliard/wine/wine/dlls/mshtml/tests/htmllocation.c:348] in mshtml_test (0x0032fd38) 33 0x686a838e func_htmllocation+0x3d() [/home/julliard/wine/wine/dlls/mshtml/tests/htmllocation.c:360] in mshtml_test (0x0032fd88) 34 0x686b535e run_test+0x15d(name=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:556] in mshtml_test (0x0032fe48) 35 0x686b5557 main+0x156(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:624] in mshtml_test (0x0032fe90) 36 0x686b60dc __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0032fea8) 37 0x7b856c4c call_process_entry+0xb() in kernel32 (0x0032fee8) 38 0x7b85914b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:994] in kernel32 (0x0032fef8) 39 0x7bc72b80 call_thread_func+0xb() in ntdll (0x0032ffc8) 40 0x7bc72d50 call_thread_entry_point+0x6f(entry=0x7b8590f0, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0032ffe8) 41 0x7bc4da6a start_process+0x29(kernel_start=0x7b8590f0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2610] in ntdll (0x00000000) 0x555d325a handle_load+0x9a [/home/julliard/wine/wine/dlls/mshtml/nsevents.c:226] in mshtml: movl 0x110(%edi),%eax 226 if(doc_obj->nscontainer->editor_controller) { -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: [PATCH 9/9] urlmon: Added IInternetProtocolEx support to http protocol handler.

by testbot＠testbot.winehq.org

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=5895 Your paranoid android. === W2K3R2SESP2 (32 bit protocol) === protocol.c:977: Test failed: hrResult = 800c0005, expected: 00000000 Timeout

Oct. 6, 2010

Re: [PATCH 6/9] urlmon: Added IBinding::Abort and binding without callback tests.

by testbot＠testbot.winehq.org

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=5893 Your paranoid android. === WXPPROSP3 (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === W2K3R2SESP2 (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === WVISTAADM (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === W2K8SE (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === W7PRO (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === W7PROX64 (32 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable No test summary line found === W7PROX64 (64 bit url) === url.c:490: Test failed: expected Read url.c:492: Test failed: expected OnProgress_DOWNLOADINGDATA url.c:493: Test failed: expected OnDataAvailable url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1428: Test failed: unexpected call OnProgress_DOWNLOADINGDATA url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1428: Test failed: unexpected call OnProgress_DOWNLOADINGDATA url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1428: Test failed: unexpected call OnProgress_DOWNLOADINGDATA url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1428: Test failed: unexpected call OnProgress_DOWNLOADINGDATA url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1428: Test failed: unexpected call OnProgress_DOWNLOADINGDATA url.c:1597: Test failed: unexpected call OnDataAvailable url.c:1597: Test failed: unexpected call OnDataAvailable

Oct. 6, 2010

Re: [PATCH 1/9] urlmon: Return correct error in get_protocol_handler for unknown protocol types.

by testbot＠testbot.winehq.org

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=5892 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:459: Test failed: expected ReportProgress_SENDINGREQUEST

Oct. 6, 2010

Re: [PATCH 3/3] d3d9/tests: Add window proc tests for switching between fullscreen and windowed.

by testbot＠testbot.winehq.org

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=5888 Your paranoid android. === W2K8SE (32 bit device) === device.c:2473: Test failed: Expected foreground window 00040182, got 0001004C. device.c:2611: Test failed: Expected foreground window 00030114, got 0001004C. === W7PROX64 (64 bit device) === device.c:2473: Test failed: Expected foreground window 0000000000020198, got 0000000000010092. device.c:2611: Test failed: Expected foreground window 0000000000030198, got 0000000000010092.

Oct. 6, 2010

Re: [1/5] mscoree: Implement ICLRMetaHost_GetRuntime.

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > This will cause the tests to fail if Mono is not available. We'll have to start providing a Mono package then. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: cabinet/tests: Reformated output in case of test failure (try 2)

by Alexandre Julliard

Marko Nikolic <grkoma(a)gmail.com> writes: > In case of test failure, expected and received values are traced. > Format for the two values was different, corrected so both values > are traced as hex. Error values are in general more useful in decimal. -- Alexandre Julliard julliard(a)winehq.org

Oct. 6, 2010

Re: crypt32(10/10): Set correct error when encountering unsupported critical extensions in the base and SSL policy

by testbot＠testbot.winehq.org

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=5874 Your paranoid android. === W98SE (32 bit chain) === chain.c:4117: Test failed: ignoredInvalidDateBasePolicyCheck[0](#0001): expected 800b0101, got 800b0102 chain.c:4117: Test failed: invalidExtensionPolicyCheck[0](#0001): expected 800b0105, got 800b0102 chain.c:4117: Test failed: iTunesPolicyCheckWithoutMatchingName[0](#0004): expected 800b010f, got 800b0109 chain.c:4117: Test failed: googlePolicyCheckWithMatchingName[0](#0004): expected 00000000, got 800b0101 chain.c:4117: Test failed: opensslPolicyCheckWithMatchingName[0](#0004): expected 00000000, got 800b0109 chain.c:4117: Test failed: opensslPolicyCheckWithoutMatchingName[0](#0004): expected 800b010f, got 800b0109 chain.c:4117: Test failed: opensslPolicyCheckWithoutMatchingName[0](#0004): expected 800b010f, got 800b0109 chain.c:4117: Test failed: opensslPolicyCheckWithoutMatchingName[0](#0004): expected 800b010f, got 800b0109 chain.c:4117: Test failed: stanfordPolicyCheckWithMatchingName[0](#0004): expected 00000000, got 800b0109 chain.c:4117: Test failed: stanfordPolicyCheckWithMatchingName[0](#0004): expected 00000000, got 800b0109 chain.c:4117: Test failed: stanfordPolicyCheckWithoutMatchingName[0](#0004): expected 800b010f, got 800b0109 chain.c:2752: Test failed: Chain 31: expected error 00000001, got 00000003. 00000020 is expected if no valid Verisign root certificate is available. chain.c:2674: Test failed: Chain 31, element [0,1]: expected error 00000000, got 00000002. 00000020 is expected if no valid Verisign root certificate is available. chain.c:2674: Test failed: Chain 31, element [0,2]: expected error 00000000, got 00000001. 00000020 is expected if no valid Verisign root certificate is available. chain.c:2752: Test failed: Chain 32: expected error 00000001, got 00010001. 00000020 is expected if no valid Verisign root certificate is available. chain.c:2712: Test failed: Chain 32: expected 3 elements, got 2 === WNT4WSSP6 (32 bit chain) === chain.c:4117: Test failed: invalidExtensionPolicyCheck[0](#0001): expected 800b0105, got 800b0102

Oct. 6, 2010

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 4)

by Mike Kaplinskiy

There are still a few style issues with your patch. You have inconsistent spacing after ifs ("if (" vs "if("), missing spaces after commas, and a few more "}else{"s. You also create a few blocks for no reason other than to get around the C declarations on top of block rule. Please organize these in tune with the surrounding code. Only create a "useless" block (ie a block without a control flow statement) if there is an #ifdef around it with other implementations. Also please don't do things like "if (x) { do {...} while(x); }". More importantly you seem to be missing the tests for this. (sorry for top posting; mobile gmail doesn't seem to have the ability to bottom post) Mike. On Oct 6, 2010 2:16 AM, "Rudolf Mayerhofer" <rm(a)eightyfive.net> wrote: > Try 2: > - Exchange Patches #2 and #3. > - Fix errors in formatting > - Check that fopen succeeds, return default value otherwise > - default return value is now 0 for all parser functions > > Try 3: > - Add missing checks for valid processor mask and cache values > > Try 4: > - More comments in the parsing code > - Some additional code cleanup > > --- > dlls/ntdll/nt.c | 343 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 343 insertions(+), 0 deletions(-) >

Oct. 6, 2010