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

Re: gdi32: Text output of records EMR_EXTTEXTOUTA/W depend on field iGraphicsMode

by Austin English

On Mon, Feb 7, 2011 at 15:49, Alexander Kochetkov <al.kochet(a)gmail.com> wrote: > Fix for bug #22996, and likely for bug #16557. > > BTW, I think, what the same problem exist with EMR_POLYTEXTOUTA/W records. Forgot the patch. -- -Austin

Feb. 8, 2011

Re: mstask/tests: make sure return values are used (LLVM/Clang)

by Marvin

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=9011 Your paranoid android. === WNT4WSSP6 (32 bit task_trigger) === task_trigger.c:165: Test failed: Failed to setup test_task

Feb. 8, 2011

Re: inetcomm/tests: make sure to use return values (LLVM/Clang)

by Marvin

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=9009 Your paranoid android. === WXPPROSP3 (32 bit mimeole) === No test summary line found

Feb. 8, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.02.2011 um 23:49 schrieb Misha Koshelev: I have no full explanation yet, just bits and pieces. By the way, if you haven't done so already I recommend a thorough study of http://en.wikipedia.org/wiki/Floating_point for background knowledge. http://en.wikipedia.org/wiki/IEEE_754-2008 may also be interesting, but I haven't read that wikipedia page so I don't really know what is in it. > I believe I've found that the threshold value is actually 65520.0 for > conversions from single to half precision That makes sense, it is halfway between 65536 and 65604. At this threshold values are rounded up or down > In any case, I have gotten the half to single precision conversion to > work in Wine by extending to 16 bits for the exponent (changing < 31 > to < 32). You may as well replace it with TRUE because the exponent won't be >= 32. Too few bits to express anything bigger than 31. > However, I am still having trouble with the single to half precision > and believe I am spinning my wheels a bit at this point. I'm still trying to make sense of the Windows values :-/ > math.c:2249: Test failed: Got 7800, expected 7bff or 7bff for index 3. Looks like the exponent is 1 too high and the mantissa zero instead of 1023. Probably a rounding / off by one bug in the code from wined3d. Different behavior wrt what happens when you exactly hit the rounding threshold. (Ie, do you round an exact 5 up or down(to 0 or 10)?) > math.c:2249: Test failed: Got ffff, expected fc00 or fce2 for index 8. > math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 12. > math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 13. > math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 14. > math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 15. This is this statement: + if (*in < -65520) return 0xFFFF; You probably wanted to return fc00 here, if you are trying to emulate case 1. Otherwise remove both CONFUSION HERE statements, change the if(exp > 30) case to exp > 31 and set ret = 0x7fff there. This will give you case 2. > math.c:2249: Test failed: Got 6400, expected 7fff or 7fff for index 18. > math.c:2249: Test failed: Got 6400, expected ffff or ffff for index 19. Hmm, I am afraid you can't remove the check for NaN entirely. If you try to any float operation on NaN undefined things are going to happen(Well, you get NaN, and later try to pick its bits apart) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNUH4mAAoJEN0/YqbEcdMwiNcP/R4sa+Z6L39FtN8qE1nX+Pwj KER3a4MWQ8DWDQgjXR09l3kYua9tM8kH5XmZNNpthH5Uck/CCdFOfCx+j3+CLuJq nbFkT5kwVA4qzv67o9qJxJhCaL2+9rXtB6ADOSU3QfLYn7L/UXzxwENzxgQlvFG5 +0GzkdlimMGB8+Rj8mYte/ORFEQQnLoCFe3d1UT9RQQhOCqQvlDuaptBWQCiFiAc GgSQuBzC7YbZxLz8i0EDjfn50X5lW0iVo0p682RJzmod+oCeFztjY/G33wGyA1MA 45Ui6onTYpN1OES1esw/WtePkM8dKrSDlw+gu5rmU9c8JwhPFnNvs/1FUvHD1bGG WjHkv3hLCf3XVjMk1aT70ItFQ8ph2b6IlU3GOSvQvrYbDB8jfb7lbJnuqzd4hrd4 ycTzAf5YULwuQ5m7Ie5QtWO+hG0iB/I0aqGIAnNj6tSO3b/bfmBlQKAauVnoUnDq sYgIEmW0GO15Ndsd/ipfbh414qQsNPyGQNdnhivkJK2PrVaiyXb/ztJf/vLDKjEw cRPoaAfQyIsfPD+cqKq4pnw2rwvr2tkOby11UQ8jfDeaTldp3redf0py0o37CGq1 520QC0CqC/A4MHawwbgcbFTi6XX/DCkHW4IOEirJvnweV8mw8V9IP4XyY/xmYepV ukB4hwY8XvIe4/Zxj8IP =bs4K -----END PGP SIGNATURE-----

