Re: GSoC: dinput8 Action Mapping

2011-06-29 Thread Lucas Zawacki
Hey guys, how are you doing? I've got some patches for you.

The first is a refactoring of the BuildActionMap implementations for
keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is
pretty much correct for  keyboard and mouse and it's being done "the
right way".

The second patch is much like one I sent some time ago, it's
SetActionMap for keyboard and mouse, this time (hopefully) with the
dataformat stuff done right too. I've split it up in a third patch,
which implements the "action mapping" per se.

Anyway, tomorrow I'll code some mouse tests to be sure that this is working.

Cheers
From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki 
Date: Fri, 10 Jun 2011 21:43:53 -0300
Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4)

Now with an actual mouse implementation and some common code factored out.
---
 dlls/dinput/device.c |   32 +-
 dlls/dinput/device_private.h |2 +
 dlls/dinput/keyboard.c   |   60 -
 dlls/dinput/mouse.c  |   57 ++-
 dlls/dinput8/tests/device.c  |8 +++---
 5 files changed, 149 insertions(+), 10 deletions(-)

diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c
index 5a03a27..b66c947 100644
--- a/dlls/dinput/device.c
+++ b/dlls/dinput/device.c
@@ -547,6 +547,34 @@ int find_property(const DataFormat *df, LPCDIPROPHEADER ph)
 return -1;
 }
 
+DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic)
+{
+DWORD type = (0xff00 & dwSemantic) >> 8;
+DWORD offset = 0x00ff & dwSemantic;
+DWORD obj_instance = 0;
+DWORD found = 0;
+int i;
+
+for (i = 0; i < This->data_format.wine_df->dwNumObjs; i++)
+{
+LPDIOBJECTDATAFORMAT odf = dataformat_to_odf(This->data_format.wine_df, i);
+
+if (odf->dwOfs == offset)
+{
+obj_instance = DIDFT_GETINSTANCE(odf->dwType);
+found = 1;
+break;
+}
+}
+
+if (!found) return 0;
+
+if (type & DIDFT_AXIS)   type = DIDFT_RELAXIS;
+if (type & DIDFT_BUTTON) type = DIDFT_PSHBUTTON;
+
+return type | (0xff00 & (obj_instance << 8));
+}
+
 /**
  *	queue_event - add new event to the ring queue
  */
