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

Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()

by Austin English

On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > You forgot the patch. -- -Austin

July 31, 2013

Re: kernel32/tests: Improve GetVolumePathNameA tests

by Bruno Jesus

Please ignore this patch, I understand that as is it will not be commited. On Tue, Jul 30, 2013 at 3:30 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Erich Hoover contacted me about a patch he sent months ago related to > GetVolumePathNameA. He developed a better test infrastructure using a > for loop instead of multiple repetitions of test lines. This patch > will make it easier for him to rebase and send his tests and function > implementation later. > > I used the same approach from [1] by decomposing the "todo_wine" in > winetest_start_todo("wine") and winetest_end_todo("wine"). > > http://source.winehq.org/source/programs/cmd/tests/batch.c#L292 -- universe* god::bigbang (void); //and then it all began...

July 30, 2013

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.

by Matteo Bruni

2013/7/30 Rico Schüller <kgbricola(a)web.de>: > Hi Matteo, > > please see the attached patch. > > > On 25.07.2013 16:13, Matteo Bruni wrote: >> >> 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >>> >>> --- >>> dlls/d3dx9_36/tests/shader.c | 308 >>> +++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 308 insertions(+) >>> >> >> This is okay, but as a followup can you add some tests with mixed-type >> structs? Something like: >> >> struct >> { >> float f; >> int i; >> bool b; >> }; >> >> If you have already written tests of this kind, I'd like to know what >> does the compiler do in this case :) >> > Single variables could only have the tested types (I was not able to > generate other conversions than bool->bool, int->int, int->float, > bool->float, float->float). But I found a way to do it with structs and > there I found some issues. Hence this has to be fixed in wine, too. Thanks > for the nice question. :-) > > Basically you got these for the struct: > 1. D3DXRS_FLOAT4: if one variable is used as float or a float variable is > used or an int variable is used as bool (the compiler may do some > optimization), else #2 > 2. D3DXRS_BOOL: if a bool variable is used as bool (in an if clause), else > #3 > 3. D3DXRS_INT4 > > It looks like you could only do it that way with unused variables. I'm not > sure if this makes sense at all. Why would someone set an unused variable? > Maybe I missed something? Do you know anything else? > It does make some sense, although this is not what I expected. Also, I'm getting different results... If I understand correctly your test, all the fields of a structure share the same registerset. Which is silly, since AFAIU each member of the structure has a separate D3DXCONSTANT_DESC in the constant table, both on disk and in memory, there is no point the compiler should force the same registerset for all the struct members. Under the constraint of forcing all the members in the same registerset, the "conversion rules" you mention make sense. In SM3 an if bool can be replaced by an if_comp with a float register and a rep/loop, which is controlled by an integer constant, can be emulated via loop unrolling (although I'm not sure how the compiler can possibly do that for the shader in your testcase). These are also pretty much the only use cases of bool and int constants and there are no int or bool "non-constant" registers so essentially no other type conversion is possible. You can check the plain text output from fxc to see how those constants are used in the shader code and how did the compiler manage to convert those constants from one type to another. I tried to compile your HLSL shader myself (I had to disable optimization though, otherwise compilation fails) and, assuming the text output of fxc matches what actually ends up in the shader bytecode, in general I'm getting different struct members in different registersets. E.g. snbf gets allocated to c6-c9 and b8. FWIW, I used fxc from the June 2010 DirectX SDK, on Windows 7. I'm not sure why my results are different from yours. Or am I misunderstanding the test? BTW, what needs to be fixed in Wine? I couldn't see anything obvious by reading the test. Cheers, Matteo. > Cheers > Rico

July 30, 2013

Re: [PATCH 4/5] d3dx9/tests: Add ID3DXConstantTable struct test.

by Rico Schüller

