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

Valgrind --malloc-fill=A5 --free-fill=DE crashes Wine
by Joerg-Cyril.Hoehle＠t-systems.com Feb. 28, 2011

Feb. 28, 2011

Hi, I used to run Valgrind with the additional options --malloc-fill=A5 --free-fill=DE around Wine 1.2 times. Now I retried it and it crashes Wine 1.3.13 and 1.3.14 (it fails to load kernel32.dll). It turns out that malloc-fill is harmless, -free-fill causes havoc currently. Am I the only one using or seeing this (Ubuntu Lucid)? Thanks for your help, Jörg Höhle

3 3

Re: gdi32: first look for a printer driver name in the registry (try 6)
by André Hentschel Feb. 27, 2011

Feb. 27, 2011

Hi, Now you entirely remove the ini-stuff, why? and why do you use a OR (||) for the registry function? -- Best Regards, André Hentschel

2 1

Re: [2/2] msxml3: Reject xmlns attribute to be added to element
by Marvin Feb. 27, 2011

Feb. 27, 2011

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=9543 Your paranoid android. === W2KPROSP4 (32 bit domdoc) === domdoc: unhandled exception c0000005 at 90909090 === WXPPROSP3 (32 bit domdoc) === domdoc: unhandled exception c0000005 at 749BCF8E === W2K3R2SESP2 (32 bit domdoc) === domdoc: unhandled exception c0000005 at 90909090 === WVISTAADM (32 bit domdoc) === domdoc: unhandled exception c0000005 at FF85F88B === W2K8SE (32 bit domdoc) === domdoc: unhandled exception c0000005 at FF8B9090 === W7PRO (32 bit domdoc) === domdoc.c:7308: Test failed: got 0x80070057 domdoc.c:7327: Test failed: got 0x00000000 domdoc.c:7351: Test failed: got 0x80070057 domdoc.c:7360: Test failed: got 0x80070057 domdoc.c:7396: Test failed: got 0x80070057 === W7PROX64 (32 bit domdoc) === domdoc.c:7308: Test failed: got 0x80070057 domdoc.c:7327: Test failed: got 0x00000000 domdoc.c:7351: Test failed: got 0x80070057 domdoc.c:7360: Test failed: got 0x80070057 domdoc.c:7396: Test failed: got 0x80070057 === W7PROX64 (64 bit domdoc) === domdoc.c:7308: Test failed: got 0x80070057 domdoc.c:7327: Test failed: got 0x00000000 domdoc.c:7351: Test failed: got 0x80070057 domdoc.c:7360: Test failed: got 0x80070057 domdoc.c:7396: Test failed: got 0x80070057

1 0

Re: msxml3/tests: Remove broken test and parameter check
by Nikolay Sivov Feb. 27, 2011

Feb. 27, 2011

On 2/27/2011 22:09, Nikolay Sivov wrote: > Test was recently enabled, and it crashes on several machines, > including mine. QueryInterface generally should never check for return > pointer. > Ignore that please, there's another line to remove.

1 0

Re: [PATCH 1/5] d3dcompiler: Fix SystemValueType for pixelshader output signature.
by Henri Verbeet Feb. 27, 2011

Feb. 27, 2011

2011/2/27 Rico Schüller <kgbricola(a)web.de>: > +static BOOL case_insensitive_compare(const char *s1, const char *s2) Isn't that called strcasecmp()?

1 0

Patches to fix GetDIBits for top down destination bitmaps
by John Edmonds Feb. 27, 2011

Feb. 27, 2011

Please ignore the patches http://source.winehq.org/patches/data/71716 and http://source.winehq.org/patches/data/71711. I was having trouble with my mail client and accidentally sent the same code 3 times.

1 0

Re: comctl32: Shed an unused parameter of TOOLTIPS_HitTestT and rename to TOOLTIPS_HitTest.
by Nikolay Sivov Feb. 27, 2011

Feb. 27, 2011