@@ -1359,7 +1387,7 @@ HRESULT WINAPI IDirectInputDevice8AImpl_BuildActionMap(LPDIRECTINPUTDEVICE8A ifa
 		   LPCSTR lpszUserName,
 		   DWORD dwFlags)
 {
-FIXME("(%p)->(%p,%s,%08x): stub !\n", iface, lpdiaf, lpszUserName, dwFlags);
+FIXME("(%p)->(%p,%s,%08x): semi-stub !\n", iface, lpdiaf, lpszUserName, dwFlags);
 #define X(x) if (dwFlags & x) FIXME("\tdwFlags =|"#x"\n");
 	X(DIDBAM_DEFAULT)
 	X(DIDBAM_PRESERVE)
@@ -1375,7 +1403,7 @@ HRESULT WINAPI IDirectInputDevice8WImpl_BuildActionMap(LPDIRECTINPUTDEVICE8W ifa
 		   LPCWSTR lpszUserName,
 		   DWORD dwFlags)
 {
-FIXME("(%p)->(%p,%s,%08x): stub !\n", iface, lpdiaf, debugstr_w(lpszUserName), dwFlags);
+FIXME("(%p)->(%p,%s,%08x): semi-stub !\n", iface, lpdiaf, debugstr_w(lpszUserName), dwFlags);
 #define X(x) if (dwFlags & x) FIXME("\tdwFlags =|"#x"\n");
 	X(DIDBAM_DEFAULT)
 	X(DIDBAM_PRESERVE)
diff --git a/dlls/dinput/device_private.h b/dlls/dinput/device_private.h
index f254d7f..a5f7f83 100644
--- a/dlls/dinput/device_private.h
+++ b/dlls/dinput/device_private.h
@@ -114,6 +114,8 @@ extern void _dump_OBJECTINSTANCEW(const DIDEVICEOBJECTINSTANCEW *ddoi)  DECLSPEC
 extern void _dump_DIDATAFORMAT(const DIDATAFORMAT *df)  DECLSPEC_HIDDEN;
 extern const char *_dump_dinput_GUID(const GUID *guid)  DECLSPEC_HIDDEN;
 
+extern DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic)  DECLSPEC_HIDDEN;
+
 /* And the stubs */
 extern HRESULT WINAPI IDirectInputDevice2AImpl_Acquire(LPDIRECTINPUTDEVICE8A iface) DECLSPEC_HIDDEN;
 extern HRESULT WINAPI IDirectInputDevice2WImpl_Acquire(LPDIRECTINPUTDEVICE8W iface) DECLSPEC_HIDDEN;
diff --git a/dlls/dinput/keyboard.c b/dlls/dinput/keyboard.c
index c697cfd..204510a 100644
--- a/dlls/dinput/keyboard.c
+++ b/dlls/dinput/keyboard.c
@@ -524,6 +524,62 @@ static HRESULT WINAPI SysKeyboardAImpl_GetProperty(LPDIRECTINPUTDEVICE8A iface,
 return SysKeyboardWImpl_GetProperty(IDirectInputDevice8W_from_impl(This), rguid, pdiph);
 }
 
+HRESULT WINAPI SysKeyboardWImpl_BuildActionMap(LPDIRECTINPUTDEVICE8W iface,
+   LPDIACTIONFORMATW lpdiaf,
+   LPCWSTR lpszUserName,
+   DWORD dwFlags)
+{
+SysKeyboardImpl *This = impl_from_IDirectInputDevice8W(iface);
+int i, has_actions = 0;
+
+FIXME("(%p)->(%p,%s,%08x): semi-stub !\n", iface, lpdiaf, debugstr_w(lpszUserName), dwFlags);
+
+for (i=0; i < lpdiaf->dwNumActions; i++)
+{
+if ((lpdiaf->rgoAction[i].dwSemantic & DIKEYBOAR

Re: wine bug 27600

2011-06-29 Thread Vincas Miliūnas
On 06/30/2011 02:19 AM, wy...@volny.cz wrote:
>> There is some garbage added to the patch code, I
>> suspect that the way
>> you downloaded the patch corrupted it.
>>
>> I wrote a bash script that will download the
>> patches correctly and apply
>> them:
>>
>> git clean -fd
>> git reset --hard origin/master
>> for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880
>> do
>> wget http://source.winehq.org/patches/data/$i -O
>> /tmp/raw-$i.patch
>> git apply /tmp/raw-$i.patch
>> done
>> ./tools/make_requests
>
> Even before i used wget for downloads & patch -p1. Anyway i gave
> your script a chance,  but i got during the compilation:
>
>
> gcc -c -I. -I. -I../include -I../include  -D__WINESRC__  -Wall -pipe
> -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith
> -Wlogical-op  -g -O2  -o raw_input.o raw_input.c
>
> In file included from raw_input.c:28:
>
> ../include/winternl.h:2361: error: expected declaration specifiers
> or ‘...’ before ‘va_list’
>
> ../include/winternl.h:2531: error: expected declaration specifiers
> or ‘...’ before ‘va_list’
>
> ../include/winternl.h:2532: error: expected declaration specifiers
> or ‘...’ before ‘va_list’
>
> In file included from raw_input.c:29:
>
> ../include/winbase.h:1578: error: expected declaration specifiers or
> ‘...’ before ‘va_list’
>
> ../include/winbase.h:1579: error: expected declaration specifiers or
> ‘...’ before ‘va_list’
>
> make[1]: *** [raw_input.o] Error 1
>
> make[1]: Leaving directory `/build/wine-git_build/server'
>
> make: *** [server] Error 2
>
>
Ok, try with a modified header:

git clean -fd
git reset --hard origin/master
for patch in \
0001-user32-tests-Added-client-side-raw-input-function-te.patch \
0002-user32-Added-DefRawInputProc-implementation-try-10.patch \
0003-server-user32-Added-GetRawInputDeviceList-implementa.patch \
0004-server-user32-Added-GetRawInputDeviceInfoW-implement.patch \
0005-user32-Added-GetRawInputDeviceInfoA-implementation-t.patch \
0006-server-user32-Added-GetRegisteredRawInputDevices-imp.patch \
0007-server-user32-Added-RegisterRawInputDevices-implemen.patch \
0008-user32-Added-GetRawInputBuffer-implementation-try-10.patch \
0009-server-user32-Added-GetRawInputData-implementation-t.patch
do
wget http://dl.dropbox.com/u/6901628/$patch -O /tmp/$patch
git apply /tmp/$patch
done
./tools/make_requests





Re: [PATCH 3/3] d3dx9/tests: Implemented Draw and DrawTransform tests for ID3DXLine.

2011-06-29 Thread Marvin
Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=12105

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed to apply




Re: [PATCH 3/3] d3dx9/tests: Implemented Draw and DrawTransform tests for ID3DXLine.

2011-06-29 Thread Charles Welton
Forgot that this patch was based on the previous one I sent. I should
probably resend when and if the others are committed.

On 06/29/2011 10:20 PM, Marvin wrote:
> Hi,
> 
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> Full results can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=12105
> 
> Your paranoid android.
> 
> 
> === WINEBUILD (build) ===
> Patch failed to apply

-- 
Charles Welton




Re: [2/2] d3dx9_36: Implement and add tests for D3DXFloat16To32Array.

2011-06-29 Thread Matteo Bruni
2011/6/29 Misha Koshelev :
> ---
...
> +else return sgn * powf(2, -14.0f) * ((float)m / 1024.0f);
 ...
> +return sgn * powf(2, (float)e - 15.0f) * (1.0f + ((float)m / 
> 1024.0f));

I think you don't need the explicit casts here, the values should be
automatically promoted to floats as the other operand is a float as
well.




Re: wine bug 27600

2011-06-29 Thread wylda
> There is some garbage added to the patch code, I
> suspect that the way
> you downloaded the patch corrupted it.
> 
> I wrote a bash script that will download the
> patches correctly and apply
> them:
> 
> git clean -fd
> git reset --hard origin/master
> for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880
> do
> wget http://source.winehq.org/patches/data/$i -O
> /tmp/raw-$i.patch
> git apply /tmp/raw-$i.patch
> done
> ./tools/make_requests


Even before i used wget for downloads & patch -p1. Anyway i gave
your script a chance,  but i got during the compilation:


gcc -c -I. -I. -I../include -I../include  -D__WINESRC__  -Wall -pipe
-fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith
-Wlogical-op  -g -O2  -o raw_input.o raw_input.c

In file included from raw_input.c:28:

../include/winternl.h:2361: error: expected declaration specifiers
or ‘...’ before ‘va_list’

../include/winternl.h:2531: error: expected declaration specifiers
or ‘...’ before ‘va_list’

../include/winternl.h:2532: error: expected declaration specifiers
or ‘...’ before ‘va_list’

In file included from raw_input.c:29:

../include/winbase.h:1578: error: expected declaration specifiers or
‘...’ before ‘va_list’

../include/winbase.h:1579: error: expected declaration specifiers or
‘...’ before ‘va_list’

make[1]: *** [raw_input.o] Error 1

make[1]: Leaving directory `/build/wine-git_build/server'

make: *** [server] Error 2





Re: Bad_Pool_Header

2011-06-29 Thread Austin English
On Wed, Jun 29, 2011 at 03:01, Keith Muir  wrote:
> Hi,
>
> Been trying to run wine tests from http://test.winehq.org/data/ but every
> time I try this for about the last half dozen versions I get a blue screen
> and bad pool header
> any suggestions? I try to support the project by doing test runs and
> updating the appdb.

What video card/OS/drivers? Can you narrow it down to the first
bad/last working winetest?

Cheers,
Austin




Bad_Pool_Header

2011-06-29 Thread Keith Muir

Hi,

Been trying to run wine tests from http://test.winehq.org/data/ but 
every time I try this for about the last half dozen versions I get a 
blue screen and bad pool header
any suggestions? I try to support the project by doing test runs and 
updating the appdb.


Regards,

Keith




Re: wine bug 27600

2011-06-29 Thread Vincas Miliūnas
On 06/30/2011 12:22 AM, wy...@volny.cz wrote:
>> The patch is rebased against today's commits -
>> http://dl.dropbox.com/u/6901628/raw.patch
> The good news is, that this combo patch successfully compiles here.
>
> The bad new is, that today's 9 newly sent patches still fails here.
> I did regression test above them and 1of9 + 2of9 successfully
> compiles here, in other word first bad "commit" is 3of9.
>
> Adding config.log and output of ./configure (each as vanilla and
> patched for comparison).
>
>
> Regards,
> W.
>
>
>
The 3th patch adds the c file for wineserver.
./configure log just shows that you have way more devel packages
installed then me :)

There is some garbage added to the patch code, I suspect that the way
you downloaded the patch corrupted it.

I wrote a bash script that will download the patches correctly and apply
them:

git clean -fd
git reset --hard origin/master
for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880
do
wget http://source.winehq.org/patches/data/$i -O /tmp/raw-$i.patch
git apply /tmp/raw-$i.patch
done
./tools/make_requests





Re: Ge (Greg) van Geldorp

2011-06-29 Thread Tom Wickline
Hello,

Alexandre, is there the possibility we/you could have a release in Greg's
memory?

Cheers,
Tom

On Thu, Jun 30, 2011 at 12:47 AM, Erich Hoover  wrote:

> On Sat, Jun 11, 2011 at 3:47 PM, James McKenzie wrote:
>
>> ...  It will take more than one person to fill Ge's shoes for providing
>> the testbot system and for his actions to get our efforts recognized in the
>> Virtual community.
>>
>
> I think we should modify the testbot page to have a little memorial
> message.  If anything, I know that I can say that my contributions to the
> animated cursor support are a direct result of the availability of the
> testbot.  Without the testbot I doubt I'd have ever figured out exactly how
> GetCursorFrameInfo works.  I know it'd been a while since this conversation
> got started, but I've been a bit busy and I thought this idea was worth
> mentioning.
>
> Erich Hoover
> ehoo...@mines.edu
>
>
>
>


-- 
Wine is not a conclusion but a process...



Re: Ge (Greg) van Geldorp

2011-06-29 Thread Erich Hoover
On Sat, Jun 11, 2011 at 3:47 PM, James McKenzie wrote:

> ...  It will take more than one person to fill Ge's shoes for providing the
> testbot system and for his actions to get our efforts recognized in the
> Virtual community.
>

I think we should modify the testbot page to have a little memorial
message.  If anything, I know that I can say that my contributions to the
animated cursor support are a direct result of the availability of the
testbot.  Without the testbot I doubt I'd have ever figured out exactly how
GetCursorFrameInfo works.  I know it'd been a while since this conversation
got started, but I've been a bit busy and I thought this idea was worth
mentioning.

Erich Hoover
ehoo...@mines.edu



Re: [1/2] include: Add declarations related to D3DXFLOAT16.

2011-06-29 Thread Dylan Smith
On Wed, Jun 29, 2011 at 11:16 AM, Misha Koshelev  wrote:

> Submitted by original author as requested by Alexandre. Necessary for
> further patches by Dylan Smith to fix bug 25769.
>

 Attached are the further patches he is referring to, which are based on his
patch series.
From 90b47b2dae25b933cc66510607e5a76fa1005155 Mon Sep 17 00:00:00 2001
From: Dylan Smith 
Date: Tue, 29 Mar 2011 13:47:38 -0400
Subject: [ 1/2] d3dx9: Implement D3DXFloat32To16Array.
Reply-To: wine-devel 
X-Our-ReplyTo: Full
To: wine-patches 

Derived from patch submitted by Misha Koshelev .

Corrected rounding of denormalized numbers.
---
 dlls/d3dx9_36/d3dx9_36.spec |2 +-
 dlls/d3dx9_36/math.c|   97 +++
 dlls/d3dx9_36/tests/math.c  |9 
 3 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec
index 5973d20..19c38c1 100644
--- a/dlls/d3dx9_36/d3dx9_36.spec
+++ b/dlls/d3dx9_36/d3dx9_36.spec
@@ -131,7 +131,7 @@
 @ stdcall D3DXFilterTexture(ptr ptr long long)
 @ stdcall D3DXFindShaderComment(ptr long ptr ptr)
 @ stdcall D3DXFloat16To32Array(ptr ptr long)
-@ stub D3DXFloat32To16Array(ptr ptr long)
+@ stdcall D3DXFloat32To16Array(ptr ptr long)
 @ stub D3DXFrameAppendChild(ptr ptr)
 @ stub D3DXFrameCalculateBoundingSphere(ptr ptr ptr)
 @ stdcall D3DXFrameDestroy(ptr ptr)
diff --git a/dlls/d3dx9_36/math.c b/dlls/d3dx9_36/math.c
index 229a058..2e455c6 100644
--- a/dlls/d3dx9_36/math.c
+++ b/dlls/d3dx9_36/math.c
@@ -1770,6 +1770,103 @@ D3DXVECTOR4* WINAPI D3DXVec4TransformArray(D3DXVECTOR4* 
out, UINT outstride, CON
 return out;
 }
 
+static inline unsigned short float_32_to_16(const float in)
+{
+int exp = 0, origexp;
+float tmp = fabs(in);
+int sign = signbit(in);
+unsigned int mantissa;
+unsigned short ret;
+
+/* Deal with special numbers */
+if (isinf(in)) return (sign ? 0x : 0x7fff);
+if (isnan(in)) return (sign ? 0x : 0x7fff);
+if (in == 0.0f) return (sign ? 0x8000 : 0x);
+
+if (tmp < powf(2, 10))
+{
+do
+{
+tmp *= 2.0f;
+exp--;
+} while (tmp < powf(2, 10));
+}
+else if (tmp >= powf(2, 11))
+{
+do
+{
+tmp /= 2.0f;
+exp++;
+} while (tmp >= powf(2, 11));
+}
+
+exp += 10;  /* Normalize the mantissa */
+exp += 15;  /* Exponent is encoded with excess 15 */
+
+origexp = exp;
+
+mantissa = (unsigned int) tmp;
+if ((tmp - mantissa == 0.5f && mantissa % 2 == 1) || /* round half to even 
*/
+(tmp - mantissa > 0.5f))
+{
+mantissa++; /* round to nearest, away from zero */
+}
+if (mantissa == 2048)
+{
+mantissa = 1024;
+exp++;
+}
+
+if (exp > 31)
+{
+/* too big */
+ret = 0x7fff; /* INF */
+}
+else if (exp <= 0)
+{
+unsigned int rounding = 0;
+
+/* Denormalized half float */
+
+/* return 0x (=0.0) for numbers too small to represent in half 
floats */
+if (exp < -11)
+return (sign ? 0x8000 : 0x);
+
+exp = origexp;
+
+/* the 13 extra bits from single precision are used for rounding */
+mantissa = (unsigned int)(tmp * powf(2, 13));
+mantissa >>= 1 - exp; /* denormalize */
+
+mantissa -= ~(mantissa >> 13) & 1; /* round half to even */
+/* remove 13 least significant bits to get half float precision */
+mantissa >>= 12;
+rounding = mantissa & 1;
+mantissa >>= 1;
+
+ret = mantissa + rounding;
+}
+else
+{
+ret = (exp << 10) | (mantissa & 0x3ff);
+}
+
+ret |= ((sign ? 1 : 0) << 15); /* Add the sign */
+return ret;
+}
+
+D3DXFLOAT16 *WINAPI D3DXFloat32To16Array(D3DXFLOAT16 *pout, CONST FLOAT *pin, 
UINT n)
+{
+unsigned int i;
+
+for (i = 0; i < n; ++i)
+{
+pout[i].value = float_32_to_16(pin[i]);
+}
+
+return pout;
+}
+
 /* Native d3dx9's D3DXFloat16to32Array lacks support for NaN and Inf. 
Specifically, e = 16 is treated as a
  * regular number - e.g., 0x7fff is converted to 131008.0 and 0x to 
-131008.0. */
 static inline float float_16_to_32(const unsigned short in)
diff --git a/dlls/d3dx9_36/tests/math.c b/dlls/d3dx9_36/tests/math.c
index aa3f135..5dbc863 100644
--- a/dlls/d3dx9_36/tests/math.c
+++ b/dlls/d3dx9_36/tests/math.c
@@ -2257,11 +2257,20 @@ static void test_D3DXFloat_Array(void)
 };
 
 /* exception on NULL out or in parameter */
+out = D3DXFloat32To16Array(&half, &single, 0);
+ok(out == &half, "Got %p, expected %p.\n", out, &half);
+
 out = D3DXFloat16To32Array(&single, (D3DXFLOAT16 *)&half, 0);
 ok(out == &single, "Got %p, expected %p.\n", out, &single);
 
 for (i = 0; i < sizeof(testdata)/sizeof(testdata[0]); i++)
 {
+out = D3DXFloat32To16Array(&half, &testdata[i].single_in, 1);
+ok(out == &half, "Got %p, exp

Re: gcc 4.6 warning report

2011-06-29 Thread Lauri Kenttä

On Wed, 29 Jun 2011 08:31:58 +0100, David Laight wrote:

On Tue, Jun 28, 2011 at 03:18:47PM -0700, Juan Lang wrote:
>> This is a false positive. ?h_addr_list is declared as a char **, 
and
>> technically it is, but gethostbyname only returns IPv4 addresses, 
i.e.

>> ones that can fit in a DWORD.
>
> That doesn't sound like a problem that would give that warning.

Why not?  A cast of a pointer to a DWORD with 64-bit pointers would
cause truncation, if it were indeed a pointer that were being cast.
It isn't, even though it's declared that way.


But 'char **h_addr_list;' is a pointer to an array of pointers
to address buffers (defined as char) - not a pointer to an array of
addresses.
IIRC the 'something' will be an IPv4 address - which might
be held as a 32 bit quantity rather that an array of char.
But nowhere should you cast the 32bit int (DWORD) to/from a pointer 
type.


David is right, the address is not stored as a pointer but as a DWORD 
in place of the chars. Like this:


gethostbyname("winehq.org"):
wrong: (DWORD) host->h_addr_list[i] = 0x00cbd1c8 = 200.209.203.0
right: *(DWORD*) host->h_addr_list[i] = 0x86192ed1 = 209.46.25.134

--
Lauri




Re: [1/2] oleaut32: COM Cleanup ICreateTypeLib2Imp (resend)

2011-06-29 Thread Michael Stefaniuc
Hello Alistair,

sorry that I missed the first time. And Alexandre should have marked it
as PENDING (good idea but current implementation is rejected).

Alistair Leslie-Hughes wrote:
> Changelog:
>  oleaut32: COM Cleanup ICreateTypeLib2Imp
> 
> 
> Best Regards
>   Alistair Leslie-Hughes


> >From 4e5e70b84cc4a254e5e3bdfeb788282a20a3dd50 Mon Sep 17 00:00:00 2001
> From: Alistair Leslie-Hughes 
> Date: Mon, 27 Jun 2011 22:24:09 +1000
> Subject: [PATCH] COM Cleanup ICreateTypeLib2Imp
> To: wine-patches 
> 
> ---
>  dlls/oleaut32/typelib2.c |   75 -
>  1 files changed, 40 insertions(+), 35 deletions(-)
> 
> diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c
> index e9c7613..5740ddd 100644
> --- a/dlls/oleaut32/typelib2.c
> +++ b/dlls/oleaut32/typelib2.c
> @@ -1476,7 +1481,7 @@ static HRESULT ctl2_find_typeinfo_from_offset(
>  
>  for (typeinfo = This->typeinfos; typeinfo; typeinfo = 
> typeinfo->next_typeinfo) {
>   if (typeinfo->typeinfo == typeinfodata) {
> - *ppTinfo = (ITypeInfo *)&typeinfo->lpVtblTypeInfo2;
> + *ppTinfo = (ITypeInfo *)&typeinfo->ITypeInfo2_iface.lpVtbl;
Please don't cast a vtable to an iface, cast the iface instead:
+   *ppTinfo = (ITypeInfo *)&typeinfo->ITypeInfo2_iface

>   ITypeInfo2_AddRef(*ppTinfo);
>   return S_OK;
>   }
> @@ -1573,7 +1578,7 @@ static HRESULT WINAPI ICreateTypeInfo2_fnQueryInterface(
>  *ppvObject = This;
>  } else if (IsEqualIID(riid, &IID_ITypeInfo) ||
>  IsEqualIID(riid, &IID_ITypeInfo2)) {
> - *ppvObject = &This->lpVtblTypeInfo2;
> + *ppvObject = &This->ITypeInfo2_iface.lpVtbl;
No need to go here down to the vtable:
+   *ppvObject = &This->ITypeInfo2_iface
It's the exact same thing but shorter.

>  }
>  
>  if(*ppvObject)
> @@ -1697,7 +1702,7 @@ static HRESULT WINAPI 
> ICreateTypeInfo2_fnSetTypeFlags(ICreateTypeInfo2 *iface, U
>  iter->next_typeinfo = This->dual;
>  }
>  } else
> -iface = (ICreateTypeInfo2*)&This->dual->lpVtbl;
> +iface = 
> (ICreateTypeInfo2*)&This->dual->ICreateTypeInfo2_iface.lpVtbl;
There's no need for a cast here as you already have the right thing:
+iface = &This->dual->ICreateTypeInfo2_iface;

>  }
>  
>  if (uTypeFlags & (TYPEFLAG_FDISPATCHABLE|TYPEFLAG_FDUAL)) {

You missed a few changes:
@@ -3153,7 +3158,7 @@
 {
 ICreateTypeInfo2Impl *This = impl_from_ITypeInfo2(iface);

-return ICreateTypeInfo2_QueryInterface((ICreateTypeInfo2 *)This,
riid, ppv);
+return
ICreateTypeInfo2_QueryInterface(&This->ICreateTypeInfo2_iface, riid, ppv);
 }

There are more of those "(ICreateTypeInfo2 *)This" ==>
"&This->ICreateTypeInfo2_iface" changes. Check for all (ICreateTypeInfo2
*),
there should be none left.

> @@ -3388,7 +3393,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeOfImplType(
>  }
>  
>  if(This->typekind == TKIND_DISPATCH)
> -return 
> ITypeInfo2_GetRefTypeOfImplType((ITypeInfo2*)&This->dual->lpVtblTypeInfo2,
> +return 
> ITypeInfo2_GetRefTypeOfImplType((ITypeInfo2*)&This->dual->ITypeInfo2_iface.lpVtbl,
No need for the cast:
+return
ITypeInfo2_GetRefTypeOfImplType(&This->dual->ITypeInfo2_iface,

>  index, pRefType);
>  }
>  
> @@ -3599,7 +3604,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeInfo(
>  return E_INVALIDARG;
>  
>  if(hRefType==-2 && This->dual) {
> -*ppTInfo = (ITypeInfo*)&This->dual->lpVtblTypeInfo2;
> +*ppTInfo = (ITypeInfo*)&This->dual->ITypeInfo2_iface.lpVtbl;
Just cast the iface:
+*ppTInfo = (ITypeInfo*)&This->dual->ITypeInfo2_iface;

>  ITypeInfo_AddRef(*ppTInfo);
>  return S_OK;
>  }
> @@ -3635,7 +3640,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeInfo(
>  
>  for(iter=This->typelib->typeinfos; iter; iter=iter->next_typeinfo) {
>  if(This->typelib->typelib_typeinfo_offsets[i] == 
> (hRefType&(~0x3))) {
> -*ppTInfo = (ITypeInfo*)&iter->lpVtblTypeInfo2;
> +*ppTInfo = (ITypeInfo*)&iter->ITypeInfo2_iface.lpVtbl;
Same here:
+*ppTInfo = (ITypeInfo*)&iter->ITypeInfo2_iface;

>  
>  ITypeLib_AddRef(*ppTInfo);
>  return S_OK;
> @@ -4948,7 +4953,7 @@ static HRESULT WINAPI ITypeLib2_fnGetDocumentation(
>  if(!iter)
>  return TYPE_E_ELEMENTNOTFOUND;
>  
> -return ITypeInfo_GetDocumentation((ITypeInfo*)&iter->lpVtblTypeInfo2,
> +return 
> ITypeInfo_GetDocumentation((ITypeInfo*)&iter->ITypeInfo2_iface.lpVtbl,
And here:
+return
ITypeInfo_GetDocumentation((ITypeInfo*)&iter->ITypeInfo2_iface,

>  -1, pBstrName, pBstrDocString, pdwHelpContext, 
> pBstrHelpFile);
>  }
>  

thanks
bye
michael




Re: gcc 4.6 warning report

2011-06-29 Thread David Laight
On Tue, Jun 28, 2011 at 03:18:47PM -0700, Juan Lang wrote:
> >> This is a false positive. ?h_addr_list is declared as a char **, and
> >> technically it is, but gethostbyname only returns IPv4 addresses, i.e.
> >> ones that can fit in a DWORD.
> >
> > That doesn't sound like a problem that would give that warning.
> 
> Why not?  A cast of a pointer to a DWORD with 64-bit pointers would
> cause truncation, if it were indeed a pointer that were being cast.
> It isn't, even though it's declared that way.

But 'char **h_addr_list;' is a pointer to an array of pointers
to address buffers (defined as char) - not a pointer to an array of addresses.
IIRC the 'something' will be an IPv4 address - which might
be held as a 32 bit quantity rather that an array of char.
But nowhere should you cast the 32bit int (DWORD) to/from a pointer type.

David

-- 
David Laight: da...@l8s.co.uk




Re: wine bug 27600

2011-06-29 Thread wylda
> > Maybe gcc 4.4.5 is too old or i'm extremly dumb today :-/
> > 
> > Regards,
> > W.
> >

> I'm not a WINE developer, just scratching my own
> itch :)
> 
> I have the same gcc version. Well, this might be a
> legitimate issue,
> another important thing would be to see the
> ./configure output log.

Thanks for interest :) That gives me hope, i won't be out of wine
game ;)

> I've merged the patch with the include lines
> modified, so they would be
> identical to the include files mostly used in the
> other wineserver c files.
> This is just a guess, I have no idea why it
> doesn't work. There is also
> today's commit, that changed include/winternl.h:
> "ntdll: Encode the
> function pointers in the vectored handler list",
> but it's not related.
> 
> The patch is rebased against today's commits -
> http://dl.dropbox.com/u/6901628/raw.patch

Nice to have all that 9+ changes in one box. So later today i will
try to apply them on current fresh git tree and upload config.log if
any trouble. If anything else comes to your mind in next 10hours
don't hesitate to ask for, so i could report that too.

Thanks,
W.



-- 
IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na:
www.ihned.cz