Hi Matteo, please see the attached patch. On 25.07.2013 16:13, Matteo Bruni wrote: > 2013/7/24 Rico Schüller <kgbricola(a)web.de>: >> --- >> dlls/d3dx9_36/tests/shader.c | 308 >> +++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 308 insertions(+) >> > > This is okay, but as a followup can you add some tests with mixed-type > structs? Something like: > > struct > { > float f; > int i; > bool b; > }; > > If you have already written tests of this kind, I'd like to know what > does the compiler do in this case :) > Single variables could only have the tested types (I was not able to generate other conversions than bool->bool, int->int, int->float, bool->float, float->float). But I found a way to do it with structs and there I found some issues. Hence this has to be fixed in wine, too. Thanks for the nice question. :-) Basically you got these for the struct: 1. D3DXRS_FLOAT4: if one variable is used as float or a float variable is used or an int variable is used as bool (the compiler may do some optimization), else #2 2. D3DXRS_BOOL: if a bool variable is used as bool (in an if clause), else #3 3. D3DXRS_INT4 It looks like you could only do it that way with unused variables. I'm not sure if this makes sense at all. Why would someone set an unused variable? Maybe I missed something? Do you know anything else? Cheers Rico

July 30, 2013

Re: Possibility of adding a new patch status

by Vincent Povirk

I think I've seen patches stay in the "New" state in the following cases: * He's convinced you do not have the ability to write a patch he would accept. (There's a common pattern where people will take feedback and attempt to revise their patch to account for it, but not really understand the feedback or how to apply it. The only way to get an acceptable patch in this situation would be to do the work for the submitter.) * He's convinced you're taking a completely wrong approach. (And generally someone has explained this in reply to a previous revision of that patch.) * He thinks there's a good chance you'll revise the patch without his intervention, and is waiting to see if that happens. * The patch is difficult to review, and he's putting it off. * He's travelling and does not have access to a machine that can successfully run the Wine test suite, and he thinks the patch might break the tests. But I'm guessing based on imperfect memory, so I could be wrong.

July 30, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Qian Hong

Forgot to say, as described in the last post, this patch doesn't kill the culprit, please reject the patch, thanks.

July 30, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Qian Hong

Hello Nikolay, On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > This could be some a different bug, and putting exception handler around it > is not necessary a right solution. Good catch, I think you are right. I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after ImmDestroyContext(), the latter frees the input method context if the call successes, but the former try to access the IMC. I have a test case show that in some case native ImmDestroyContext() fails but builtin ImmDestroyContext() success: https://testbot.winehq.org/JobDetails.pl?Key=26499&log_206=1#k206 That is why Office die on Wine but live on Windows, ImmDestroyContext() fails so following ImmLockIMC()/ImmUnLockIMC()/ImmGetIMCCSize() are safe, but on Wine ImmDestroyContext() success and free the memory of the IMC, and... Boom! --- snip --- Call imm32.ImmDestroyContext(08a29b28) ret=3927e447 Ret imm32.ImmDestroyContext() retval=00000001 ret=3927e447 /* success, free the IMC (hIMC == 0x08a29b28) */ Call imm32.ImmLockIMC(08a29b28) ret=09ea2c54 /* would die sooner or later ... */ Ret imm32.ImmLockIMC() retval=08a29b2c ret=09ea2c54 ... Call imm32.ImmGetIMCCSize(00000008) ret=09ea3545 /* 0x00000008 comes from hIMC->IMC.hPrivate, unfortunately hIMC is freed... */ --- snip --- I need more tests to figure out what is the necessary and sufficient conditions to make ImmDestroyContext fails. Thanks for the help! -- Regards, Qian Hong - http://www.winehq.org

July 30, 2013

Call for Windows tests

by Bruno Jesus

Hi, I'm looking for help to test WSAEnumProtocols, I need to collect more information about the values returned from different versions of windows, especially 7 and 8. If you can help please download the file below, unzip, run the .bat and send me back the result.txt file (sources included). http://influenza.blog.br/wsa.zip There is no need to answer to the list. Virustotal.com scan: http://bit.ly/1catW4a Thanks in advance, Bruno

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> You shouldn't check the version, but the actual problem (i.e. the size >> of the offending type). Also please avoid unnecessary changes. > > The offending type is toff_t, it's size is either 32 or 64-bit depending > on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. > So I don't see how checking for the size of toff_t makes it possible to > differentiate between 3.x, 4.x and broken 4.x headers. You can test TIFF_UINT64_T or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2013

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > You shouldn't check the version, but the actual problem (i.e. the size > of the offending type). Also please avoid unnecessary changes. The offending type is toff_t, it's size is either 32 or 64-bit depending on whether it's libtiff 3.0 or 4.0, or whether it's broken 4.0 headers. So I don't see how checking for the size of toff_t makes it possible to differentiate between 3.x, 4.x and broken 4.x headers. -- Dmitry.

July 30, 2013