Hi Detlef,
> When reading the log in the bug, the WSAAsyncGetHostByName16 is the
> indicator for an 16bit app.
Right you are. I ignored that, but clearly I was mistaken.
> Attached is my diff from last year for that code.
The changes you made to getsockopt16 and setsockopt16 look correct.
The
On Do, 2009-08-20 at 18:22 +0200, Alexandre Julliard wrote:
> Juan Lang writes:
>
> >> There can be several other ways to handle this, it needs test cases to
> >> determine which way Windows is using.
> >
> > Sorry for my lack of imagination: could you suggest at least one
> > other way so I can
On Do, 2009-08-20 at 17:58 +0200, Alexandre Julliard wrote:
> Juan Lang writes:
>
> > @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> > TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
> >s, level, optname, optval, *optlen);
> >
> > +/*
Juan Lang writes:
>> There can be several other ways to handle this, it needs test cases to
>> determine which way Windows is using.
>
> Sorry for my lack of imagination: could you suggest at least one
> other way so I can make sure the tests are representative?
It may check for just 0x
> There can be several other ways to handle this, it needs test cases to
> determine which way Windows is using.
Sorry for my lack of imagination: could you suggest at least one
other way so I can make sure the tests are representative?
Thanks,
--Juan
Juan Lang writes:
> @@ -1779,6 +1779,8 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> TRACE("socket: %04lx, level 0x%x, name 0x%x, ptr %p, len %d\n",
>s, level, optname, optval, *optlen);
>
> +/* Some apps sign-extend the level, so mask off the higher-order bits */
> +
