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

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

by Robert Kim App and Facebook Marketing

"my 3G Internet > connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one > cares) > " HAHA!!! Don't you have a starbucks near by??? They do free wifi now! On Tue, Aug 31, 2010 at 3:58 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > 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) > > > > -- Robert Q Kim 2611 S Coast Highway San Diego, CA 92007 310 598 1606 My Latest Blog Post: http://sparkah.com/2010/07/29/experienced-iphone-app-developer-los-angeles-… http://sparkah.com/2010/08/25/facebook-marketing-strategies-from-nyc-and-lo…

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:48, misha680 <misha680(a)gmail.com> wrote: > D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per > include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 > it is last, I assume it would also come last? > The LASTBETA FVF flags don't add elements themselves, they modify the D3DFVF_XYZBn ones. See also D3DXDeclaratorFromFVF() for reference.

Aug. 31, 2010

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.

by Francois Gouget

On Tue, 31 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4872 [...] > === W98SE (32 bit process) === > Failure running script in VM: Exceeded timeout limit of 315 sec This is strange. Testbot says the process timed out yet the full log has the expected summary line listing the tests that were run as well as the 'process done' line so it looks like the test completed: > process: 320 tests executed (0 marked as todo, 0 failures), 5 skipped. > kernel32:process done (0) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >>> 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. >> Thank you. I was not aware of these constraints. >> >> Is there, by any chance, a good place for this? I have been checking >> the MSDN docs so far: >> http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx >> but at least upon my initial reads did not notice any such guidelines. >> > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | > D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific > vertex buffer layout, if you translate a declaration to that, it > should better describe that exact same layout.) > Thank you. I had to check a reference but I think I understand now. http://www.xmission.com/~legalize/book/download/05-Modeling.pdf pg. 168 "The vertex components are laid out in memory in the same order as the vertex components listed in the table, starting with the position component. #define D3DFVF_XYZ 0x002 #define D3DFVF_XYZRHW 0x004 #define D3DFVF_XYZB1 0x006 #define D3DFVF_XYZB2 0x008 #define D3DFVF_XYZB3 0x00a #define D3DFVF_XYZB4 0x00c #define D3DFVF_XYZB5 0x00e #define D3DFVF_NORMAL 0x010 #define D3DFVF_PSIZE 0x020 #define D3DFVF_DIFFUSE 0x040 #define D3DFVF_SPECULAR 0x080 #define D3DFVF_TEX0 0x000 #define D3DFVF_TEX1 0x100 #define D3DFVF_TEX2 0x200 #define D3DFVF_TEX3 0x300 #define D3DFVF_TEX4 0x400 #define D3DFVF_TEX5 0x500 #define D3DFVF_TEX6 0x600 #define D3DFVF_TEX7 0x700 #define D3DFVF_TEX8 0x800 #define D3DFVF_LASTBETA_UBYTE4 0x1000 Every FVF must include a position with one of the D3DFVF XYZ, D3DFVF - XYZRHW, D3DFVF XYZB1, D3DFVF XYZB2, D3DFVF XYZB3, D3DFVF XYZB4, or D3D- FVF XYZB5. The remaining FVF flags are all optional." D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 it is last, I assume it would also come last? 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: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >> 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. > Thank you. I was not aware of these constraints. > > Is there, by any chance, a good place for this? I have been checking > the MSDN docs so far: > http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx > but at least upon my initial reads did not notice any such guidelines. > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific vertex buffer layout, if you translate a declaration to that, it should better describe that exact same layout.)

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Misha Koshelev

On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 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. Thank you. I was not aware of these constraints. Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines. > >> 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. That is a great idea! I honestly did not think of that at all. Thank you for the wonderful hint. Misha

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Owen Rudge

Hi Henri, > Probably depends on the device supporting NPOT textures again. The capabilities are checked in the D3DXCheckTextureRequirements function, and the values adjusted if necessary. > (Yeah, this is a mostly unchanged copy of my earlier comments.) My apologies, I somehow missed the previous e-mail at the time. (I do see it now.) Thanks for your feedback, -- Owen Rudge http://www.owenrudge.net/

Aug. 31, 2010

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs

by Alexandre Julliard

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

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Mikko Rasa

On 31.08.2010 16:16, Henri Verbeet wrote: > 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. That was originally so I could determine the end of the message and fill a SECBUFFER_EXTRA buffer if there's any leftover data (probably because the input buffer contained part of the next message). However, since I had to do my own TLS frame decoding anyway in a later patch, I don't really need to know the MAC size anymore. I'll produce a revised patchset shortly, taking into account Hans's feedback as well. -- Mikko

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Henri Verbeet

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.

Aug. 31, 2010