August 2010 - Wine-devel - list.winehq.org

Re: d3dx9: Implement D3DXFVFFromDeclarator.
by Henri Verbeet 31 Aug '10

31 Aug '10

On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: > Looking forward to (constructive) comments. > Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.

3 6

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.
by testbot＠testbot.winehq.org 31 Aug '10

31 Aug '10

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=4872 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

2 1

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx
by Henri Verbeet 31 Aug '10

31 Aug '10

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability. (Yeah, this is a mostly unchanged copy of my earlier comments.)

2 1

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs
by Alexandre Julliard 31 Aug '10

31 Aug '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > /*********************************************************************** > + * WS2_async_recv_accept (INTERNAL) > + * > + * This function is used to finish the read part of an accept request. It is > + * needed to place the completion on the correct socket (listener). > + */ > +static NTSTATUS WINAPI WS2_async_recv_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ > + void *junk; > + struct ws2_accept_async *wsa = arg; > + > + status = WS2_async_recv( wsa->read, iosb, status, &junk ); > + if (status == STATUS_PENDING) > + return status; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} > + > +/*********************************************************************** > + * WS2_async_accept (INTERNAL) > + * > + * This is the function called to satisfy the AcceptEx callback > + */ > +static NTSTATUS WINAPI WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ These are not valid async callbacks, the way async callbacks work has changed since the patch was first written. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use
by Henri Verbeet 31 Aug '10

31 Aug '10

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote: > + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); ... > - stream_sizes->cbHeader = 5; > - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbHeader = ctx->header_bytes; > + stream_sizes->cbTrailer = ctx->trailer_bytes; Does this imply TLS record padding should be disabled? I imagine an encrypted message may not fit in the application provided buffers otherwise.

2 1

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage
by Hans Leidekker 31 Aug '10

31 Aug '10

On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote: > + SIZE_T expected_size; > ssize_t received = 0; > ssize_t ret; > int idx; > - char *buf_ptr; > + unsigned char *buf_ptr; > unsigned int offset; > > TRACE("context_handle %p, message %p, message_seq_no %d, quality %p\n", > @@ -1230,12 +1243,22 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if (idx == -1) > return SEC_E_INVALID_TOKEN; > buffer = &message->pBuffers[idx]; > + buf_ptr = (unsigned char *)buffer->pvBuffer; > + > + expected_size = 5 + ((buf_ptr[3] << 8) | buf_ptr[4]); > + if(buffer->cbBuffer < expected_size) > + { > + TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } This produces a compiler warning here: schannel.c: In function ‘schan_DecryptMessage’: schannel.c:1251: warning: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘SIZE_T’

1 0

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does
by Hans Leidekker 31 Aug '10

31 Aug '10

On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote: > - memcpy(buffer->pvBuffer, data, received); > - buffer->cbBuffer = received; > + buf_ptr = (char *)buffer->pvBuffer; You don't need this cast. > + offset = ctx->header_bytes; > + memcpy(buf_ptr + offset, data, received); > HeapFree(GetProcessHeap(), 0, data); > > + schan_decrypt_fill_buffer(message, SECBUFFER_DATA, buf_ptr + offset, received); > + offset += received; > + > + schan_decrypt_fill_buffer(message, SECBUFFER_STREAM_TRAILER, buf_ptr + offset, buffer->cbBuffer - offset); > + offset += ctx->trailer_bytes; > + > + if(buffer->cbBuffer > offset) > + schan_decrypt_fill_buffer(message, SECBUFFER_EXTRA, buf_ptr + offset, buffer->cbBuffer - offset); > + > + buffer->BufferType = SECBUFFER_STREAM_HEADER; > + buffer->cbBuffer = ctx->header_bytes; > + FWIW, this patch set passes my tests.

1 0

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.
by Alexandre Julliard 31 Aug '10

31 Aug '10

Jacek Caban <jacek(a)codeweavers.com> writes: > They are defined by default by midl. __midl is supposed to be set to the midl compiler version, and I'm not entirely convinced it's appropriate for us to define it. Also, _WIN64 can't depend on how widl was built, since it can generate both 32-bit and 64-bit code. You'd have to parse everything twice if you wanted to make use of this. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.
by Francois Gouget 31 Aug '10

31 Aug '10

http://source.winehq.org/patches/data/65442 According to http://source.winehq.org/patches/ this patch causes a build error (or maybe a new warning). However here (gcc 4.4) I see no warning at all. Does this patch cause warnings / errors for anyone? (it would be nice if the patches website could include the build error log<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

3 3

Re: wined3d: separate driver info from GPU info (try3)
by Henri Verbeet 31 Aug '10

31 Aug '10

On 31 August 2010 00:46, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > In the previous version of this patch, no version info was returned > for Windows versions which were not in the table. I verified on > Vista/Win7 what version numbers, gpu names and driver strings are > returned to applications running in 9x/2k/xp compatibility mode. It > appears that by default (perhaps the shim database can override it?) > these applications receive information about the current drivers > instead of fake information. For now I'm returning XP driver info if > no match was found. > > Future patches will add the 9x/Vista/Win7 info. When we reach that > stage and a user uses a Geforce 8800 and winver=win98, it will behave > the same as Windows (I assume XP is the default version number). > No. This will simply break currently working functionality. Regardless, I think it's a design flaw anyway to require separate entries for different Windows versions even though they're using the same driver model.

1 0