January 2009 - Wine-devel - list.winehq.org

Re: Testing DIB Engine (second part)
by Jeff Zaroyko 05 Jan '09

05 Jan '09

On Wed, Dec 24, 2008 at 11:23 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Here the second part, it contains winedib.drv code and changes to Makefiles. > > Still no way to enable/disable the engine, besides of deleting the .so > inside dlls/winedib.drv. > > I'll wait for some feedback before going fourther. > > Ciao > > Max > Instead of deleting it, you could simply set winedib.drv to disabled in winecfg? -Jeff

4 5

Re: [1/2] sfc: Export by ordinal and add missing exports.
by Alexandre Julliard 05 Jan '09

05 Jan '09

Hans Leidekker <hans(a)codeweavers.com> writes: > SfcIsKeyProtected is not exported from my copy of sfc.dll. I think > it was added by mistake in commit 7dbe9a6728064172a9d9edac484f90c421156785. It's exported on Vista. Also please don't make up names for ordinal functions, use anonymous entry points ('@') until we find out the real name. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: dlls/dinput/effect_linuxinput.c: Check return value of 'write'. (bug # 16413)
by Dan Kegel 05 Jan '09

05 Jan '09

Vitaliy Margolen wrote: >> titon barua wrote: >>> - write(*(This->fd), &event, sizeof(event)); >>> + if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL ); >> What's the point of your patch? What part of the comment isn't clear to you? > >GCC is complaining about the ignored return value. As Alexandre implied in http://www.winehq.org/pipermail/wine-devel/2009-January/071769.html one should not fix these warnings casually. A real fix probably involves actually handing the error rather than printing a warning. The last thing we need is an army of people papering over compiler warnings. - Dan

2 2

Re: widl: Also arrays need NULL pointer checks.
by Alexandre Julliard 05 Jan '09

05 Jan '09

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > This is still not complete. No NULL pointer checks are emitted for parameters > that are aliases to pointers or arrays. This adds checks in places where midl doesn't have them. It breaks the service tests for instance. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/dinput/effect_linuxinput.c: Check return value of 'write'. (bug # 16413)
by Vitaliy Margolen 05 Jan '09

05 Jan '09

titon barua wrote: > --- > /* we don't care about the success or failure of this call */ > - write(*(This->fd), &event, sizeof(event)); > + /* print errors if they occur */ > + if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL ); What's the point of your patch? What part of the comment isn't clear to you? Also don't use perror. Wine has ERR(), WARN(), TRACE() macros for that. Vitaliy

6 6

Re: widl: Make to interfaces RPC_FC_OP instead of RPC_FC_RP
by Rob Shearman 05 Jan '09

05 Jan '09

2009/1/4 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de>: > This eliminates the wrong null pointer check for pointers to interfaces. This isn't correct. Object pointers are generated, I believe, in the case where we have an [in, out] unique pointer, since if the pointer has been set to NULL the previous memory needs to be freed (on the client side). The correct fix for the problem you see is to implement (yet another) check in cant_be_null. -- Rob Shearman

1 0

Re: widl: use base pointer type instead of default if not overwritten.
by Rob Shearman 05 Jan '09

05 Jan '09

2009/1/4 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de>: > diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c > index f0e3f1d..0e5cbaf 100644 > --- a/tools/widl/proxy.c > +++ b/tools/widl/proxy.c > @@ -185,6 +185,11 @@ int needs_null_check(const var_t *v) > > if (type) > { > + if (type->type == RPC_FC_FP || > + type->type == RPC_FC_OP || > + type->type == RPC_FC_UP) > + return 0; > + > attrs = type->attrs; > type = type->ref; > } Looks good, although we should always use the type set in the type object, rather than trying to guess from the attributes. I plan to clean this up in the near future so you don't need to change the patch unless you want to. -- Rob Shearman

1 0

MaxVertexBlendMatrices, multi-matrix vertex blending and D3DX
by Paul TBBle Hampson 05 Jan '09

05 Jan '09

This is a bit of an old topic, but it relates to two active bugs, 8357 (affecting Everquest) and 14608 (affecting Warhammer Online) The rough summary of the situation is that these two games use d3dx9_30 and d3dx9_34 respectively, and at least the former uses ConvertToIndexedBlendedMesh. Anyway, they both show an odd behaviour where if the device caps report MaxVertexBlendMatrices <= 2 (or <2 maybe) then the d3dx apparently generates odd behaviour and unrecognised vertex entries, the upshot being that the character's vertices all end up on the ground at the model's world transform. If MaxVertexBlendMatrices is > 2 then the vertices come out fine, and everything seems to work. A d3d trace from Warhammer Online indicates that D3DRS_VERTEXBLEND is only ever set to 0 (only tested up to the character select screen, which is the first screen where the bug is visible) both with and without the patch. >From what I understand from here and on MSDN, indexed multimatrix blending in the fixed function pipeline is generally emulated except on certain older ATI Radeon cards, so I guess that D3DX ConvertToIndexedBlended actually ends up emulating the index blending without actually using the D3DRS_VERTEXBLEND renderstates. The current workaround is to patch Wine to report MaxVertexBlendMatrices 4, but that will cause bad behaviour in programs that do use the multimatrix vertex blending, as I understand. Anyway, what I'm wondering is would it be worth throwing together a patch that implements the multimatrix blending in drawStridedSlow for cards that don't support ARB_VERTEX_BLEND (ie all of them under Linux) If this is sensible, any pointers towards the right thing to do would be greatly appreciated, this isn't an area I'm massively experienced in. The only other option I'm aware of is to await the shader-based fixed function pipeline replacement which might contain an implementation of the D3DRS_VERTEXBLEND renderstates. The last time I'm aware of this being discussed was [1], in February last year. [1] http://www.winehq.org/pipermail/wine-devel/2008-February/062433.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

2 1

Re: dlls/dinput/effect_linuxinput.c: Check return value of 'write'. (bug # 16413)
by Vitaliy 04 Jan '09

04 Jan '09

titon barua wrote: > --- > /* we don't care about the success or failure of this call */ > - write(*(This->fd), &event, sizeof(event)); > + /* print errors if they occur */ > + if (write(*(This->fd), &event, sizeof(event)) == -1) perror ( NULL ); What's the point of your patch? What part of the comment isn't clear to you? Also don't use perror. Wine has ERR(), WARN(), TRACE() macros for that. Vitaliy

1 0

re: Patch implementing riched20 : EM_PASTESPECIAL -- critique?
by Dan Kegel 04 Jan '09

04 Jan '09

Hi, and welcome to Wine development! Two notes on your patch: 1) does treating CF_TEXT as a CF_UNICODETEXT work? 2) you don't include a conformance test. Conformance tests are really, really helpful. I bet you could write one for this feature. Please give it a shot, and make sure the test passes on Windows. - Dan

2 1