May 2011 - Wine-Devel - list.winehq.org

Re: Tahoma Font License

by Maarten Lankhorst

Hi mark, 2011/5/25 Mark Page <rombust(a)hotmail.co.uk>: > > I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 > > It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) > > It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. > > Ideally I feel it should have a creative commons license > > I believe Creative commons did not exist when that font was created tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed in accordance with former's license. Please do not contact Bitstream Inc. for any reason regarding this font. So just look up the original without contacting bitstream inc. ? Cheers, Maarten

May 25, 2011

Tahoma Font License

by Mark Page

I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. Ideally I feel it should have a creative commons license I believe Creative commons did not exist when that font was created (I initially posted this message to forum.winehq.org, and it was suggested that I should post here instead) Mark.

May 25, 2011

re: [2/5] d3dx9: Generate effect instances from materials for mesh loading.

by Dan Kegel

+ static const char diffuse_paramname[] = "Diffuse"; + static const char power_paramname[] = "Power"; + static const char specular_paramname[] = "Specular"; + static const char emissive_paramname[] = "Emissive"; + static const char ambient_paramname[] = "Ambient"; + static const DWORD basic_paramname_sizes = sizeof(diffuse_paramname) + + sizeof(power_paramname) + + sizeof(specular_paramname) + + sizeof(emissive_paramname) + + sizeof(ambient_paramname); ... It might be more readable to define material_effects[] up next to where those paramnames are defined, since it kind of clutters the loop, and it's nicer to keep the whole table definition together. (Also, at least conceptually, basic_paramname_sizes could be computed by a loop over the table. Then you wouldn't need those five _paramname variables, you could just use string constants. But if the strlen's would be expensive, I guess that's ok.) A comment or two about the layout of the output buffer might be nice. Can materials and material_ptr be const pointers? - Dan

May 25, 2011

Re: [PATCH] version: mark internal function with hidden visibility

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > @@ -348,7 +348,7 @@ static BOOL find_pe_resource( HFILE lzfd, DWORD *resLen, DWORD *resOff ) > /*********************************************************************** > * find_version_resource [internal] > */ > -DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > +DECLSPEC_HIDDEN DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > { This should be in a header. It's not very useful to make it hidden if callers are not aware of the fact. -- Alexandre Julliard julliard(a)winehq.org

May 25, 2011

Re: [1/5] wined3d: Don't check the FBO status if FIXMEs are off

by Stefan Dösinger

On Tuesday 24 May 2011 22:57:34 Henri Verbeet wrote: > I'm not sure that's really worth it. If the GL lock is really such a > concern, you should probably change the calls in context.c to already > be under the GL lock anyway. You can easily change > context_apply_draw_buffers() for example to require locking by the > caller. I planned to do this on top of this patch, but it turned out to be way easier than expected. Please ignore this patch for now. The others should still apply though.

May 25, 2011

Re: usp10/tests: Make enumFontProc() static.

by 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=11170 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Michael Stefaniuc

Damn ... I have attached the wrong diff. Michael Stefaniuc wrote: > Ričardas Barkauskas wrote: >> My first try for COM cleanup. Please donėt be too harsh :) >> If this is too large for one patch, please suggest how to split it. >> >> This is not automatic clean up so I don't really expect it to be good on >> first try. > Heh! I have attached the raw diff generated by my coccinelle script. > Looking at the interdiff between the two patches it looks like you > caught everything. And the BADBADBAD() (*) from the generated patch are > replaced with unsafe_impl_from_IDirectDrawSurface3(), very good. > > If you want to do more COM cleanup I can give you the raw generated > patches to save you some time. > > bye > michael > > P.S.: (*) My script validates that impl_from_IFace() is called only from > methods of that IFace. All other impl_from_IFace() calls are replaced > with BADBADBAD().

May 25, 2011

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface

by Michael Stefaniuc

