RE: user32: Problem using SetClassLongW to subclass built-in control (Edit)
Hi Everyone, It turns out my previous patch was not right to solve the problem. After writing a win32 application for debuging the impact of SetClassLongW, I found out that something is abnormal in windows. After a built-in class (which has procA and procW) is subclassed by SetClassLong(Ptr)W(hWnd, GCL_WNDPROC, newProcW); If you create a window of the same built-in class (such as Edit) using CreateWindow(Ex)A, the created window got it's wnd.procA = class.newProcW. The created window is Ansi. That is right, the newProcW is going to receive Ansi message - [ABNORMAL]. I have captured the debug screen, here is the screenshot http://www.njstar.com/devimg/SetClassLongW-debug.png Where in Wine, created window is Unicode, with wnd.procW = class.newProcW. newProcW will only receive Unicode message. That is the difference between Window and Wine regarding to subclass built-in control. This observation explains exactly what I have seen in my App. With this knowledge it's now easy to create the patch. _ Windows Live Messenger treats you to 30 free emoticons - Bees, cows, tigers and more! http://livelife.ninemsn.com.au/article.aspx?id=567534
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
Michael Karcher wrote: > Am Samstag, den 12.07.2008, 16:55 -0500 schrieb James Hawkins: > > -GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0, > >>> Of course there's only one value of inverted matrix. >>> > Which is not representable as a finite binary fraction. > > >>> 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. > > >> If you write and test the results in Windows, you won't have to guess >> what the results will be. >> > Right. Testing against Windows is the only method of verifying whether > Wine does the right things, but floating point arithmetic, which is > inherently prone to rounding errors, should IMHO be accounted for by > allowing slight variances. > > >> No I don't think the results will be >> slightly different. Higher-precision arithmetic doesn't mean more >> slop. >> > What do you mean with higher-precision arithmetic? Floating point > arithmetic *always* means slop, as soon as numbers that can't be written > as finite binary fractions are involved. In this concrete case, I > suspect you are right. There is just one obvious algorithm[1] to invert > a 2x2 Matrix, which is so simple that it cannot be stated in numerically > non-equivalent ways (remember, a+(b+c) is not necessarily equal to (a > +b)+c)), so I would expect the results to be really identical on windows > if the input numbers are small integers. Still, the fractions with nine > in the denominator make me worry. Couldn't we use a matrix with a > determinant of 8 or 16 instead of nine? This would make nice floats you > can definitely compare for equality. > > As a side note: I don't like the implementation of m_equalf, as it > checks for absolute deviation instead of relative deviation. The values > used have the same order of magnitude as 1, so it does not matter for > this test. But: This very criterion is also used in in > GdipIsMatrixInvertible, where I consider it highly questionable, as long > as it is not backed by API tests. > You're absolutely right. m_equalf id used as a temporary solution just to make the test pass with this deviation, which is acceptable in this particular initial data, to show that GdipInvertMatrix works in the main. But check in GdipIsMatrixInvertible should be replaced, I'm fully agreed here. I'll try to choose appropriate method to do so (using Windows test results too of course). > 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? > On Windows it shows the following: 0., 32768.000, 65536.000, -16384.000, 0., 0. So native criterion differs. > Regards, > Michael Karcher > > [1] Which I found (as expected) when looking at dlls/gdiplus/matrix.c >
RE: CUDA wrapper
I have no idea regarding that crash, but from the rest of the log it seems that the app is initializing a d3d device; This means you'll probably have to implement cuda<->d3d communication From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Saturday, July 12, 2008 7:52 PM To: wine-devel@winehq.org Subject: Re: CUDA wrapper OK, I've fixed a few mistakes in the .spec file and we are getting further, but I tried debugging the output but I am not sure what it all means. [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-dbg>n 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 . But what exactly that means I am not sure, I mean I don't know which function it is saying is missing or messed up. Also from the documentation and from the nvidia forums it seems that both libraries are exactly the same, and it is said that there is no difference in writing a program for Linux vs. Windows, but I assume that is minus the direct3d functions, which I know the folding at home program doesn't use. On Thu, Jul 10, 2008 at 12:01 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Wine links against cudart.dll.so from /usr/lib/ or wherever it is. You don't have to put it in C:\windows\... . You can put a TRACE or ERR into the cudaMalloc(or whatever) function implementation in your code to write a message to check if the functions are properly called. I suspect they are, and that libcudart.so writes those errors. This would then mean that the Windows and Linux cuda libraries are different, and some features are missing in the Linux version. If that is true, the only thing you can do is to contact Nvidia and ask them for help From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Wednesday, July 09, 2008 7:23 PM To: Juan Lang; wine-devel@winehq.org Subject: Re: CUDA wrapper Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented. Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented. I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files. http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec Does wine need to somehow be made aware of the presence of the cudart.dll.so file? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?
Re: CUDA wrapper
OK, I've fixed a few mistakes in the .spec file and we are getting further, but I tried debugging the output but I am not sure what it all means. [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-dbg>n 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 . But what exactly that means I am not sure, I mean I don't know which function it is saying is missing or messed up. Also from the documentation and from the nvidia forums it seems that both libraries are exactly the same, and it is said that there is no difference in writing a program for Linux vs. Windows, but I assume that is minus the direct3d functions, which I know the folding at home program doesn't use. On Thu, Jul 10, 2008 at 12:01 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Wine links against cudart.dll.so from /usr/lib/ or wherever it is. You > don't have to put it in C:\windows\... . > > > > You can put a TRACE or ERR into the cudaMalloc(or whatever) function > implementation in your code to write a message to check if the functions are > properly called. I suspect they are, and that libcudart.so writes those > errors. This would then mean that the Windows and Linux cuda libraries are > different, and some features are missing in the Linux version. If that is > true, the only thing you can do is to contact Nvidia and ask them for help > > > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt > *Sent:* Wednesday, July 09, 2008 7:23 PM > *To:* Juan Lang; wine-devel@winehq.org > *Subject:* Re: CUDA wrapper > > > > Well at least it compiled, but it isn't working. We are still getting the > message that the function isn't implemented. > > > Initializing Nvidia gpu library > cudaMalloc CUDAStream::Allocate failed feature is not yet implemented > > > Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, > Query and Synchronize were implemented. > I thought maybe it was because in the spec file I had the cudaStream's as > pointers (ptr) so I switched them to long but ti didn't make a difference. > Originally the argument was "stream" but I can't get any argument but ptr > and long to pass the winegcc for spec files. > > http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec > > Does wine need to somehow be made aware of the presence of the > cudart.dll.so file? We tried putting it in both the system32 and the lib > folder but it seems also that maybe WINE needs to be made aware of it? >
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
On Sat, Jul 12, 2008 at 4:16 PM, Dan Kegel <[EMAIL PROTECTED]> wrote: > Floating point equality comparisons need an error tolerance. > See e.g. > > http://teaching.idallen.com/cst8110/97s/floating_point.html > http://docs.hp.com/en/B3906-90006/ch03s05.html > http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems > http://search.cpan.org/~dagolden/Test-Number-Delta-1.03/lib/Test/Number/Delta.pm Someone goaded me into finding better links (thanks...), so: http://code.google.com/p/googletest/ is a test framework that gets it right, I think. After peeking at its source, I recalled the magic buzzword: ULP. Searching for floating point comparison ULP finds better links than I found before, e.g. http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm - Dan
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
Am Sonntag, den 13.07.2008, 01:14 +0200 schrieb Michael Karcher: > Am Samstag, den 12.07.2008, 23:56 +0100 schrieb Reece Dunn: > If you are brave enough to really find out what happens (might be > different depending on Windows version, instruction sets available and > things like that), also try the identity matrix scaled by 2^66 and > 2^(-66). The square of 2^66 overflows a 32 bit floating point number. Sorry, forgot denormals. The square of 2^(-66) *is* exactly represenatable as float! Use 2^(-80) to be sure that the square underflows. Regards, Michael Karcher
re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
James wrote: > > GDI+ uses floating point values for matrix elements so >> don't you think the result could be slightly different... > > No I don't think the results will be slightly different. > Higher-precision arithmetic doesn't mean more slop. Floating point equality comparisons need an error tolerance. See e.g. http://teaching.idallen.com/cst8110/97s/floating_point.html http://docs.hp.com/en/B3906-90006/ch03s05.html http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems http://search.cpan.org/~dagolden/Test-Number-Delta-1.03/lib/Test/Number/Delta.pm And testing matrix math routines is even trickier, it helps to have a really good math background there...
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
Am Samstag, den 12.07.2008, 23:56 +0100 schrieb Reece Dunn: > > 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. Yes. Excellent idea! Determinant is one. Division by one is exact. This should definitely yield exact results. Now, add the identity matrix scaled by a big power of two (like 2^60) and divided by that power of two. Powers of two are as good as a simple one if you are on floating point numbers. If you are brave enough to really find out what happens (might be different depending on Windows version, instruction sets available and things like that), also try the identity matrix scaled by 2^66 and 2^(-66). The square of 2^66 overflows a 32 bit floating point number. So, if you calculate within x87 coprocessor registers, you can invert the matrix. If you store to double variables too. If you store to float variables or calc via SSE or 3Dnow! (overkill for a matrix inversion, I know), matrix inversion probably fails, if no tricks are used. Regards, Michael Karcher
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
Am Samstag, den 12.07.2008, 16:55 -0500 schrieb James Hawkins: > >>> -GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0, > > Of course there's only one value of inverted matrix. Which is not representable as a finite binary fraction. > > 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. > If you write and test the results in Windows, you won't have to guess > what the results will be. Right. Testing against Windows is the only method of verifying whether Wine does the right things, but floating point arithmetic, which is inherently prone to rounding errors, should IMHO be accounted for by allowing slight variances. > No I don't think the results will be > slightly different. Higher-precision arithmetic doesn't mean more > slop. What do you mean with higher-precision arithmetic? Floating point arithmetic *always* means slop, as soon as numbers that can't be written as finite binary fractions are involved. In this concrete case, I suspect you are right. There is just one obvious algorithm[1] to invert a 2x2 Matrix, which is so simple that it cannot be stated in numerically non-equivalent ways (remember, a+(b+c) is not necessarily equal to (a +b)+c)), so I would expect the results to be really identical on windows if the input numbers are small integers. Still, the fractions with nine in the denominator make me worry. Couldn't we use a matrix with a determinant of 8 or 16 instead of nine? This would make nice floats you can definitely compare for equality. As a side note: I don't like the implementation of m_equalf, as it checks for absolute deviation instead of relative deviation. The values used have the same order of magnitude as 1, so it does not matter for this test. But: This very criterion is also used in in GdipIsMatrixInvertible, where I consider it highly questionable, as long as it is not backed by API tests. 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? Regards, Michael Karcher [1] Which I found (as expected) when looking at dlls/gdiplus/matrix.c
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
James Hawkins wrote:
> On Sat, Jul 12, 2008 at 4:35 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
>
>> James Hawkins wrote:
>>
>>> On Sat, Jul 12, 2008 at 4:12 PM, Nikolay Sivov <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>
Changelog:
- Make GdipInvertMatrix test pass on native
---
dlls/gdiplus/tests/matrix.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/dlls/gdiplus/tests/matrix.c b/dlls/gdiplus/tests/matrix.c
index 16c1517..daf61ea 100644
--- a/dlls/gdiplus/tests/matrix.c
+++ b/dlls/gdiplus/tests/matrix.c
@@ -27,6 +27,19 @@
#define expect(expected, got) ok(got == expected, "Expected %.8x, got
%.8x\n", expected, got)
+/* compare matrix data with some tolerance */
+BOOL m_equalf(REAL *m1, REAL *m2)
+{
+BOOL ret = TRUE;
+INT i;
+
+for(i = 0; i < 6; i++){
+ret = ret && (fabsf(m1[i] - m2[i]) < 1e-5);
+}
+
+return ret;
+}
+
static void test_constructor_destructor(void)
{
GpStatus status;
@@ -119,12 +132,12 @@ static void test_isinvertible(void)
GdipDeleteMatrix(matrix);
}
+static REAL minverted[] = {1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0,
-1.0};
static void test_invert(void)
{
GpStatus status;
GpMatrix *matrix = NULL;
-GpMatrix *inverted = NULL;
-BOOL equal;
+REAL mdata[6];
/* NULL */
status = GdipInvertMatrix(NULL);
@@ -141,11 +154,9 @@ static void test_invert(void)
status = GdipInvertMatrix(matrix);
expect(Ok, status);
-GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0,
&inverted);
-GdipIsMatrixEqual(matrix, inverted, &equal);
-expect(TRUE, equal);
+GdipGetMatrixElements(matrix, mdata);
+expect(TRUE, m_equalf(mdata, minverted));
>>> Why are you creating a new function that allows tolerance when you
>>> control the matrix you're comparing it to? Allowing slop is
>>> acceptable in some circumstances, but not in this case, when there is
>>> one exact value (or matrix of values) returned.
>>>
>> Of course there's only one value of inverted matrix. GDI+ uses floating
>> point values for matrix elements so don't you think the result could be
>> slightly different due different calculation algorithms?
>>
>>
>
> If you write and test the results in Windows, you won't have to guess
> what the results will be. No I don't think the results will be
> slightly different. Higher-precision arithmetic doesn't mean more
> slop.
>
Higher then what? Bitwise comparison of floating point values is useless
in most cases. The constant for inverted matrix provided in test is
exact product of invert operation. Such difference is acceptable here.
The tolerance could be decreased to 1e-7 I think but I don't see any
reason for that.
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
On Sat, Jul 12, 2008 at 4:35 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> James Hawkins wrote:
>>
>> On Sat, Jul 12, 2008 at 4:12 PM, Nikolay Sivov <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> Changelog:
>>> - Make GdipInvertMatrix test pass on native
>>>
>>> ---
>>> dlls/gdiplus/tests/matrix.c | 23 +--
>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/dlls/gdiplus/tests/matrix.c b/dlls/gdiplus/tests/matrix.c
>>> index 16c1517..daf61ea 100644
>>> --- a/dlls/gdiplus/tests/matrix.c
>>> +++ b/dlls/gdiplus/tests/matrix.c
>>> @@ -27,6 +27,19 @@
>>>
>>> #define expect(expected, got) ok(got == expected, "Expected %.8x, got
>>> %.8x\n", expected, got)
>>>
>>> +/* compare matrix data with some tolerance */
>>> +BOOL m_equalf(REAL *m1, REAL *m2)
>>> +{
>>> +BOOL ret = TRUE;
>>> +INT i;
>>> +
>>> +for(i = 0; i < 6; i++){
>>> +ret = ret && (fabsf(m1[i] - m2[i]) < 1e-5);
>>> +}
>>> +
>>> +return ret;
>>> +}
>>> +
>>> static void test_constructor_destructor(void)
>>> {
>>>GpStatus status;
>>> @@ -119,12 +132,12 @@ static void test_isinvertible(void)
>>>GdipDeleteMatrix(matrix);
>>> }
>>>
>>> +static REAL minverted[] = {1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0,
>>> -1.0};
>>> static void test_invert(void)
>>> {
>>>GpStatus status;
>>>GpMatrix *matrix = NULL;
>>> -GpMatrix *inverted = NULL;
>>> -BOOL equal;
>>> +REAL mdata[6];
>>>
>>>/* NULL */
>>>status = GdipInvertMatrix(NULL);
>>> @@ -141,11 +154,9 @@ static void test_invert(void)
>>>status = GdipInvertMatrix(matrix);
>>>expect(Ok, status);
>>>
>>> -GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0,
>>> &inverted);
>>> -GdipIsMatrixEqual(matrix, inverted, &equal);
>>> -expect(TRUE, equal);
>>> +GdipGetMatrixElements(matrix, mdata);
>>> +expect(TRUE, m_equalf(mdata, minverted));
>>>
>>>
>>
>> Why are you creating a new function that allows tolerance when you
>> control the matrix you're comparing it to? Allowing slop is
>> acceptable in some circumstances, but not in this case, when there is
>> one exact value (or matrix of values) returned.
>
> Of course there's only one value of inverted matrix. GDI+ uses floating
> point values for matrix elements so don't you think the result could be
> slightly different due different calculation algorithms?
>
If you write and test the results in Windows, you won't have to guess
what the results will be. No I don't think the results will be
slightly different. Higher-precision arithmetic doesn't mean more
slop.
--
James Hawkins
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
James Hawkins wrote:
> On Sat, Jul 12, 2008 at 4:12 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
>
>> Changelog:
>>- Make GdipInvertMatrix test pass on native
>>
>> ---
>> dlls/gdiplus/tests/matrix.c | 23 +--
>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/dlls/gdiplus/tests/matrix.c b/dlls/gdiplus/tests/matrix.c
>> index 16c1517..daf61ea 100644
>> --- a/dlls/gdiplus/tests/matrix.c
>> +++ b/dlls/gdiplus/tests/matrix.c
>> @@ -27,6 +27,19 @@
>>
>> #define expect(expected, got) ok(got == expected, "Expected %.8x, got
>> %.8x\n", expected, got)
>>
>> +/* compare matrix data with some tolerance */
>> +BOOL m_equalf(REAL *m1, REAL *m2)
>> +{
>> +BOOL ret = TRUE;
>> +INT i;
>> +
>> +for(i = 0; i < 6; i++){
>> +ret = ret && (fabsf(m1[i] - m2[i]) < 1e-5);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> static void test_constructor_destructor(void)
>> {
>> GpStatus status;
>> @@ -119,12 +132,12 @@ static void test_isinvertible(void)
>> GdipDeleteMatrix(matrix);
>> }
>>
>> +static REAL minverted[] = {1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0};
>> static void test_invert(void)
>> {
>> GpStatus status;
>> GpMatrix *matrix = NULL;
>> -GpMatrix *inverted = NULL;
>> -BOOL equal;
>> +REAL mdata[6];
>>
>> /* NULL */
>> status = GdipInvertMatrix(NULL);
>> @@ -141,11 +154,9 @@ static void test_invert(void)
>> status = GdipInvertMatrix(matrix);
>> expect(Ok, status);
>>
>> -GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0,
>> &inverted);
>> -GdipIsMatrixEqual(matrix, inverted, &equal);
>> -expect(TRUE, equal);
>> +GdipGetMatrixElements(matrix, mdata);
>> +expect(TRUE, m_equalf(mdata, minverted));
>>
>>
>
> Why are you creating a new function that allows tolerance when you
> control the matrix you're comparing it to? Allowing slop is
> acceptable in some circumstances, but not in this case, when there is
> one exact value (or matrix of values) returned.
Of course there's only one value of inverted matrix. GDI+ uses floating
point values for matrix elements so don't you think the result could be
slightly different due different calculation algorithms?
Re: [3/3] gdiplus: Make GdipInvertMatrix test pass on native
On Sat, Jul 12, 2008 at 4:12 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> Changelog:
>- Make GdipInvertMatrix test pass on native
>
> ---
> dlls/gdiplus/tests/matrix.c | 23 +--
> 1 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/dlls/gdiplus/tests/matrix.c b/dlls/gdiplus/tests/matrix.c
> index 16c1517..daf61ea 100644
> --- a/dlls/gdiplus/tests/matrix.c
> +++ b/dlls/gdiplus/tests/matrix.c
> @@ -27,6 +27,19 @@
>
> #define expect(expected, got) ok(got == expected, "Expected %.8x, got
> %.8x\n", expected, got)
>
> +/* compare matrix data with some tolerance */
> +BOOL m_equalf(REAL *m1, REAL *m2)
> +{
> +BOOL ret = TRUE;
> +INT i;
> +
> +for(i = 0; i < 6; i++){
> +ret = ret && (fabsf(m1[i] - m2[i]) < 1e-5);
> +}
> +
> +return ret;
> +}
> +
> static void test_constructor_destructor(void)
> {
> GpStatus status;
> @@ -119,12 +132,12 @@ static void test_isinvertible(void)
> GdipDeleteMatrix(matrix);
> }
>
> +static REAL minverted[] = {1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0};
> static void test_invert(void)
> {
> GpStatus status;
> GpMatrix *matrix = NULL;
> -GpMatrix *inverted = NULL;
> -BOOL equal;
> +REAL mdata[6];
>
> /* NULL */
> status = GdipInvertMatrix(NULL);
> @@ -141,11 +154,9 @@ static void test_invert(void)
> status = GdipInvertMatrix(matrix);
> expect(Ok, status);
>
> -GdipCreateMatrix2(1.0/9.0, 2.0/9.0, 4.0/9.0, -1.0/9.0, -2.0, -1.0,
> &inverted);
> -GdipIsMatrixEqual(matrix, inverted, &equal);
> -expect(TRUE, equal);
> +GdipGetMatrixElements(matrix, mdata);
> +expect(TRUE, m_equalf(mdata, minverted));
>
Why are you creating a new function that allows tolerance when you
control the matrix you're comparing it to? Allowing slop is
acceptable in some circumstances, but not in this case, when there is
one exact value (or matrix of values) returned.
--
James Hawkins
Re: [2/3] gdiplus: Fix test for PathIterator + make it pass on native and Wine (try2)
On Sat, Jul 12, 2008 at 4:11 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> Changelog:
>- Fix test for PathIterator + make it pass on native and Wine
> ---
> dlls/gdiplus/pathiterator.c |3 ++-
> dlls/gdiplus/tests/pathiterator.c |5 +++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
> index 55b0782..3d3b1dc 100644
> --- a/dlls/gdiplus/pathiterator.c
> +++ b/dlls/gdiplus/pathiterator.c
> @@ -140,7 +140,8 @@ GpStatus WINGDIPAPI
> GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
> /* first call could start with second point as all subsequent, cause
>path couldn't contain only one */
> for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
> -if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
> +if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
> + (i == iterator->pathdata.Count - 1)){
> *startIndex = iterator->marker_pos;
> if(iterator->marker_pos > 0) (*startIndex)++;
> *endIndex = iterator->marker_pos = i;
> diff --git a/dlls/gdiplus/tests/pathiterator.c
> b/dlls/gdiplus/tests/pathiterator.c
> index 071c1d5..90725dc 100644
> --- a/dlls/gdiplus/tests/pathiterator.c
> +++ b/dlls/gdiplus/tests/pathiterator.c
> @@ -95,7 +95,8 @@ static void test_nextmarker(void)
> GpPath *path;
> GpPathIterator *iter;
> GpStatus stat;
> -INT start, end, result;
> +INT start, end;
> +INT result = (INT)0xdeadbeef;
>
> /* NULL args
>BOOL out argument is local in wrapper class method,
> @@ -114,7 +115,7 @@ static void test_nextmarker(void)
> GdipCreatePathIter(&iter, path);
> stat = GdipPathIterNextMarker(iter, &result, &start, &end);
> expect(Ok, stat);
> -expect(0, result);
> +expect(TRUE, (result == 4) && (start == 0) && (end == 3));
Please break these out into their own tests. Like I said before, they
are independent, and if one of them fails, it's impossible to tell
from the test results which one is wrong. Also, none of the tests
should be (returned == expected) == TRUE. It should simply be
expect(expected, returned).
--
James Hawkins
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
James Hawkins wrote:
> On Sat, Jul 12, 2008 at 12:37 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
>
>> James Hawkins wrote:
>>
>>> On Sat, Jul 12, 2008 at 11:56 AM, Nikolay Sivov <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>
Changelog:
- Fix GdipPathIterNextMarker behaviour on path without markers. Make
tests pass on native.
---
dlls/gdiplus/pathiterator.c |3 ++-
dlls/gdiplus/tests/pathiterator.c |6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
index 55b0782..3d3b1dc 100644
--- a/dlls/gdiplus/pathiterator.c
+++ b/dlls/gdiplus/pathiterator.c
@@ -140,7 +140,8 @@ GpStatus WINGDIPAPI
GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
/* first call could start with second point as all subsequent, cause
path couldn't contain only one */
for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
-if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
+if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
+ (i == iterator->pathdata.Count - 1)){
*startIndex = iterator->marker_pos;
if(iterator->marker_pos > 0) (*startIndex)++;
*endIndex = iterator->marker_pos = i;
diff --git a/dlls/gdiplus/tests/pathiterator.c
b/dlls/gdiplus/tests/pathiterator.c
index 071c1d5..6498bb3 100644
--- a/dlls/gdiplus/tests/pathiterator.c
+++ b/dlls/gdiplus/tests/pathiterator.c
@@ -114,7 +114,7 @@ static void test_nextmarker(void)
GdipCreatePathIter(&iter, path);
stat = GdipPathIterNextMarker(iter, &result, &start, &end);
expect(Ok, stat);
-expect(0, result);
+if(stat == Ok) expect(TRUE, (result == 4) && (start == 0) && (end ==
3));
>>> Why are you checking if stat == Ok? You're linking what should be
>>> separate tests together. You also need to put each of these checks
>>> into separate tests. If the test fails, you have no idea (without
>>> debugging further) which one of those checks fails. They're called
>>> unit tests for a reason.
>>>
>>>
>> 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..
>>
>>
>
> An API defines a unique output* for the set of all possible inputs.
> When you write unit tests, you verify that the implementation of the
> API conforms to the definition. In the case of Wine, our definition
> of the Win32 API is the test results from running the Wine test suite
> in Windows. While msdn is a good reference, it's not always correct
> and we can't test our implementation against it.
>
If you mean that an API's defined by a mapping of all possible inputs to
a set of outputs I'm agreed.
> In all the cases where you've added checks for (stat != Ok), stat does
> equal Ok in Windows. Thus, the definition of the API for those inputs
> is that the functions return Ok. If, for a hypothetical example, one
> version of gdiplus did not return Ok, we would probably mark that as
> broken. That leads me to my next point.
>
> You say you added the checks because it's wrong to check the value of
> an uninitialized variable. You are correct in that it is wrong to
> check the value of an uninitialized variable. Where you are mistaken
> is that, by the definition of this API, none of these out variables
> will be uninitialized in these cases. One area where your tests are
> lacking is that you don't control all of the input. Even in the
> failure case, you should initialize all out variables to some magic
> value and then check the values of those parameters after the failed
> call. Either the values were unchanged, and thus still hold the magic
> value, or they are set to some other value. One bonus of this
> practice is that, even if the test fails in Wine when it should
> succeed, you're guaranteed to never read the value of an uninitialized
> variable.
>
So you mean here that in this case testing return value should be
unlinked to testing outputs, that these tests are independent. Maybe it
really helps when behaviour changes (API changes in fact) from version
to version. So maybe it's the better way to split this and let it both
test fail.
> So to answer your question, there should be no unpredictable values in
> a well-written test.
>
> * or a unique set of acceptable outputs, e.g., multiple GetLastError values.
Yes, I thought about some special 'magic' values for output arguments.
Some deadbeef should be acceptable.
Thanks for comments I'll repost these fixes.
Re: [dplayx] New library dpwsockx, needed by dplayx
On Sat, Jul 12, 2008 at 2:21 PM, Michael Karcher <[EMAIL PROTECTED]> wrote: > Am Samstag, den 12.07.2008, 12:40 -0500 schrieb James Hawkins: >> On Sat, Jul 12, 2008 at 12:25 PM, Ismael Barros <[EMAIL PROTECTED]> wrote: >> > but AFAIK wine doesn't want to put in include files that are not >> > originally present in Windows. >> If it's not in the SDK, it can't go into include. Also, please >> bottom-post on this mailing list. > > 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. -- James Hawkins
Re: [dplayx] New library dpwsockx, needed by dplayx
Am Samstag, den 12.07.2008, 12:40 -0500 schrieb James Hawkins: > On Sat, Jul 12, 2008 at 12:25 PM, Ismael Barros <[EMAIL PROTECTED]> wrote: > > but AFAIK wine doesn't want to put in include files that are not > > originally present in Windows. > If it's not in the SDK, it can't go into include. Also, please > bottom-post on this mailing list. OK, you got a point. So, what about an uninstalled file in include/wine? Not all files from there get installed. Regards, Michael Karcher
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
On Sat, Jul 12, 2008 at 12:37 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> James Hawkins wrote:
>>
>> On Sat, Jul 12, 2008 at 11:56 AM, Nikolay Sivov <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> Changelog:
>>> - Fix GdipPathIterNextMarker behaviour on path without markers. Make
>>> tests pass on native.
>>>
>>> ---
>>> dlls/gdiplus/pathiterator.c |3 ++-
>>> dlls/gdiplus/tests/pathiterator.c |6 +++---
>>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
>>> index 55b0782..3d3b1dc 100644
>>> --- a/dlls/gdiplus/pathiterator.c
>>> +++ b/dlls/gdiplus/pathiterator.c
>>> @@ -140,7 +140,8 @@ GpStatus WINGDIPAPI
>>> GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
>>>/* first call could start with second point as all subsequent, cause
>>> path couldn't contain only one */
>>>for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
>>> -if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
>>> +if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
>>> + (i == iterator->pathdata.Count - 1)){
>>>*startIndex = iterator->marker_pos;
>>>if(iterator->marker_pos > 0) (*startIndex)++;
>>>*endIndex = iterator->marker_pos = i;
>>> diff --git a/dlls/gdiplus/tests/pathiterator.c
>>> b/dlls/gdiplus/tests/pathiterator.c
>>> index 071c1d5..6498bb3 100644
>>> --- a/dlls/gdiplus/tests/pathiterator.c
>>> +++ b/dlls/gdiplus/tests/pathiterator.c
>>> @@ -114,7 +114,7 @@ static void test_nextmarker(void)
>>>GdipCreatePathIter(&iter, path);
>>>stat = GdipPathIterNextMarker(iter, &result, &start, &end);
>>>expect(Ok, stat);
>>> -expect(0, result);
>>> +if(stat == Ok) expect(TRUE, (result == 4) && (start == 0) && (end ==
>>> 3));
>>>
>>
>> Why are you checking if stat == Ok? You're linking what should be
>> separate tests together. You also need to put each of these checks
>> into separate tests. If the test fails, you have no idea (without
>> debugging further) which one of those checks fails. They're called
>> unit tests for a reason.
>>
>
> 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..
>
An API defines a unique output* for the set of all possible inputs.
When you write unit tests, you verify that the implementation of the
API conforms to the definition. In the case of Wine, our definition
of the Win32 API is the test results from running the Wine test suite
in Windows. While msdn is a good reference, it's not always correct
and we can't test our implementation against it.
In all the cases where you've added checks for (stat != Ok), stat does
equal Ok in Windows. Thus, the definition of the API for those inputs
is that the functions return Ok. If, for a hypothetical example, one
version of gdiplus did not return Ok, we would probably mark that as
broken. That leads me to my next point.
You say you added the checks because it's wrong to check the value of
an uninitialized variable. You are correct in that it is wrong to
check the value of an uninitialized variable. Where you are mistaken
is that, by the definition of this API, none of these out variables
will be uninitialized in these cases. One area where your tests are
lacking is that you don't control all of the input. Even in the
failure case, you should initialize all out variables to some magic
value and then check the values of those parameters after the failed
call. Either the values were unchanged, and thus still hold the magic
value, or they are set to some other value. One bonus of this
practice is that, even if the test fails in Wine when it should
succeed, you're guaranteed to never read the value of an uninitialized
variable.
So to answer your question, there should be no unpredictable values in
a well-written test.
* or a unique set of acceptable outputs, e.g., multiple GetLastError values.
--
James Hawkins
Re: [dplayx] New library dpwsockx, needed by dplayx
On 7/12/08, James Hawkins <[EMAIL PROTECTED]> wrote: > On Sat, Jul 12, 2008 at 12:25 PM, Ismael Barros <[EMAIL PROTECTED]> > wrote: >> Nop, actually I also thought the best solution would be to move that >> file to include, because in fact it's just copied from dlls/dplayx, >> but AFAIK wine doesn't want to put in include files that are not >> originally present in Windows. >> >> However, if it's okay I'll move it, much better. I will also have to >> implement a stub modem provider, so I would have to copy that >> dplaysp.h again to dlls/dpmodemx, and any change in those definitions >> would have to be done three times... >> > > If it's not in the SDK, it can't go into include. Also, please > bottom-post on this mailing list. As the Peter Hunnisett (author of dplaysp.h) told me, you have to ask Microsoft for the documentation and interface to create a new service provider, as this information was not made public because they never thought it were to become useful for anyone. I suppose this file was extracted from that documentation, but I can't confirm it yet.
Re: [dplayx] New library dpwsockx, needed by dplayx
On Sat, Jul 12, 2008 at 12:25 PM, Ismael Barros <[EMAIL PROTECTED]> wrote: > Nop, actually I also thought the best solution would be to move that > file to include, because in fact it's just copied from dlls/dplayx, > but AFAIK wine doesn't want to put in include files that are not > originally present in Windows. > > However, if it's okay I'll move it, much better. I will also have to > implement a stub modem provider, so I would have to copy that > dplaysp.h again to dlls/dpmodemx, and any change in those definitions > would have to be done three times... > If it's not in the SDK, it can't go into include. Also, please bottom-post on this mailing list. -- James Hawkins
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
James Hawkins wrote:
> On Sat, Jul 12, 2008 at 11:56 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
>
>> Changelog:
>>- Fix GdipPathIterNextMarker behaviour on path without markers. Make
>> tests pass on native.
>>
>> ---
>> dlls/gdiplus/pathiterator.c |3 ++-
>> dlls/gdiplus/tests/pathiterator.c |6 +++---
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
>> index 55b0782..3d3b1dc 100644
>> --- a/dlls/gdiplus/pathiterator.c
>> +++ b/dlls/gdiplus/pathiterator.c
>> @@ -140,7 +140,8 @@ GpStatus WINGDIPAPI
>> GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
>> /* first call could start with second point as all subsequent, cause
>>path couldn't contain only one */
>> for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
>> -if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
>> +if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
>> + (i == iterator->pathdata.Count - 1)){
>> *startIndex = iterator->marker_pos;
>> if(iterator->marker_pos > 0) (*startIndex)++;
>> *endIndex = iterator->marker_pos = i;
>> diff --git a/dlls/gdiplus/tests/pathiterator.c
>> b/dlls/gdiplus/tests/pathiterator.c
>> index 071c1d5..6498bb3 100644
>> --- a/dlls/gdiplus/tests/pathiterator.c
>> +++ b/dlls/gdiplus/tests/pathiterator.c
>> @@ -114,7 +114,7 @@ static void test_nextmarker(void)
>> GdipCreatePathIter(&iter, path);
>> stat = GdipPathIterNextMarker(iter, &result, &start, &end);
>> expect(Ok, stat);
>> -expect(0, result);
>> +if(stat == Ok) expect(TRUE, (result == 4) && (start == 0) && (end ==
>> 3));
>>
>
> Why are you checking if stat == Ok? You're linking what should be
> separate tests together. You also need to put each of these checks
> into separate tests. If the test fails, you have no idea (without
> debugging further) which one of those checks fails. They're called
> unit tests for a reason.
>
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..
Re: [dplayx] New library dpwsockx, needed by dplayx
Nop, actually I also thought the best solution would be to move that file to include, because in fact it's just copied from dlls/dplayx, but AFAIK wine doesn't want to put in include files that are not originally present in Windows. However, if it's okay I'll move it, much better. I will also have to implement a stub modem provider, so I would have to copy that dplaysp.h again to dlls/dpmodemx, and any change in those definitions would have to be done three times... On 7/12/08, Michael Karcher <[EMAIL PROTECTED]> wrote: > Am Samstag, den 12.07.2008, 18:46 +0300 schrieb Ismael Barros: >> I'm sorry, that patch lacked a header file, this is the fixed patch. > > I would put the dplaysp.h file into include, not dlls/dpwsockx. It > contains definitions for all DirectPlay service providers, so it might > be useful if a modem provider or a direct serial connection provider > will be implemented. Is there a reason not to do so? > > Regards, > Michael Karcher > > -- ...yet even then, we ran like the wind, whilst our laughter echoed, under cerulean skies...
Re: [2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.
On Sat, Jul 12, 2008 at 11:56 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> Changelog:
>- Fix GdipPathIterNextMarker behaviour on path without markers. Make
> tests pass on native.
>
> ---
> dlls/gdiplus/pathiterator.c |3 ++-
> dlls/gdiplus/tests/pathiterator.c |6 +++---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/gdiplus/pathiterator.c b/dlls/gdiplus/pathiterator.c
> index 55b0782..3d3b1dc 100644
> --- a/dlls/gdiplus/pathiterator.c
> +++ b/dlls/gdiplus/pathiterator.c
> @@ -140,7 +140,8 @@ GpStatus WINGDIPAPI
> GdipPathIterNextMarker(GpPathIterator* iterator, INT *result
> /* first call could start with second point as all subsequent, cause
>path couldn't contain only one */
> for(i = iterator->marker_pos + 1; i < iterator->pathdata.Count; i++){
> -if(iterator->pathdata.Types[i] & PathPointTypePathMarker){
> +if((iterator->pathdata.Types[i] & PathPointTypePathMarker) ||
> + (i == iterator->pathdata.Count - 1)){
> *startIndex = iterator->marker_pos;
> if(iterator->marker_pos > 0) (*startIndex)++;
> *endIndex = iterator->marker_pos = i;
> diff --git a/dlls/gdiplus/tests/pathiterator.c
> b/dlls/gdiplus/tests/pathiterator.c
> index 071c1d5..6498bb3 100644
> --- a/dlls/gdiplus/tests/pathiterator.c
> +++ b/dlls/gdiplus/tests/pathiterator.c
> @@ -114,7 +114,7 @@ static void test_nextmarker(void)
> GdipCreatePathIter(&iter, path);
> stat = GdipPathIterNextMarker(iter, &result, &start, &end);
> expect(Ok, stat);
> -expect(0, result);
> +if(stat == Ok) expect(TRUE, (result == 4) && (start == 0) && (end == 3));
Why are you checking if stat == Ok? You're linking what should be
separate tests together. You also need to put each of these checks
into separate tests. If the test fails, you have no idea (without
debugging further) which one of those checks fails. They're called
unit tests for a reason.
> GdipDeletePathIter(iter);
>
> /* one marker */
> @@ -125,7 +125,7 @@ static void test_nextmarker(void)
> expect(TRUE, (start == 0) && (end == 3) && (result == 4));
> stat = GdipPathIterNextMarker(iter, &result, &start, &end);
> expect(Ok, stat);
> -expect(0, result);
> +if(stat == Ok) expect(0, result);
Same thing as above.
> GdipDeletePathIter(iter);
>
> /* two markers */
> @@ -140,7 +140,7 @@ static void test_nextmarker(void)
> expect(TRUE, (start == 4) && (end == 5) && (result == 2));
> stat = GdipPathIterNextMarker(iter, &result, &start, &end);
> expect(Ok, stat);
> -expect(0, result);
> +if(stat == Ok) expect(0, result);
Same.
--
James Hawkins
Re: [dplayx] New library dpwsockx, needed by dplayx
Am Samstag, den 12.07.2008, 18:46 +0300 schrieb Ismael Barros: > I'm sorry, that patch lacked a header file, this is the fixed patch. I would put the dplaysp.h file into include, not dlls/dpwsockx. It contains definitions for all DirectPlay service providers, so it might be useful if a modem provider or a direct serial connection provider will be implemented. Is there a reason not to do so? Regards, Michael Karcher
Re: winhttp: tests/winhttp.c[new]: Add test for WinHttpOpenRequest
On Thu, 10 Jul 2008, Zac Brown wrote: > Zac Brown wrote: > > Add test for WinHttpOpenRequest. This test is modeled after > > wininet/tests/http.c's InternetOpenRequest_test function. > > > > This is the first of many tests for getting Bug 14381 > > (http://bugs.winehq.org/show_bug.cgi?id=14381) fixed with regard to > > WinHTTP. [...] > As a note this passes on Win XP as well as Win 2003. In other notes you may want to be a bit more selective when quoting past emails. This will make your emails much more readable. Really! -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ 145 = 1! + 4! + 5!
Re: Installing Wine's fonts system-wide: which ones are worthwhile?
On Fri, 11 Jul 2008, Scott Ritchie wrote:
[...]
> On Ubuntu, the
> liberation fonts also not installed by default. Which brings up a
> related question: should the Wine package depend on them? It seems like
> having liberation fonts available would be helpful to Wine, and
> therefore they should be installed when Wine is.
Depend or Recommend: I don't think so. Maybe suggest though.
--
Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/
$live{free} || die "";
Re: Question about crosstest build
Michael Karcher wrote: > Am Samstag, den 12.07.2008, 18:13 +0400 schrieb Nikolay Sivov: > >> Hi. >> >> Could someone explain me in details how could I build crosstest binaries >> on Linux (Debian) to run them on WinXP? >> Now I've done the following: >> - clean up my wine tree with 'make clean'; >> - installed mingw32 package >> - use configure parameters from >> http://wiki.winehq.org/CompilingDLLsUsingMingw >> - use 'make crosstest' from tree top. >> >> After building wine tools I've got: >> >> make[1]: Entering directory `/home/mrlarch/wine/dlls' >> make[2]: Entering directory `/home/mrlarch/wine/dlls/d3dx9_36' >> ../../tools/winebuild/winebuild -w --def -o d3dx9_36.def --export >> ./d3dx9_36.spec >> false -k -l libd3dx9.a -d d3dx9_36.def >> > [...] > >> What should I do with that? >> > > Read your configure log. mingw was obviously not found, and false (a > command that always fails) was written instead to the makefile. > > Regards, > Michael Karcher > > Thanks, it works now.
Re: Question about crosstest build
Am Samstag, den 12.07.2008, 18:13 +0400 schrieb Nikolay Sivov: > Hi. > > Could someone explain me in details how could I build crosstest binaries > on Linux (Debian) to run them on WinXP? > Now I've done the following: > - clean up my wine tree with 'make clean'; > - installed mingw32 package > - use configure parameters from > http://wiki.winehq.org/CompilingDLLsUsingMingw > - use 'make crosstest' from tree top. > > After building wine tools I've got: > > make[1]: Entering directory `/home/mrlarch/wine/dlls' > make[2]: Entering directory `/home/mrlarch/wine/dlls/d3dx9_36' > ../../tools/winebuild/winebuild -w --def -o d3dx9_36.def --export > ./d3dx9_36.spec > false -k -l libd3dx9.a -d d3dx9_36.def [...] > What should I do with that? Read your configure log. mingw was obviously not found, and false (a command that always fails) was written instead to the makefile. Regards, Michael Karcher
Question about crosstest build
Hi. Could someone explain me in details how could I build crosstest binaries on Linux (Debian) to run them on WinXP? Now I've done the following: - clean up my wine tree with 'make clean'; - installed mingw32 package - use configure parameters from http://wiki.winehq.org/CompilingDLLsUsingMingw - use 'make crosstest' from tree top. After building wine tools I've got: make[1]: Entering directory `/home/mrlarch/wine/dlls' make[2]: Entering directory `/home/mrlarch/wine/dlls/d3dx9_36' ../../tools/winebuild/winebuild -w --def -o d3dx9_36.def --export ./d3dx9_36.spec false -k -l libd3dx9.a -d d3dx9_36.def make[2]: *** [libd3dx9.a] Error 1 make[2]: Leaving directory `/home/mrlarch/wine/dlls/d3dx9_36' make[1]: *** [d3dx9_36/libd3dx9.a] Error 2 make[1]: Leaving directory `/home/mrlarch/wine/dlls' make: *** [dlls/__crosstest__] Error 2 What should I do with that?
Re: failing gdiplus:matrix tests
Nikolay Sivov <[EMAIL PROTECTED]> writes: > Alexandre Julliard wrote: >> You no longer need a patched mingw, crosstest uses the Wine import libs now. > So this page http://wiki.winehq.org/CompilingDLLsUsingMingw will be > enough to build crosstest binaries? You don't need any of that, just do a 'make crosstest' in the normal tree. -- Alexandre Julliard [EMAIL PROTECTED]
Re: failing gdiplus:matrix tests
Alexandre Julliard wrote: > "James Hawkins" <[EMAIL PROTECTED]> writes: > > >> 'make crosstest' works if you have a patched mingw. You can get the patches >> at: >> >> http://www.astro.gla.ac.uk/users/paulm/Cross/ >> > > You no longer need a patched mingw, crosstest uses the Wine import libs now. So this page http://wiki.winehq.org/CompilingDLLsUsingMingw will be enough to build crosstest binaries?
Re: failing gdiplus:matrix tests
"James Hawkins" <[EMAIL PROTECTED]> writes: > 'make crosstest' works if you have a patched mingw. You can get the patches > at: > > http://www.astro.gla.ac.uk/users/paulm/Cross/ You no longer need a patched mingw, crosstest uses the Wine import libs now. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winehq] broken link
Stefan Leichter wrote: > when i click on the "Development" link in the "Development" section i get an > 404 error. Can someone please fix this. > Its been in bugzilla for a while, [Bug 13898] Busted Development link.
Re: failing gdiplus:matrix tests
James Hawkins wrote: > On Sat, Jul 12, 2008 at 1:58 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote: > >> James Hawkins wrote: >> >>> Hi Nikolay, >>> >>> Tests you added in the following commit fail on all platforms. Did >>> you run the tests in Windows? >>> >>> commit d7999a008be5d7e95fcd86019adc79b0359ae8d4 >>> Author: Nikolay Sivov <[EMAIL PROTECTED]> >>> Date: Tue Jul 8 01:32:36 2008 +0400 >>> >>>gdiplus: GdipInvertMatrix implementation with tests. >>> >>> >> No, I never tried to run the test binary on Windows. I always try get test >> results >> trough my own test application and use these results in Wine test. >> Of course I will fix this, could you explain how to build tests on Windows? >> I never did such thing. >> >> > > http://wiki.winehq.org/CompilingDLLsUsingMingw > > 'make crosstest' works if you have a patched mingw. You can get the patches > at: > > http://www.astro.gla.ac.uk/users/paulm/Cross/ > > If you end up not being able to build the tests, ask someone on > wine-devel to build them for you. > As I see we need patch only w32api package. Could this be done after installation of all Debian packages?
[winehq] broken link
Hi, when i click on the "Development" link in the "Development" section i get an 404 error. Can someone please fix this. Thanks Stefan
Re: failing gdiplus:matrix tests
James Hawkins wrote: > On Sat, Jul 12, 2008 at 1:58 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote: > >> James Hawkins wrote: >> >>> Hi Nikolay, >>> >>> Tests you added in the following commit fail on all platforms. Did >>> you run the tests in Windows? >>> >>> commit d7999a008be5d7e95fcd86019adc79b0359ae8d4 >>> Author: Nikolay Sivov <[EMAIL PROTECTED]> >>> Date: Tue Jul 8 01:32:36 2008 +0400 >>> >>>gdiplus: GdipInvertMatrix implementation with tests. >>> >>> >> No, I never tried to run the test binary on Windows. I always try get test >> results >> trough my own test application and use these results in Wine test. >> Of course I will fix this, could you explain how to build tests on Windows? >> I never did such thing. >> >> > > http://wiki.winehq.org/CompilingDLLsUsingMingw > > 'make crosstest' works if you have a patched mingw. You can get the patches > at: > > http://www.astro.gla.ac.uk/users/paulm/Cross/ > > If you end up not being able to build the tests, ask someone on > wine-devel to build them for you. > Ok, I'll try this.
Re: failing gdiplus:matrix tests
On Sat, Jul 12, 2008 at 1:58 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote: > James Hawkins wrote: >> >> Hi Nikolay, >> >> Tests you added in the following commit fail on all platforms. Did >> you run the tests in Windows? >> >> commit d7999a008be5d7e95fcd86019adc79b0359ae8d4 >> Author: Nikolay Sivov <[EMAIL PROTECTED]> >> Date: Tue Jul 8 01:32:36 2008 +0400 >> >>gdiplus: GdipInvertMatrix implementation with tests. >> > > No, I never tried to run the test binary on Windows. I always try get test > results > trough my own test application and use these results in Wine test. > Of course I will fix this, could you explain how to build tests on Windows? > I never did such thing. > http://wiki.winehq.org/CompilingDLLsUsingMingw 'make crosstest' works if you have a patched mingw. You can get the patches at: http://www.astro.gla.ac.uk/users/paulm/Cross/ If you end up not being able to build the tests, ask someone on wine-devel to build them for you. -- James Hawkins
Re: failing gdiplus:matrix tests
On Sat, Jul 12, 2008 at 1:58 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote: > James Hawkins wrote: >> >> Hi Nikolay, >> >> Tests you added in the following commit fail on all platforms. Did >> you run the tests in Windows? >> >> commit d7999a008be5d7e95fcd86019adc79b0359ae8d4 >> Author: Nikolay Sivov <[EMAIL PROTECTED]> >> Date: Tue Jul 8 01:32:36 2008 +0400 >> >>gdiplus: GdipInvertMatrix implementation with tests. >> > > No, I never tried to run the test binary on Windows. I always try get test > results > trough my own test application and use these results in Wine test. > Of course I will fix this, could you explain how to build tests on Windows? > I never did such thing. > http://wiki.winehq.org/CompilingDLLsUsingMingw 'make crosstest' works if you have a patched mingw. You can get the patches at: http://www.astro.gla.ac.uk/users/paulm/Cross/ If you end up not being able to build the tests, ask someone on wine-devel to build them for you. -- James Hawkins