On 2/26/2011 23:01, Gerald Pfeifer wrote: > --- > dlls/comctl32/tooltips.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index a2e58e0..445845c 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1396,8 +1396,7 @@ TOOLTIPS_GetToolInfoT (const TOOLTIPS_INFO *infoPtr, TTTOOLINFOW *ti, BOOL isW) > > > static LRESULT > -TOOLTIPS_HitTestT (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit, > - BOOL isW) > +TOOLTIPS_HitTest (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit) > { > TTTOOL_INFO *toolPtr; > INT nTool; > @@ -2209,8 +2208,8 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > > case TTM_HITTESTA: > case TTM_HITTESTW: > - return TOOLTIPS_HitTestT (infoPtr, (LPTTHITTESTINFOW)lParam, > - uMsg == TTM_HITTESTW); > + return TOOLTIPS_HitTest (infoPtr, (LPTTHITTESTINFOW)lParam); > + > case TTM_NEWTOOLRECTA: > case TTM_NEWTOOLRECTW: > return TOOLTIPS_NewToolRectT (infoPtr, (LPTTTOOLINFOW)lParam); This should properly handle text instead of removing A/W case.

2 1

Re: d3dx9: Implement D3DXFloat32To16Array and D3DXFloat16To32Array. (try 2)
by Misha Koshelev Feb. 27, 2011

Feb. 27, 2011

> Hi Misha, > > ... > > I'm attaching your patch with some modifications (mostly I took some > missing pieces from my old, way broken, patch). It seems to help a bit > but it's not perfect yet. It fixes handling of > 65520.0 values and > denormalized numbers. The interesting bit was to have some ad-hoc > rounding for the denormalized case. > The current implementation doesn't match native on some rounding > cases, but it's not clear what really the issue is. If you replace >= > with a > in "if (tmp - mantissa >= 0.5f) mantissa++;" you essentially > switch some failing cases with others. Maybe it has something to do > with floating point CPU rounding mode, but that seems unlikely to me. > Some testing under Windows is also needed. > > Ok, that's all. Please continue your work, correct 32/16 bit float > conversion functions are really a good thing to have (and you can fix > the implementation in wined3d after this is done ;)) > Hi Guys, Just thought I'd forward to the list (I hope it's ok Matteo). I'm pretty stumped. Matteo's patches were a big help. I did test on Windows and saw same result. My own (very unhelpful) diagnosis of the pattern is that, for the mantissa values: 2018.5 should round to 2018 2019.5 should round to 2020 2016.5 should round to 2016 2017.5 should round to 2018 2014.5 should round to 2014 2015.5 should round to 2016 2012.5 should round to 2012 2013.5 should round to 2014 1954.5 should round to 1954 1955.5 should round to 1956 1952.5 should round to 1952 1953.5 should round to 1954 1950.5 should round to 1950 1951.5 should round to 1952 1948.5 should round to 1948 1949.5 should round to 1950 I have attached a patch that makes this explicit and has just one failing test. Unfortunately, if we change the increment from 0xfff to 0xff, we seem to have a lot more disagreements. If anyone has any ideas pls let me know. I am stumped. I am going to see if perhaps I can make the relevant game work better by stubbing, and, if so, will submit a stub patch for now. Thank you Misha p.s. Note: the singles2halfp function is not mine, and is licensed under the BSD license. I modified it slightly to see if it would make things better. It didn't. It is not meant to actually be included in Wine but is useful for testing. http://www.mathworks.com/matlabcentral/fileexchange/23173 Thank you

2 2

Re: [3/3] comctl32/tests: Add a statusbar test for setting number of parts to zero.
by Marvin Feb. 27, 2011

Feb. 27, 2011

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=9486 Your paranoid android. === WNT4WSSP6 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2KPROSP4 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === WXPPROSP3 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2K3R2SESP2 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === WVISTAADM (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W2K8SE (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PRO (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PROX64 (32 bit status) === status.c:412: Test failed: Expected 1, got 0 === W7PROX64 (64 bit status) === status.c:412: Test failed: Expected 1, got 0

2 1

Re: kernel32/tests: remove win9x hacks (try 2)
by Damjan Jovanovic Feb. 26, 2011

Feb. 26, 2011

On Wed, Feb 23, 2011 at 11:38 AM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in?

6 10