Feb. 7, 2011

Re: comctl32/tests: Fixed variable type, removed sign comparison warning.

by Nikolay Sivov

On 2/8/2011 00:26, Marko Nikolic wrote: > --- > dlls/comctl32/tests/trackbar.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/comctl32/tests/trackbar.c b/dlls/comctl32/tests/trackbar.c > index ac67d50..714a321 100644 > --- a/dlls/comctl32/tests/trackbar.c > +++ b/dlls/comctl32/tests/trackbar.c > @@ -953,7 +953,7 @@ static void test_ignore_selection(HWND hWndTrackbar){ > static void test_initial_state(void) > { > HWND hWnd; > - DWORD ret; > + HRESULT ret; > > hWnd = create_trackbar(0, hWndParent); This is wrong, did you mean LRESULT?

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

On Mon, Feb 7, 2011 at 2:14 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag 07 Februar 2011, 19:37:09 schrieb Misha Koshelev: >> Stefan: I believe this is actually a _difference_ between Windows versions. >> >> As you will note on the full results from winetestbot as well as my >> own testing on XP (what I _thought_ was SP3) is that only 3/9 >> platforms have this error. The rest pass fine. Thus, it seems a >> variance in the tests. > The results still don't make sense. > > Basically it seems to me that native d3dx9 lacks support for NaN and INF. > Those magic numbers are created by making the highest possible exponent a > special marker(thus reduce exp_max by 1 and make exp_max + 1 special). This is > why halfs end up with 65536.0 as just not reachable number. The highest > exponent is 15, the highest mantissa value is 1023. This gives value = 2^15 * > (1 + 1023/1024) = 65504. > > However, it looks like Windows(all versions) treat e = 16 like regular > numbers, allowing max numbers from -131008.0 to +131008.0. This is shown by > the conversion of 0x7fff to 131008.0 and 0xffff to -131008.0, and the conversion > of -INF to 0xffff (sign bit, exp=max+1=16, mantissa=max=1023). I suspect someone > tested INF and saw that it was converted into something that looked like NaN > and added a line like this: > > if(isinf(input)) return 0x7c00; > or > if(input > 65504) return 0x7c00; > > but didn't properly implement NaN and INF. Then someone realized such a check > is just stupid given the lack of infrastructure and removed it. And since the > code is maybe written in assembler the check got only removed from the 32 bit > version, not the 64 bit one. (Notice how old windows versions and 64 bit ones > return 0x7c00 and new 32 bit ones return 0x7fff). > > I'd suggest a few more tests: See what a number like 80000.0 is converted to. > Look what happens to 65503, 65504, 65505, 65534, 65535, 65536. And see what > values like 0x7c01,7c02, 7ffe, 7ffd are converted to. > Thanks Stefan. I believe I've found that the threshold value is actually 65520.0 for conversions from single to half precision (tests are still running but I checked on my machine at least so the half_ver1 values are correct; additionally, I tested half_ver2 without the negative numbers previously on winetestbot http://testbot.winehq.org/JobDetails.pl?Key=8995) The full test results with the attached patch will be here: https://testbot.winehq.org/JobDetails.pl?Key=9000 In any case, I have gotten the half to single precision conversion to work in Wine by extending to 16 bits for the exponent (changing < 31 to < 32). However, I am still having trouble with the single to half precision and believe I am spinning my wheels a bit at this point. Here are the errors I'm getting: math.c:2249: Test failed: Got 7800, expected 7bff or 7bff for index 3. math.c:2249: Test failed: Got ffff, expected fc00 or fce2 for index 8. math.c:2249: Test failed: Got f800, expected fbff or fbff for index 11. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 12. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 13. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 14. math.c:2249: Test failed: Got ffff, expected fc00 or fc00 for index 15. math.c:2249: Test failed: Got 6400, expected 7fff or 7fff for index 18. math.c:2249: Test failed: Got 6400, expected ffff or ffff for index 19. Any ideas? Thanks Misha

Feb. 7, 2011

Re: Killing WineAPI project on SourceForge.

by Alexandre Julliard

Steve Brown <sbrown7(a)umbc.edu> writes: > I've seen this discussion come and go a few times... Would something > like LXR be appropriate for generating a web front-end to searching > and indexing the Wine source code? Yes, and it's been in place for years: http://source.winehq.org -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2011

Re: Including winegcc-built shared library in Debian binary package

by Alexandre Julliard

Robert McDonald <rmcdonald(a)bittorrent.com> writes: > Is there a more appropriate installation directory than /usr/lib for > the shared library (although lintian complains if I don't put it in > /usr/lib)? It should go in /usr/lib/wine. > Does ldconfig need to be run after installing/uninstalling the shared > library (other than to satisfy lintian complaints if ldconfig isn't > run from postinst/postrm)? ldconfig is not needed. > Is there any reason to bother with version numbering the shared > library (other than using one version number for all library releases > just to keep lintian happy by having the version number) since the > library is prepared by winegcc and will only be loaded by wine? There's no support for version numbering in Wine dlls. -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2011

RE: iphlpapi: Changed return value of NotifyAddrChange() stub and added test cases.

by Janne Hakonen

> in todo_wine blocks only ok() calls should be made. > So consider splitting them down to "todo_wine ok(..." for each. Ah thank you, I will change them. > > -CancelIPChangeNotify > > CreateProxyArpEntry > > DeleteIPAddress > > DeleteProxyArpEntry > > EnableRouter > > FlushIpNetTable > > GetAdapterIndex > > -NotifyAddrChange > > -NotifyRouteChange > > +NotifyRouteChange + CancelIPChangeNotify > > this change regarding CancelIPChangeNotify is also not needed. CancelIPChangeNotify is used when testing NotifyAddrChange. It cancels the overlapped notify call. The function can be used also to cancel NotifyRouteChange calls. I changed it like that so that when NotifyRouteChange is also implemented the cancelling is also tested with that one. If I would have left CancelIPChangeNotify in the list like it was, then someone might wonder why it is still in the list even though it used in the tests with NotifyAddrChange. Best Regards, Janne Hakonen

Feb. 7, 2011

Re: iphlpapi: Changed return value of NotifyAddrChange() stub and added test cases.

by André Hentschel

Hi, in todo_wine blocks only ok() calls should be made. So consider splitting them down to "todo_wine ok(..." for each. > -CancelIPChangeNotify > CreateProxyArpEntry > DeleteIPAddress > DeleteProxyArpEntry > EnableRouter > FlushIpNetTable > GetAdapterIndex > -NotifyAddrChange > -NotifyRouteChange > +NotifyRouteChange + CancelIPChangeNotify this change regarding CancelIPChangeNotify is also not needed. -- Best Regards, André Hentschel

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

Am Montag 07 Februar 2011, 19:37:09 schrieb Misha Koshelev: > Stefan: I believe this is actually a _difference_ between Windows versions. > > As you will note on the full results from winetestbot as well as my > own testing on XP (what I _thought_ was SP3) is that only 3/9 > platforms have this error. The rest pass fine. Thus, it seems a > variance in the tests. The results still don't make sense. Basically it seems to me that native d3dx9 lacks support for NaN and INF. Those magic numbers are created by making the highest possible exponent a special marker(thus reduce exp_max by 1 and make exp_max + 1 special). This is why halfs end up with 65536.0 as just not reachable number. The highest exponent is 15, the highest mantissa value is 1023. This gives value = 2^15 * (1 + 1023/1024) = 65504. However, it looks like Windows(all versions) treat e = 16 like regular numbers, allowing max numbers from -131008.0 to +131008.0. This is shown by the conversion of 0x7fff to 131008.0 and 0xffff to -131008.0, and the conversion of -INF to 0xffff (sign bit, exp=max+1=16, mantissa=max=1023). I suspect someone tested INF and saw that it was converted into something that looked like NaN and added a line like this: if(isinf(input)) return 0x7c00; or if(input > 65504) return 0x7c00; but didn't properly implement NaN and INF. Then someone realized such a check is just stupid given the lack of infrastructure and removed it. And since the code is maybe written in assembler the check got only removed from the 32 bit version, not the 64 bit one. (Notice how old windows versions and 64 bit ones return 0x7c00 and new 32 bit ones return 0x7fff). I'd suggest a few more tests: See what a number like 80000.0 is converted to. Look what happens to 65503, 65504, 65505, 65534, 65535, 65536. And see what values like 0x7c01,7c02, 7ffe, 7ffd are converted to.

Feb. 7, 2011

Re: oleaut32: Fix copying an array of 0 elements

by Marvin

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=8987 Your paranoid android. === WNT4WSSP6 (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W2KPROSP4 (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === WXPPROSP3 (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W2K3R2SESP2 (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === WVISTAADM (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W2K8SE (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W7PRO (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W7PROX64 (32 bit safearray) === safearray: unhandled exception c0000005 at 0040E5A5 === W7PROX64 (64 bit safearray) === Timeout

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

On Mon, Feb 7, 2011 at 3:32 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Am 07.02.2011 um 03:37 schrieb Misha Koshelev: >> + FLOAT full[10] = { 1.0f, -2.0f, 6.55e4, 6.10352e-5, 5.96046e-8, 0.0f, -0.0f, INFINITY, -INFINITY, NAN }, >> + full_exp[10] = { 1.0f, -2.0f, 6.55e4, 6.10352e-5, 5.96046e-8, 0.0f, -0.0f, 65536.0f, -131008.0f, 131008.0f }, >> + full_res[10]; > I'd rather call them "single" instead of full because 32 bit floats are usually referred to as single precision(doubles are double precision, and 16 bit floats half precision) Done. > >> math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. > Looks like Windows doesn't do INF, and returns NaN instead. Your -INF value test already expects NaN as return value, but with the sign bit set. INF or -INF should have all mantissa bits set to 0. NaN looks like +/- INF, just with mantissa != 0(so there are many possible encodings of NaN). > > However, it is also possible that Windows doesn't support those special values at all. This is suggested by the fact that +/- NaN is happily converted into a proper single precision value. Stefan: I believe this is actually a _difference_ between Windows versions. As you will note on the full results from winetestbot as well as my own testing on XP (what I _thought_ was SP3) is that only 3/9 platforms have this error. The rest pass fine. Thus, it seems a variance in the tests. Please see http://testbot.winehq.org/JobDetails.pl?Key=8981. I have attached a patch that passes all tests: https://testbot.winehq.org/JobDetails.pl?Key=8985 What do you think? If I am missing something please do let me know. Thank you Misha p.s. I heard down the grapevine that Henri might be on vacation for a week. If so, please wish him the best for me and I hope he enjoys his time. If I am mistaken, would be great to know. Thank you. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > iQIcBAEBAgAGBQJNT64vAAoJEN0/YqbEcdMwHskP/2UvtNtsTuC6wL9skKbAhMxf > 9AyjSx+k8BOb2fQpkLrrR8gPC3feERax+MCrprPDgjSWftWKxWezfRDSAL9eR/+E > BQNRq0v+NfEITVCHVbMee3CNV+acWv2rXViz2HT03JCbuTe3htBytf8XPGPcrfUj > ls1KjNPVoYxH5cQJ4sVwAxbMR7CVI9F++B9LiLV8UzJkeYhztilKC3Qu+PLj1QFh > jXhfbwHMgCo4cunLIPTxZFndFcLvKwHVUSpZcFmY/OQBxWDAKqlo4fQKVw8Gonlb > Q0AbwKMbWQeOPq8Wlyb0XFV35qdUdDkAkJ0139SiyMCakgzmnebAmpx2Ur5/LNQl > t82jG+30Ajvnq43oXyczrmoueLtCdOqrXUiEl8wSpcQqFdC13N67NzzGNRvhBfNK > wJw25P9VZZCvpw5Wx3iqVXpk1Honrjmrn/hgLLHCKOA1Iv4mByp1svu263n4mfIq > Ga3gUdKzcv++1qr9eOfFfG7waGxrNZ8+X2q5Pp6f0SmeoX2nlhYjzOlCOdFDbFA1 > yEjHXFYkeZw9PD83c7fOkpLkrEcyDCEol9reDzzQXqmFKYoYP2JLLvRjjnPWoxk0 > LviYxmFQ1kZMBhR6WojGx1WjEPVEa+uQxmrK4n6H8fymsXVGu5TfbFgJvmrmg2hG > hRDKzYpNRuUYojjHKP6N > =EhgD > -----END PGP SIGNATURE----- >

Feb. 7, 2011

Patch to fix ntdll:exception tests on Mac OS

by Charles Davis

Hi, This is a small patch I wrote to fix the exception tests on Mac OS X. Right now, if you look at the Mac results I submitted, you'll notice that there are two failures. The first failure happens because Mach doesn't allow the 'global' flag to be set when setting the debug registers. Changing the test not to set the global flag causes the test to pass. I get the feeling, though, that there is a good reason the global flag was set, so I'm reluctant to send that change in. The other failure happens because 32-bit Mac OS only protects stacks from execution. If you clear PROT_EXEC on any other data, you can still execute code from it. (64-bit Mac OS, on the other hand, always respects the PROT_EXEC flag.) I changed ntdll on 32-bit Mac OS to report DEP as permanently disabled, but I wonder if this was the right change to make. I just want to know: am I doing the right thing here? If not, what should I do instead to fix the tests? Chip

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.02.2011 um 03:37 schrieb Misha Koshelev: > + FLOAT full[10] = { 1.0f, -2.0f, 6.55e4, 6.10352e-5, 5.96046e-8, 0.0f, -0.0f, INFINITY, -INFINITY, NAN }, > + full_exp[10] = { 1.0f, -2.0f, 6.55e4, 6.10352e-5, 5.96046e-8, 0.0f, -0.0f, 65536.0f, -131008.0f, 131008.0f }, > + full_res[10]; I'd rather call them "single" instead of full because 32 bit floats are usually referred to as single precision(doubles are double precision, and 16 bit floats half precision) > math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. Looks like Windows doesn't do INF, and returns NaN instead. Your -INF value test already expects NaN as return value, but with the sign bit set. INF or -INF should have all mantissa bits set to 0. NaN looks like +/- INF, just with mantissa != 0(so there are many possible encodings of NaN). However, it is also possible that Windows doesn't support those special values at all. This is suggested by the fact that +/- NaN is happily converted into a proper single precision value. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNT64vAAoJEN0/YqbEcdMwHskP/2UvtNtsTuC6wL9skKbAhMxf 9AyjSx+k8BOb2fQpkLrrR8gPC3feERax+MCrprPDgjSWftWKxWezfRDSAL9eR/+E BQNRq0v+NfEITVCHVbMee3CNV+acWv2rXViz2HT03JCbuTe3htBytf8XPGPcrfUj ls1KjNPVoYxH5cQJ4sVwAxbMR7CVI9F++B9LiLV8UzJkeYhztilKC3Qu+PLj1QFh jXhfbwHMgCo4cunLIPTxZFndFcLvKwHVUSpZcFmY/OQBxWDAKqlo4fQKVw8Gonlb Q0AbwKMbWQeOPq8Wlyb0XFV35qdUdDkAkJ0139SiyMCakgzmnebAmpx2Ur5/LNQl t82jG+30Ajvnq43oXyczrmoueLtCdOqrXUiEl8wSpcQqFdC13N67NzzGNRvhBfNK wJw25P9VZZCvpw5Wx3iqVXpk1Honrjmrn/hgLLHCKOA1Iv4mByp1svu263n4mfIq Ga3gUdKzcv++1qr9eOfFfG7waGxrNZ8+X2q5Pp6f0SmeoX2nlhYjzOlCOdFDbFA1 yEjHXFYkeZw9PD83c7fOkpLkrEcyDCEol9reDzzQXqmFKYoYP2JLLvRjjnPWoxk0 LviYxmFQ1kZMBhR6WojGx1WjEPVEa+uQxmrK4n6H8fymsXVGu5TfbFgJvmrmg2hG hRDKzYpNRuUYojjHKP6N =EhgD -----END PGP SIGNATURE-----

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Misha Koshelev

Sorry guys. Looks like there are differences between Windows version. Sigh. Will fix. Henri, will you get a chance to look at the patch before I re-send so that I can fix any other defects you might see? I don't want to send too many resends to the list. Thank you so much Misha On Sun, Feb 6, 2011 at 9:32 PM, Marvin <testbot(a)testbot.winehq.org> 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=8981 > > Your paranoid android. > > > === WXPPROSP3 (32 bit math) === > math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. > > === WVISTAADM (32 bit math) === > math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. > > === W7PRO (32 bit math) === > math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. >

Feb. 7, 2011

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

by Marvin

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=8981 Your paranoid android. === WXPPROSP3 (32 bit math) === math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. === WVISTAADM (32 bit math) === math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7. === W7PRO (32 bit math) === math.c:2238: Test failed: Got 7fff, expected 7c00 for index 7.

Feb. 7, 2011

Re: user32: Don't try to move mouse to (-1,0).

by Jacek Caban

On 2/6/11 5:33 AM, Vitaliy Margolen wrote: > On 02/05/2011 07:10 AM, Jacek Caban wrote: >> >> This trigers screen edge action on KDE, which is 'Present Windows' in >> default configuration. > > mouse_event() generates relative mouse movement events unless > MOUSEEVENTF_ABSOLUTE is specified. If you don't want a pointer to get > near the edge then you should use SetCursorPos() instead. It's enough that we don't try to move the cursor up nor left when it's in the edge. Jacek

Feb. 6, 2011

Re: Wine FAQ edits

by Rosanne DiMesio

On Sat, 5 Feb 2011 21:49:30 -0500 Albert Lee <trisk(a)forkgnu.org> wrote: > > I think relying on tilde expansion can can be considered > good practice for the interactive use case. > Tilde expansion doesn't work if there are quotes around the path, and if you search the forum, you will find instances of users who did not know that and didn't understand why they were getting "No such file or directory" messages. $HOME is better because it can be used inside quotes, but what I have found to be most understandable to newbies is simply /home/user/ with a note telling them to substitute their username for user. (Yes, there are people who need to be told that. This is the level of technical knowledge you are writing for in the FAQ.) -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 6, 2011

Re: Pulling Patch

by Shachar Shemesh

On 06/02/11 11:13, Damjan Jovanovic wrote: > > > On Sat, Feb 5, 2011 at 5:48 PM, Shachar Shemesh <shachar(a)shemesh.biz > <mailto:shachar(a)shemesh.biz>> wrote: > > On 05/02/11 00:24, James McKenzie wrote: > > Actually, the latest patch is what I don't want reused. And > no, you don't put it in the LGPL until it is committed, which > I don't expect AJ to do anyway. > > However, I'm moving in a different direction since my Mac > needs more repairs than I'm willing to spend money on. > > Besides, I've been a big enough pain that my existence here is > unwarranted and unneeded. > > As anyone who attended the last WineConf probably already knows, > you have my complete sympathies in that regard. I also doubt very > much anyone would use your uncommitted patches against your will, > so in that respect, you probably have nothing to worry about. > > That said, I believe your claim to the right to demand no use is > wrong. It is my understanding that by submitting your patches to > wine-patches, you have placed them under the LGPL, which is a > non-revocable license. Again, in all likely hood, this is a purely > hypothetical question. > > > If the LGPL is non-revocable, is code you've placed under it still > re-licensable, by you, under another license, as long as you don't > revoke the LGPL in the process? > > ie. could I submit a piece of code to Wine and to another project? First, IANAL. You do not give up your copyright when you license code under the LGPL (or any other open source license). You merely provide a license (which is irrevocable). As such, the answer is "yes". You can license code for which you own the complete copyrights under as many licenses of any type you wish to as many recipients as you wish, even if the licenses conflict. That said, if the copyright is only for derivative work, then you also need a license for the original work. The only license you have for the original work in the case of Wine is the LGPL, and THAT LICENSE is conditioned upon the fact that you license your own code under the LGPL only. As such, you cannot license changes to wine under another license, despite the fact you have the copyright for it, as that would leave you without the license to create your derivative work in the first place. So the real question is how independent your code is that you wish to submit. As long as you do not copy code from wine, you can submit the same change to as many open source projects as you like (even if their licenses are conflicting), and even use it for a proprietary project. If, however, the code requires Wine code in order to make sense, then you are bound by the LGPL and need to only use the code in a compliant way. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Feb. 6, 2011

Re: Pulling Patch

by Damjan Jovanovic

On Sat, Feb 5, 2011 at 5:48 PM, Shachar Shemesh <shachar(a)shemesh.biz> wrote: > On 05/02/11 00:24, James McKenzie wrote: > > Actually, the latest patch is what I don't want reused. And no, you don't >> put it in the LGPL until it is committed, which I don't expect AJ to do >> anyway. >> >> However, I'm moving in a different direction since my Mac needs more >> repairs than I'm willing to spend money on. >> >> Besides, I've been a big enough pain that my existence here is unwarranted >> and unneeded. >> >> As anyone who attended the last WineConf probably already knows, you have > my complete sympathies in that regard. I also doubt very much anyone would > use your uncommitted patches against your will, so in that respect, you > probably have nothing to worry about. > > That said, I believe your claim to the right to demand no use is wrong. It > is my understanding that by submitting your patches to wine-patches, you > have placed them under the LGPL, which is a non-revocable license. Again, in > all likely hood, this is a purely hypothetical question. > > If the LGPL is non-revocable, is code you've placed under it still re-licensable, by you, under another license, as long as you don't revoke the LGPL in the process? ie. could I submit a piece of code to Wine and to another project? Shachar > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd. > http://www.lingnu.com > > > > Damjan Jovanovic

Feb. 6, 2011

Re: Wine FAQ edits

by David Laight

On Sat, Feb 05, 2011 at 09:49:30PM -0500, Albert Lee wrote: > > Anyone using the original Bourne sh *interactively* is in for a world > of pain anyway (speaking as someone who often had to before the ksh93 > replacement). I think relying on tilde expansion can can be considered > good practice for the interactive use case. I wouldn't rely on ~ expansion - not unless you detect that it has returned empty string. Although anyone using a system that doesn't support it (most likely Solaris's /bin/sh) will probably know how to avoid the problem, not knowing what is wrong is more problematical. Adding a few 'sh' conditional substitutions to a script might show some people just how powerful the language is - especially if they have onely ever seen windows cmd.com .bat scripts. I've seen some recent systems fail to expand ~ properly (for some definition of the word 'properly') most noticably cygwin on windoes 7. David -- David Laight: david(a)l8s.co.uk

Feb. 6, 2011

Re: user32: Don't try to move mouse to (-1,0).

by Vitaliy Margolen

On 02/05/2011 07:10 AM, Jacek Caban wrote: > > This trigers screen edge action on KDE, which is 'Present Windows' in > default configuration. mouse_event() generates relative mouse movement events unless MOUSEEVENTF_ABSOLUTE is specified. If you don't want a pointer to get near the edge then you should use SetCursorPos() instead. Vitaliy.

Feb. 6, 2011

Re: Wine FAQ edits

by Vitaliy Margolen

On 02/05/2011 07:54 PM, Albert Lee wrote: > Instead, I am suggesting reducing the complexity of the solution, Multiple expansions, redirections and use of xargs is hardly a simplification of a script with 2 parameters. Again, we are not talking about advanced skills here. We talking about users who do not understand what expansion, redirection are. Let alone xargs. In either case please don't add such complex scripts into FAQ. Keep it simple. Vitaliy.

Feb. 6, 2011

Re: Wine FAQ edits

by Albert Lee

On Thu, Feb 3, 2011 at 9:49 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 02/03/2011 09:17 AM, Albert Lee wrote: >> >> The instructions were intended to give some context for users who >> might not be familiar with the ~ expansion. > > Then mention that if you must. "~" is used in number of other places in FAQ, > and all over the net. Please keep it simple. > I will add that, since we're not properly explaining it currently. >> It's a fairly trivial one-liner as it is > > Which will blow away most windows users who have no concept of expansions > and redirections. You not writing developer's guide, you writing FAQ for > clueless windows users who want Wine do what they need. The existing implementation is not exactly transparent to new users either, and we're not attempting to explain in detail how it works. Instead, I am suggesting reducing the complexity of the solution, which also reduces the work for the user. -Albert

Feb. 6, 2011