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