Hello Ričardas! Ričardas Barkauskas wrote: > My first try for COM cleanup. Please donėt be too harsh :) > If this is too large for one patch, please suggest how to split it. > > This is not automatic clean up so I don't really expect it to be good on > first try. Heh! I have attached the raw diff generated by my coccinelle script. Looking at the interdiff between the two patches it looks like you caught everything. And the BADBADBAD() (*) from the generated patch are replaced with unsafe_impl_from_IDirectDrawSurface3(), very good. If you want to do more COM cleanup I can give you the raw generated patches to save you some time. bye michael P.S.: (*) My script validates that impl_from_IFace() is called only from methods of that IFace. All other impl_from_IFace() calls are replaced with BADBADBAD().

May 25, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Tue, May 24, 2011 at 8:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Tuesday 24 May 2011 19:56:06 Michael Mc Donnell wrote: > >> Sorry I phrased that in a wrong way. In the UpdateSemantics function I >> call IDirect3DDevice9_CreateVertexDeclaration which allocates a new >> Vertex Declaration on the heap. > Is there an alternative? I guess you could cache existing declarations. The > d3d9 API doesn't give you an option to reuse an existing declaration. > > I doubt apps will regularly change the declaration, usually this doesn't make > sense without also changing the data. Of course that doesn't mean there isn't > a broken app out there that does this. Yeah it might not be a problem at all. I'll give it a quick second look to see if it's possible to cache things. I anyway need to read some more code too to see exactly how the APIs interact. >> I also noticed that I didn't call >> IDirect3DDevice9_SetVertexDeclaration. I've added it to stick with the >> defined locking scheme. > Locking scheme? I've just started reading into into the Mesh API, but I don't > think you're supposed to apply the declaration until the mesh is used for > drawing. Ok good, I started to doubt this last night. I'll remove it and try to get a better sense of how the API works. >> > *) In your first test you forgot to check the HeapAlloc result. >> >> Ok, I'll return E_OUTOFMEMORY in that case. > I guess the callers will only abort the tests if NewTestContext fails, so I > think the NULL / non-NULL return value was better. > >> Should I try to make some more invalid >> D3DVERTEXELEMENT9 arrays to see if I can provoke an error? > I was thinking about something that would make CreateVertexDeclaration fail, > e.g. declaring a usage+usage index twice or using an undefined type. > dlls/d3d9/vertexdeclaration.c and dlls/wined3d/vertexdeclaration.c check for a > few error conditions in their vertexdeclaration_init functions. Just pick one > of them(no need to check all of them) > But watch out that you don't open a can of worms here. Our > CreateVertexDeclaration probably doesn't catch all error conditions. I > recommend that you pick one it does catch, otherwise you'll have to fix > d3d9.dll and wined3d.dll too for a small test. Ok thanks I'll do that. >> > *) In the wined3d code(and its client libs) Henri and I avoid structure >> > typedefs. The existing d3dx9 code has a few of them. I'm ok with either >> > way, but maybe you and the other d3dx9 devs want to go the wined3d way. >> >> Sure I can change them. So just normal structs? Is it to keep the >> namespace clean? > Henri started with this change, I think keeping the namespace clean was a > consideration. What you do is up to you and the other devs working on d3dx9. > I'm only suggesting that you discuss the code style and agree on a format. > > Either way it is a fairly minor point IMO, but it tends to end up in holy war. Ok :-) I don't have any strong feelings about it, so I'll just follow your convention until somebody complains.

May 25, 2011

Re: cmd: Don't read past end of thisVar in WCMD_expand_envvar (valgrind)

by Dan Kegel

On Tue, May 24, 2011 at 10:26 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > === WNT4WSSP6 (32 bit) === > batch.c:223: Test failed: unexpected char 0x54 position 0 in line 86 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted '65536') Well, foo. Guess NT is different. I'll rework the tests sometime and resubmit. > === WXPPROSP3 (32 bit) === > batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') This one surprised me, doesn't seem to match local testing on XP.

May 25, 2011