Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Nikolay Sivov [EMAIL PROTECTED] writes: I don't think so. If the call fails testing return value doesn't make any sense. In this case 'result' is uninitialized and remains uninitialized after a call if it fails (here I mean a native too). So why should we check something which has unpredictable value? By the way first time I saw this here 8fd6f0e26ae28f2ba4938e2fbcc4851f47baa53c.. The difference is that this was a todo_wine, so it's expected to fail and we don't want to test uninitialized data since that can cause random test failures. In your case the test is expected to succeed, so the only way you'll get uninitialized data is when the first test fails, and then it doesn't matter if we get a random second failure, the test failed already. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Alexandre Julliard wrote: Nikolay Sivov [EMAIL PROTECTED] writes: I don't think so. If the call fails testing return value doesn't make any sense. In this case 'result' is uninitialized and remains uninitialized after a call if it fails (here I mean a native too). So why should we check something which has unpredictable value? By the way first time I saw this here 8fd6f0e26ae28f2ba4938e2fbcc4851f47baa53c.. The difference is that this was a todo_wine, so it's expected to fail and we don't want to test uninitialized data since that can cause random test failures. In your case the test is expected to succeed, so the only way you'll get uninitialized data is when the first test fails, and then it doesn't matter if we get a random second failure, the test failed already. I see. I've just reposted it with 'try3' label, there's no linking based on return value now. Now I'm explicitly initialize output before each call to be sure that values changed or not. What do you think about matrix comparison or in general float comparison implementation? What is the best way to implement this. We have two cases now: 1. GdipIsMatrixEqual which compares two matrices (with simple bitwise operation now) 2. GdipIsMatrixInvertible which contains a check for 'not above zero' determinant. I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that?
Re: CUDA wrapper
Am Samstag, den 12.07.2008, 20:52 -0400 schrieb Seth Shelnutt: [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] winedbg [EMAIL PROTECTED] WineDbg starting on pid 0024 start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904 0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp) 904 ExitThread( entry( peb ) ); Wine-dbgn fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x), stub! err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0xf7facaaf Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it Process of pid=0024 has terminated Wine-dbg I believe the key line is Invalid address (0x7b877d07 start_process +0xc7) for breakpoint 0, disabling it. No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code 0xc005 is a general protection fault. After your program has crashed, the breakpoint wine automatically sets to catch program startup is not valid anymore (there is no program to break anymore), that causes the message you quoted. Whats strange is that the debugger does not catch the exception. While the first-chance event can be disabled, you should get a last-chance exception catch right before the program dies. See http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info about configuring the debugger. Have you tried a relay trace yet? Regards, Michael Karcher
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Am Sonntag, den 13.07.2008, 12:42 +0400 schrieb Nikolay Sivov: I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that? That might a good approach if we want to implement some new API and want to do it sensibly. That's the point where design questions are asked. But the Wine project works the other way round: Wine is bug-for-bug compatible with Microsoft Windows. This means we have to design the same way as Microsoft, whether we think this behaviour is idiotic or not. [Next paragraph is generally about Wine development. I do not imply that you are going to violate the rules stated here or already have sone so. Its just for your (or everybody who reads this mail in the archive) information] So: First you try out what native does. And I mean *try* *out*, not reverse engineer by disassembling. To proof that you have tried out what native does, you publish your tests as wine testcases. Then you implement wine in a way these testcases pass. For myself, I think it is acceptable to implement some API without comparing to native first, if you get an application to run by that, *but* to get this patch included, you better write an API test that shows how that application used the API you changed (or implemented) and verifies that your implementation not just happen to make the application run, but really returns the same result as native does. If you post a patch, always be prepared to be asked to test further cases. It greatly increases your chance to get your patch committed if you add these further cases (often, they show deficiencies in your patch then). Modify your patch to make these tests pass too, or (with a convincing explanation why this would be out-of-scope for your patch, for example needing to implement a whole new thing to make it pass) include the test as todo_wine. Do never ignore a test request because your implementation of an API fails it. As explained above: The point What nativce does is an extremely stupid way to handle these corner cases, my implementation if much smarter about it is never valid for Wine. I made the explicit note about disassembling (be it with IDA, w32dasm or getting an assembler listing of Microsoft dlls with some debugger), because for legal reasons, developers that have seen Microsoft source or object code are not allowed to commit code to Wine anymore. IIRC there is no consensus yet to what extent this rule applies, but (IIRC again) the usual interpretation is you may not contribute to the dll you disassembled. Regards, Michael Karcher
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Reece Dunn wrote: 2008/7/13 Nikolay Sivov [EMAIL PROTECTED]: What do you think about matrix comparison or in general float comparison implementation? What is the best way to implement this. We have two cases now: 1. GdipIsMatrixEqual which compares two matrices (with simple bitwise operation now) Is this the way it works on Windows? You have 4 basic cases: a. exactly equal; b. equal + epsilon for rounding/representation errors; c. equal - epsilon for rounding/representation errors; d. not equal. The code at the moment covers a and d (is there a test for d?), but what about b and c? These would be useful, because if the Windows version of GdipIsMatrixEqual *is* catering for error of a given epsilon, then you can use that function for validation. If not, you have tests that prove that Windows is using a simplistic comparison method. Exactly, so I plan to test this deeper on native. As I see now after some basic tests, most probably native call does a bitwise comparison cause the result is affected by a smallest matrix element change (e.g. 1.000f - 1.001f). But I'll test it more. Reece, do you have any suggestions to do some bounds test (I mean test is call affected by representation or round errors or not)? 2. GdipIsMatrixInvertible which contains a check for 'not above zero' determinant. It has been a while since I have done any matrix math. I'll assume that the above is the correct definition/check for invertible (makes sense because you have inv(a(ij)) = a(ij)/det(A), so can't have det(A) == 0). Now here, you have several 'classes' of matrices w.r.t. whether they are invertible or not: a. det(A) 0 b. det(A) == 0 c. det(A) 0 So does Windows match your assumption for the answer to these (a == yes; b, c == no). What do you mean here by (c = no)? Native allows negative det and I do so. I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that? Are you saying that GdipIsMatrixInvertible should be used for comparison of two matrices? If so, you can have two different matrices that are invertible, so it does not make sense. Where did I say that? It's weird. A good first step would be to print out the expected and returned values for the matrices, and keep the GdipIsMatrixEqual check. This will allow you to determine if the reason this is failing is due to rounding errors, or that they are completely different results. - Reece With last patch marked 'try3' http://www.winehq.org/pipermail/wine-patches/2008-July/057797.html test and crosstest work for me cause there aren't affected by representation errors using det == 16..
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Michael Karcher wrote: Am Sonntag, den 13.07.2008, 12:42 +0400 schrieb Nikolay Sivov: I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that? That might a good approach if we want to implement some new API and want to do it sensibly. That's the point where design questions are asked. But the Wine project works the other way round: Wine is bug-for-bug compatible with Microsoft Windows. This means we have to design the same way as Microsoft, whether we think this behaviour is idiotic or not. [Next paragraph is generally about Wine development. I do not imply that you are going to violate the rules stated here or already have sone so. Its just for your (or everybody who reads this mail in the archive) information] So: First you try out what native does. And I mean *try* *out*, not reverse engineer by disassembling. To proof that you have tried out what native does, you publish your tests as wine testcases. Then you implement wine in a way these testcases pass. For myself, I think it is acceptable to implement some API without comparing to native first, if you get an application to run by that, *but* to get this patch included, you better write an API test that shows how that application used the API you changed (or implemented) and verifies that your implementation not just happen to make the application run, but really returns the same result as native does. If you post a patch, always be prepared to be asked to test further cases. It greatly increases your chance to get your patch committed if you add these further cases (often, they show deficiencies in your patch then). Modify your patch to make these tests pass too, or (with a convincing explanation why this would be out-of-scope for your patch, for example needing to implement a whole new thing to make it pass) include the test as todo_wine. Do never ignore a test request because your implementation of an API fails it. As explained above: The point What nativce does is an extremely stupid way to handle these corner cases, my implementation if much smarter about it is never valid for Wine. I made the explicit note about disassembling (be it with IDA, w32dasm or getting an assembler listing of Microsoft dlls with some debugger), because for legal reasons, developers that have seen Microsoft source or object code are not allowed to commit code to Wine anymore. IIRC there is no consensus yet to what extent this rule applies, but (IIRC again) the usual interpretation is you may not contribute to the dll you disassembled. Regards, Michael Karcher All of this is absolutely clear. The only reason why my last tests fail was that I didn't check them on native thinking that a crossbuild is much complicated procedure that it is in fact. Of course I will not reverse any Windows binary to look at it cause it's a direct License Agreement violation. With this question I didn't try to bring some incompatibility with a 'better' implementation, not equivalent with native. Of course not. I've just asked the possible way to start with this problem of portable floating point comparison. If I'll found that native use some 'not bitwise' comparison for this calls I'll have to use some comparison method with tolerance value(s) and then try to get the same results as native provides. The question was 'what method is preferable in this case' that's all.
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Am Sonntag, den 13.07.2008, 13:51 +0400 schrieb Nikolay Sivov: Reece Dunn wrote: Is this the way it works on Windows? You have 4 basic cases: a. exactly equal; b. equal + epsilon for rounding/representation errors; c. equal - epsilon for rounding/representation errors; d. not equal. I don't see a difference between b and c. A matrix has four elements. Some might be slightly too big and others slightly too small. Would this make b or c? It's just one case: equal +/- epsilon. Exactly, so I plan to test this deeper on native. As I see now after some basic tests, most probably native call does a bitwise comparison cause the result is affected by a smallest matrix element change (e.g. 1.000f - 1.001f). But I'll test it more. 1+FLT_EPSILON is the value to use for the smallest matrix element change. But sour test already is a very strong indication that it really is strict equality test. FLT_EPSILON is in float.h Reece, do you have any suggestions to do some bounds test (I mean test is call affected by representation or round errors or not)? Another thing you could test is: Is the Matrix (1,FLT_EPSILON/2,0,1) equal to (1,0,0,1). A matrix like te former can easily be the result of multiplying a matrix by its inverse matrix (if represented as floating point numbers). One might expect that the product of a matrix and its inverse always is the identity matrix. 2. GdipIsMatrixInvertible which contains a check for 'not above zero' determinant. a. det(A) 0 b. det(A) == 0 c. det(A) 0 So does Windows match your assumption for the answer to these (a == yes; b, c == no). What do you mean here by (c = no)? Native allows negative det and I do so. He implied it form your not above zero quote. A hint how I would implement that test (if it turns out that a strict comparison to 0 is not the right result): Do not calculate the sum of a*d and -b*c, but compare these numbers in a sensible way. Regards, Michael Karcher
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Am Sonntag, den 13.07.2008, 14:09 +0400 schrieb Nikolay Sivov: Michael Karcher wrote: Am Sonntag, den 13.07.2008, 12:42 +0400 schrieb Nikolay Sivov: I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that? [ Deleted quotes about how to work on Wine ] All of this is absolutely clear. OK. Won't tell it to you again. With this question I didn't try to bring some incompatibility with a 'better' implementation, not equivalent with native. You have written that we should choose an appropriate method. We can not choose an appropriate method. Microsoft has chosen one. We have to find out which. And it might be different for GdipIsMatrixInvertible and GdipIsMatrixEqual. Regards, Michael Karcher
Re: [dplayx] New library dpwsockx, needed by dplayx
Hello Alexandre, this thread is about an include file specifying the interface between dplayx.dll and the DirectPlay service providers. As it is not in the Windows Platform SDK, James Hawkins explained that it may not go into include. This file is shared between dplayx and the service providers, currently two copies exist (if the patch that started the discussion gets applied), and if a modem provider gets written, three copies exist. What do you think would be the appropriate location of that file? Am Samstag, den 12.07.2008, 14:31 -0500 schrieb James Hawkins: If it's not in the SDK, it can't go into include. OK, you got a point. So, what about an uninstalled file in include/wine? Not all files from there get installed. Maybe. You'd have to ask Julliard. Regards, Michael Karcher
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
2008/7/12 Michael Karcher [EMAIL PROTECTED]: Am Samstag, den 12.07.2008, 16:55 -0500 schrieb James Hawkins: GDI+ uses floating point values for matrix elements so don't you think the result could be slightly different due different calculation algorithms? As they say: Never compare floating point numbers for equality. So I understand your point. Especially if unrepresentable values are involved. Agreed. There could also be issues depending on the compiler used (msvc vs gcc), different CPUs or instruction sets (e.g. using MMX/SSE/SSE2 to optimise the calculations). Nikolay: Please write a test whether the matrix 1.0/131072, 2.0/131072, 4.0/131072, -1/131072, 0, 0 is invertible. According to your criterion, it is *not* invertible, as the determinant will be 9.0/17179869184, which is way below 1e-5, but this matrix still *is* invertible. What happens on Windows? The identity matrix would also be a nice test case - for the other GDI and DirectX matrix operations as well. - Reece
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
2008/7/13 Nikolay Sivov [EMAIL PROTECTED]: What do you think about matrix comparison or in general float comparison implementation? What is the best way to implement this. We have two cases now: 1. GdipIsMatrixEqual which compares two matrices (with simple bitwise operation now) Is this the way it works on Windows? You have 4 basic cases: a. exactly equal; b. equal + epsilon for rounding/representation errors; c. equal - epsilon for rounding/representation errors; d. not equal. The code at the moment covers a and d (is there a test for d?), but what about b and c? These would be useful, because if the Windows version of GdipIsMatrixEqual *is* catering for error of a given epsilon, then you can use that function for validation. If not, you have tests that prove that Windows is using a simplistic comparison method. 2. GdipIsMatrixInvertible which contains a check for 'not above zero' determinant. It has been a while since I have done any matrix math. I'll assume that the above is the correct definition/check for invertible (makes sense because you have inv(a(ij)) = a(ij)/det(A), so can't have det(A) == 0). Now here, you have several 'classes' of matrices w.r.t. whether they are invertible or not: a. det(A) 0 b. det(A) == 0 c. det(A) 0 So does Windows match your assumption for the answer to these (a == yes; b, c == no). I think first of all we should choose an appropriate method to do so and only after that try to compare results with native. What do you think of that? Are you saying that GdipIsMatrixInvertible should be used for comparison of two matrices? If so, you can have two different matrices that are invertible, so it does not make sense. A good first step would be to print out the expected and returned values for the matrices, and keep the GdipIsMatrixEqual check. This will allow you to determine if the reason this is failing is due to rounding errors, or that they are completely different results. - Reece
Re: RFC: More tests for riched20 ITextServices
2008/7/4 Dan Hipschman [EMAIL PROTECTED]:
On Thu, Jul 03, 2008 at 05:32:32PM +1000, Austin Lund wrote:
I have run these with the native dll in wine and it works fine, but
would like someone to test them on windows platforms.
I couldn't get these to compile within a few minutes due to not being
familiar with what headers were needed, but I can comment on a few
things to get the ball rolling.
+#include config.h
+#include wine/port.h
These should not be included in tests.
I need these for the thiscall wrappers. But from commit 4904c807 the
non use of these seems to be strictly enforced. And I understand why.
But this makes portability of the test a bigger headache.
I managed to get the attached patch to compile with GCC. But the
added #defines must break portability.
Is there an easy way out of this?
From ef9eb766ebc11d555fb045222d1e71259d0a21b3 Mon Sep 17 00:00:00 2001
From: Austin Lund [EMAIL PROTECTED]
Date: Fri, 27 Jun 2008 22:40:51 +1000
Subject: [PATCH] richedit: Added conformance tests for txtsrv.c
---
dlls/riched20/tests/Makefile.in |5 +-
dlls/riched20/tests/txtsrv.c| 571 +++
2 files changed, 574 insertions(+), 2 deletions(-)
create mode 100644 dlls/riched20/tests/txtsrv.c
diff --git a/dlls/riched20/tests/Makefile.in b/dlls/riched20/tests/Makefile.in
index 0993609..a4db8f1 100644
--- a/dlls/riched20/tests/Makefile.in
+++ b/dlls/riched20/tests/Makefile.in
@@ -3,11 +3,12 @@ TOPOBJDIR = ../../..
SRCDIR= @srcdir@
VPATH = @srcdir@
TESTDLL = riched20.dll
-IMPORTS = ole32 user32 gdi32 kernel32
+IMPORTS = ole32 user32 gdi32 kernel32 uuid riched20
CTESTS = \
editor.c \
- richole.c
+ richole.c \
+ txtsrv.c
@MAKE_TEST_RULES@
diff --git a/dlls/riched20/tests/txtsrv.c b/dlls/riched20/tests/txtsrv.c
new file mode 100644
index 000..9cf788e
--- /dev/null
+++ b/dlls/riched20/tests/txtsrv.c
@@ -0,0 +1,571 @@
+/*
+ * Unit test suite for windowless rich edit controls
+ *
+ * Copyright 2008 Austin Lund [EMAIL PROTECTED]
+ * Copyright 2008 Maarten Lankhorst
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#define COBJMACROS
+
+#include stdio.h
+#include stdarg.h
+#include windef.h
+#include winbase.h
+#include shlwapi.h
+#include richedit.h
+#include initguid.h
+#include textserv.h
+#include wine/test.h
+
+/* Define to a macro to generate an assembly function directive */
+#define __ASM_FUNC(name) .type __ASM_NAME(name) ,@function
+
+/* Define to a macro to generate an assembly name from a C symbol */
+#define __ASM_NAME(name) name
+
+/* Macros to define assembler functions somewhat portably */
+
+#define __ASM_GLOBAL_FUNC(name,code) \
+ __asm__( .text\n\t \
+ .align 4\n\t \
+ .globl __ASM_NAME(#name) \n\t \
+ __ASM_FUNC(#name) \n \
+ __ASM_NAME(#name) :\n\t \
+ code \
+ \n\t.previous );
+
+
+//
+/* ITextHost implementation for conformance testing. */
+
+typedef struct ITextHostTestImpl {
+ITextHostVtbl *lpVtbl;
+LONG refCount;
+} ITextHostTestImpl;
+
+static ITextHostVtbl itestvtbl;
+
+static HRESULT WINAPI ITextHostImpl_QueryInterface(ITextHost *iface,
+ REFIID riid,
+ LPVOID *ppvObject) {
+ITextHostTestImpl *This = (ITextHostTestImpl *)iface;
+
+if (IsEqualIID(riid, IID_IUnknown) || IsEqualIID(riid, IID_ITextHost)) {
+*ppvObject = (LPVOID)This;
+ITextHost_AddRef((ITextHost *)(*ppvObject));
+return S_OK;
+}
+else
+return E_NOINTERFACE;
+}
+
+static ULONG WINAPI ITextHostImpl_AddRef(ITextHost *iface) {
+ITextHostTestImpl *This = (ITextHostTestImpl *)iface;
+ULONG refCount = InterlockedIncrement(This-refCount);
+return refCount;
+}
+
+static ULONG WINAPI ITextHostImpl_Release(ITextHost *iface) {
+ITextHostTestImpl *This = (ITextHostTestImpl *)iface;
+ULONG refCount = InterlockedDecrement(This-refCount);
+
+if (!refCount)
+{
+CoTaskMemFree(This);
+return 0;
+}
+else
+return refCount;
+}
+
+HDC WINAPI
Re: How do I write an exception filter?
Hello everyone, On 7/10/08, Juan Lang [EMAIL PROTECTED] wrote: snip Now that we've established you can't do this yourself, a hint on how you can help us: file a bug describing the problem, and produce as small a test case as you can that shows the problem in Wine. Ideally you can write a regression test that succeeds on Windows and fails on Wine. That should give the devs here a pretty strong hint about what needs to be done. Done, it's Bug #14465. It contains source code and binaries for a windows RPC client and server that allows to use a variety of RPC calls with different comm and fault status decoration of the RPC calls and client side diagnosis of what exceptions are legitimate and what are erroneous. I have also a attached a patch with the result of my work regarding this problem. The source code for this patch has been written before I started debugging the XP implementation of NdrClientCall2 and has been created by analysing the MIDL generated source code for my test project. I hope this all can help to fix this problem. If anyone needs help with my code or my test project, don't hesitate to contact me. Cheers, -- Stefan
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Michael Karcher wrote: Am Sonntag, den 13.07.2008, 13:51 +0400 schrieb Nikolay Sivov: Reece Dunn wrote: Is this the way it works on Windows? You have 4 basic cases: a. exactly equal; b. equal + epsilon for rounding/representation errors; c. equal - epsilon for rounding/representation errors; d. not equal. I don't see a difference between b and c. A matrix has four elements. Some might be slightly too big and others slightly too small. Would this make b or c? It's just one case: equal +/- epsilon. Exactly, so I plan to test this deeper on native. As I see now after some basic tests, most probably native call does a bitwise comparison cause the result is affected by a smallest matrix element change (e.g. 1.000f - 1.001f). But I'll test it more. 1+FLT_EPSILON is the value to use for the smallest matrix element change. But sour test already is a very strong indication that it really is strict equality test. FLT_EPSILON is in float.h This header is optional, isn't it? I've used FLT_EPSILON in call PlgBlt of gdi32, but it was replaced with 1e-5 on commit (it was fabs(det) FLT_EPSILON). So am I right that we can't use it on portability reason? Reece, do you have any suggestions to do some bounds test (I mean test is call affected by representation or round errors or not)? Another thing you could test is: Is the Matrix (1,FLT_EPSILON/2,0,1) equal to (1,0,0,1). A matrix like te former can easily be the result of multiplying a matrix by its inverse matrix (if represented as floating point numbers). One might expect that the product of a matrix and its inverse always is the identity matrix. I'll try that. 2. GdipIsMatrixInvertible which contains a check for 'not above zero' determinant. a. det(A) 0 b. det(A) == 0 c. det(A) 0 So does Windows match your assumption for the answer to these (a == yes; b, c == no). What do you mean here by (c = no)? Native allows negative det and I do so. He implied it form your not above zero quote. Yes, I meant absolute value of course. A hint how I would implement that test (if it turns out that a strict comparison to 0 is not the right result): Do not calculate the sum of a*d and -b*c, but compare these numbers in a sensible way. Here I something like FLT_EPSILON constant. So it's the same like above. Regards, Michael Karcher
RE: wined3d: add surface convertor from D3DFMT_X8R8G8B8 to D3DFMT_R5G6B5
Please allign the entries in the conversion table. It seems that the spacing
isn't properly alliged(although maybe my outlook messed it up). Otherwise it
looks ok to me
Also it is generally better to attach the patch as an extra file to the mail
instead of inlining it, since mail clients often mangle the lines, thus
breaking the patch
-Original Message-
From: [EMAIL PROTECTED] [mailto:wine-patches-
[EMAIL PROTECTED] On Behalf Of Victor
Sent: Saturday, July 12, 2008 9:54 PM
To: [EMAIL PROTECTED]
Subject: wined3d: add surface convertor from D3DFMT_X8R8G8B8 to
D3DFMT_R5G6B5
removes cannot convert FIXMEs in Ancient Evil game.
---
dlls/wined3d/surface_base.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/surface_base.c b/dlls/wined3d/surface_base.c
index 183cd2b..d74ec42 100644
--- a/dlls/wined3d/surface_base.c
+++ b/dlls/wined3d/surface_base.c
@@ -636,6 +636,23 @@ void convert_r32f_r16f(BYTE *src, BYTE *dst, DWORD
pitch_in, DWORD pitch_out, un
}
}
+inline WORD x8r8g8b8_to_x5r6g5(DWORD xrgb){
+return ((xrgb 0xFF) 3) | ((xrgb 0xFF00) 10) |
+ ((xrgb 0xFF) 19);
+}
+
+void convert_x8r8g8b8_x5r6g5(BYTE* src, BYTE* dst, DWORD pitch_in,
DWORD pitch_out, unsigned int w, unsigned int h){
+unsigned int x, y;
+DWORD* srcp;
+WORD* destp;
+for (y = 0; y h; y++, src+= pitch_in, dst += pitch_out){
+ srcp = (DWORD*)src;
+ destp = (WORD*)dst;
+ for (x = 0; x w; x++)
+ destp[x] = x8r8g8b8_to_x5r6g5(srcp[x]);
+}
+}
+
struct d3dfmt_convertor_desc {
WINED3DFORMAT from, to;
void (*convert)(BYTE *src, BYTE *dst, DWORD pitch_in, DWORD
pitch_out, unsigned int w, unsigned int h); @@ -643,6 +660,7 @@ struct
d3dfmt_convertor_desc {
struct d3dfmt_convertor_desc convertors[] = {
{WINED3DFMT_R32F, WINED3DFMT_R16F,convert_r32f_r16f},
+{WINED3DFMT_X8R8G8B8,WINED3DFMT_R5G6B5,
convert_x8r8g8b8_x5r6g5}
};
static inline struct d3dfmt_convertor_desc
*find_convertor(WINED3DFORMAT from, WINED3DFORMAT to) {
--
1.5.5
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
Am Sonntag, den 13.07.2008, 18:43 +0400 schrieb Nikolay Sivov:
Exactly, so I plan to test this deeper on native. As I see now after
some basic tests, most probably native call does a bitwise comparison
cause the result is affected by a smallest matrix element change (e.g.
1.000f - 1.001f). But I'll test it more.
1+FLT_EPSILON is the value to use for the smallest matrix element
change. But sour test already is a very strong indication that it
really is strict equality test. FLT_EPSILON is in float.h
This header is optional, isn't it? I've used FLT_EPSILON in call PlgBlt
of gdi32, but it was replaced with 1e-5 on commit (it was fabs(det)
FLT_EPSILON).
To the best of my knowledge and the web pages I found on this topic,
float.h is standard ANSI C. There should be no need to avoid this
header.
On the other hand, I don't understand why you use 1e-5 or FLT_EPSILON at
that point at all. If I am not totally confused, you calculate some kind
of determinant from the nRect entries, which were directly before
initialized from the nXSrc, nYSrc, nWidth, nHeight variables, which are
integers, so rect contains integer values. The formula for det only
contains subtraction and multiplication. How do you expect that the
outcome of this calculation is non-integral?
A hint how I would
implement that test (if it turns out that a strict comparison to 0 is
not the right result): Do not calculate the sum of a*d and -b*c, but
compare these numbers in a sensible way.
Here I something like FLT_EPSILON constant. So it's the same like above.
Be aware that 2+FLT_EPSILON stored into a float still is 2! You do not
want to write fabs(a*d-b*c) FLT_EPSILON.
Try this:
#include float.h
#include stdio.h
float det(float a, float b, float c, float d)
{
return fabs(a*b-c*d);
}
int main(void)
{
printf(%g %g\n,det(100./3,120./7,12000./21,1), FLT_EPSILON);
}
compiled with no optimization (to avoid the compiler pre-calculating the
determinant with higher precision). You will see that the difference is
*much* bigger than FLT_EPSILON, yet the matrix was intended to be
singular (and were singular if there were no rounding errors on the
thirds). You should understand the cause of this before you try to write
a robust float comparison function.
Regards,
Michael Karcher
Re: [dplayx] New library dpwsockx, needed by dplayx
Michael Karcher [EMAIL PROTECTED] writes: Hello Alexandre, this thread is about an include file specifying the interface between dplayx.dll and the DirectPlay service providers. As it is not in the Windows Platform SDK, James Hawkins explained that it may not go into include. This file is shared between dplayx and the service providers, currently two copies exist (if the patch that started the discussion gets applied), and if a modem provider gets written, three copies exist. What do you think would be the appropriate location of that file? If it's part of some DirectPlay SDK then it can go in include, otherwise it will probably have to go in include/wine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [dplayx] New library dpwsockx, needed by dplayx
On 7/13/08, Alexandre Julliard [EMAIL PROTECTED] wrote: Michael Karcher [EMAIL PROTECTED] writes: Hello Alexandre, this thread is about an include file specifying the interface between dplayx.dll and the DirectPlay service providers. As it is not in the Windows Platform SDK, James Hawkins explained that it may not go into include. This file is shared between dplayx and the service providers, currently two copies exist (if the patch that started the discussion gets applied), and if a modem provider gets written, three copies exist. What do you think would be the appropriate location of that file? If it's part of some DirectPlay SDK then it can go in include, otherwise it will probably have to go in include/wine. It's not part of any official DirectPlay SDK, but I suppose it's part of the documentation Microsoft provides if you ask them for the interfaces needed to develop a new service provider. However I can't confirm this yet (they agreed to provide me the documentation, but I've got no news from them since then), so include/wine is probably the place then. What would be the exact path? include/wine/dplaysp.h? include/wine/dplay/dplaysp.h? Cheers Ismael
please disregard my patch wined3d: add surface convertor from D3DFMT_X8R8G8B8 to D3DFMT_R5G6B5
Hello. I ask to disregard patch wined3d: add surface convertor from D3DFMT_X8R8G8B8 to D3DFMT_R5G6B5 (d15c66beeb5ab7130161278d0ee86ee79aed.diff) I've sent yesterday. There are minor errors in masks used within x8r8g8b8_to_x5r6g5 that might cause minor graphical artefacts on textures with this conversion. I've written better (more flexible) converter function which will be submitted to wine-patches soon. -- With best regards, Victor Eremin ([EMAIL PROTECTED]) signature.asc Description: This is a digitally signed message part.
Allow running conformance tests in parallel
The attached patch lets you run Wine's conformance tests in parallel.
On my relatively fast dual core machine (e7200):
make -k test takes 3 minutes 55 seconds
make -k -j2 test takes 2 minutes 15 seconds
make -k -j4 test takes 1 minute 45 seconds
make -k -j10 test takes 1 minute 27 seconds
About the same number of tests fail regardless of -j value.
How it works:
this patch adds a new function, winetest_exclusive(),
that waits until it can acquire an exclusive lock.
It should be called near the top of the START_TEST body
for any test that needs exclusive access to the
system. (In tests that exec themselves, the call has to
be placed carefully to avoid having the child call it.)
I did this for all tests that call CreateWindow, and
a few more that seemed like they might need it.
The list of tests marked exclusive is somewhat rough;
probably a few tests should be added or removed,
but it's pretty good for a first cut.
I've been wanting to do this for ages. Turned out to be easier than I'd feared.
diff --git a/dlls/comctl32/tests/comboex.c b/dlls/comctl32/tests/comboex.c
index eca7ca4..7fe0874 100644
--- a/dlls/comctl32/tests/comboex.c
+++ b/dlls/comctl32/tests/comboex.c
@@ -339,6 +339,8 @@ static void cleanup(void)
START_TEST(comboex)
{
+winetest_exclusive();
+
if (!init())
return;
diff --git a/dlls/comctl32/tests/datetime.c b/dlls/comctl32/tests/datetime.c
index b194cc1..5bff228 100644
--- a/dlls/comctl32/tests/datetime.c
+++ b/dlls/comctl32/tests/datetime.c
@@ -579,6 +579,8 @@ START_TEST(datetime)
BOOL (WINAPI *pInitCommonControlsEx)(const INITCOMMONCONTROLSEX*);
INITCOMMONCONTROLSEX iccex;
+winetest_exclusive();
+
hComctl32 = GetModuleHandleA(comctl32.dll);
pInitCommonControlsEx = (void*)GetProcAddress(hComctl32, InitCommonControlsEx);
if (!pInitCommonControlsEx)
diff --git a/dlls/comctl32/tests/header.c b/dlls/comctl32/tests/header.c
index a3778cf..c62dca2 100644
--- a/dlls/comctl32/tests/header.c
+++ b/dlls/comctl32/tests/header.c
@@ -1524,6 +1524,8 @@ START_TEST(header)
{
HWND parent_hwnd;
+winetest_exclusive();
+
if (!init())
return;
diff --git a/dlls/comctl32/tests/imagelist.c b/dlls/comctl32/tests/imagelist.c
index 0d1770b..76600ec 100644
--- a/dlls/comctl32/tests/imagelist.c
+++ b/dlls/comctl32/tests/imagelist.c
@@ -976,6 +976,9 @@ static void test_imagelist_storage(void)
START_TEST(imagelist)
{
HMODULE hComCtl32 = GetModuleHandle(comctl32.dll);
+
+winetest_exclusive();
+
pImageList_DrawIndirect = (void*)GetProcAddress(hComCtl32, ImageList_DrawIndirect);
pImageList_SetImageCount = (void*)GetProcAddress(hComCtl32, ImageList_SetImageCount);
diff --git a/dlls/comctl32/tests/listview.c b/dlls/comctl32/tests/listview.c
index 4f8b32d..8069835 100644
--- a/dlls/comctl32/tests/listview.c
+++ b/dlls/comctl32/tests/listview.c
@@ -1216,6 +1216,8 @@ START_TEST(listview)
HMODULE hComctl32;
BOOL (WINAPI *pInitCommonControlsEx)(const INITCOMMONCONTROLSEX*);
+winetest_exclusive();
+
hComctl32 = GetModuleHandleA(comctl32.dll);
pInitCommonControlsEx = (void*)GetProcAddress(hComctl32, InitCommonControlsEx);
if (pInitCommonControlsEx)
diff --git a/dlls/comctl32/tests/monthcal.c b/dlls/comctl32/tests/monthcal.c
index cd9592d..bd167f2 100644
--- a/dlls/comctl32/tests/monthcal.c
+++ b/dlls/comctl32/tests/monthcal.c
@@ -1114,6 +1114,8 @@ START_TEST(monthcal)
INITCOMMONCONTROLSEX iccex;
HWND hwnd, parent_wnd;
+winetest_exclusive();
+
hComctl32 = GetModuleHandleA(comctl32.dll);
pInitCommonControlsEx = (void*)GetProcAddress(hComctl32, InitCommonControlsEx);
if (!pInitCommonControlsEx)
diff --git a/dlls/comctl32/tests/msg.c b/dlls/comctl32/tests/msg.c
index 2129f22..b1fe203 100644
--- a/dlls/comctl32/tests/msg.c
+++ b/dlls/comctl32/tests/msg.c
@@ -248,4 +248,5 @@ void init_msg_sequences(struct msg_sequence **seq, int n)
START_TEST(msg)
{
+winetest_exclusive();
}
diff --git a/dlls/comctl32/tests/progress.c b/dlls/comctl32/tests/progress.c
index 10bbbef..bf9a455 100644
--- a/dlls/comctl32/tests/progress.c
+++ b/dlls/comctl32/tests/progress.c
@@ -222,6 +222,8 @@ static void test_redraw(void)
START_TEST(progress)
{
+winetest_exclusive();
+
init();
test_redraw();
diff --git a/dlls/comctl32/tests/propsheet.c b/dlls/comctl32/tests/propsheet.c
index 45c8d97..1f7b612 100644
--- a/dlls/comctl32/tests/propsheet.c
+++ b/dlls/comctl32/tests/propsheet.c
@@ -201,6 +201,8 @@ static void test_disableowner(void)
START_TEST(propsheet)
{
+winetest_exclusive();
+
test_title();
test_nopage();
test_disableowner();
diff --git a/dlls/comctl32/tests/rebar.c b/dlls/comctl32/tests/rebar.c
index e5bea38..fdb18d3 100644
--- a/dlls/comctl32/tests/rebar.c
+++ b/dlls/comctl32/tests/rebar.c
@@ -835,6 +835,8 @@ START_TEST(rebar)
MSG msg;
RECT rc;
+winetest_exclusive();
+
/* LoadLibrary is needed. This file has
Re: [WineHQ][WWN] WWN 349
Zachary Goldberg wrote: ... but did not spell check :) Granted, the movie quote is pretty funny, even if isn't spelled right. Ivan
Illegal attachment in bug 14461
Bugzilla admin(s) please remove the illegal attachment from the http://bugs.winehq.org/show_bug.cgi?id=14461 Vitaliy.
Re: Allow running conformance tests in parallel
Dan Kegel wrote: About the same number of tests fail regardless of -j value. How it works: this patch adds a new function, winetest_exclusive(), that waits until it can acquire an exclusive lock. It should be called near the top of the START_TEST body for any test that needs exclusive access to the system. (In tests that exec themselves, the call has to be placed carefully to avoid having the child call it.) I did this for all tests that call CreateWindow, and a few more that seemed like they might need it. The list of tests marked exclusive is somewhat rough; probably a few tests should be added or removed, but it's pretty good for a first cut. About -- shouldn't it be exactly? Unless tests are sometimes supposed fail inconsistently, then you probably need it on every one that behaves differently. Thanks, Scott Ritchie
