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

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 14:47, misha680 <misha680(a)gmail.com> wrote: > As you can see by the tests added, colors and normals have an ordering that > is specifically constrained within the FVF. > Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable. > To clarify, by saying that the booleans are redundant, do you mean to say > that, say, if I have a normal element, I should iterate back through all > declaration elements that have already been processed and check for a prior > color element, and then return D3DERR_INVALIDCALL? > No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already have a normal.

Aug. 31, 2010

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage

by Hans Leidekker

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’

Aug. 31, 2010

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does

by Hans Leidekker

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.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > 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. > > > > As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF. To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL? Again, for the case of two color elements or two normal elements, are you suggesting I do the same (iterate through all past elements)? Wouldn't, in this case, a boolean be more efficient? hasPosition I apologize does not need to be there. Just trying to clarify your points regarding your comments re booleans and specialty of colors and normals. Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXFVFFromDeclarator-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Jacek Caban

On 8/31/10 2:03 PM, Alexandre Julliard wrote: > 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. My motivation was to make headers prepared for midl to work. They usually check only if __midl is defined and that's all we can sanely do. > Also, _WIN64 can't depend on how widl was built, since it can generate > both 32-bit and 64-bit code. Right, I've sent the patch too quickly, sorry. > You'd have to parse everything twice if you wanted to make use of this. That's a matter of not using it, but if midl defines it, I think we should do it as well. I will resend the patch with _WIN32 define only. Thanks, Jacek

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Henri Verbeet

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.)

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Alexandre Julliard

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

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Nicolas Le Cam

2010/8/31 Francois Gouget <fgouget(a)free.fr> > On Tue, 31 Aug 2010, Alexandre Julliard wrote: > > > Francois Gouget <fgouget(a)free.fr> writes: > > > > > 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. > [...] > > It's an undefined reference, probably you don't have OpenAL so that code > > doesn't get compiled. > > Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if > OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 > system so there's no package providing the 32bit version :-( > > Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 > and libopenal on a 64bit Debian system? I would try apt-cross but I was > once told that using it to get 32bit libraries on 64bit system was > stupid, not meant to work, etc. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > > I don't know of a 'clean' way (and I'm also interested if anyone knows) but, at least, lib32v4l-0 is available for squeeze and sid since early june (it also seems to be in lenny-backports but from the older, now removed, libv4l source package). -- Nicolas Le Cam

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

Is the attached patch well formed ? Can someone give it a try ? I don't want to run it, I fear it'll download all tables : my 3G Internet connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one cares)

Aug. 31, 2010

Re: Chinese translation of key pages on wiki.winehq.org?

by Frédéric Delanoy

On Tue, Aug 31, 2010 at 02:40, Dan Kegel <dank(a)kegel.com> wrote: > Are there any Chinese speakers on the list? > Any interest in starting a Chinese translation of wiki.winehq.org? > > I bring this up because a Chinese user/developer is asking for help > getting started with submitting translations to Wine. I think he would find > Chinese versions of > http://wiki.winehq.org/SubmittingPatches > and perhaps even > http://wiki.winehq.org/Translating > helpful. > > It seems strange for a translator to need help reading English > documents, but perhaps it would help them come up the curve > faster. Well maybe it's because (some of) these pages are not clear enough for non-techies. Maybe he could tell what parts he didn't understand so the wiki pages can be improved (it would help for other languages, too). Rgds, Frédéric

Aug. 31, 2010