November 2007 - Wine-Devel - list.winehq.org

Re: d3dx9__xx dlls

by Michael Stefaniuc

Maarten Lankhorst wrote: > Stefan Dösinger schreef: >> What do we do if there's a d3dx9_37.dll next month? >> > One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a > forward dll for the old one. Renames are "cheap" in git and we do not loose the history. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Nov. 28, 2007

Re: d3dx9__xx dlls

by Maarten Lankhorst

Hello Stefan, Stefan Dösinger schreef: > What do we do if there's a d3dx9_37.dll next month? > One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a forward dll for the old one. Cheers, Maarten

Nov. 28, 2007

Re: d3dx9__xx dlls

by Stefan Dösinger

Am Mittwoch, 28. November 2007 18:14:21 schrieb David.Adam(a)math.cnrs.fr: > Following Alexandre (and I agree with him :D ), one only needs to > export the functions of d3dx9_36 (the latest one) to the older > d3dx9_xx dlls. > So, we just just need to implement the functions in the d3dx9_36 dll > repertory. > No wine_d3dx9 is useful. What do we do if there's a d3dx9_37.dll next month?

Nov. 28, 2007

d3dx9__xx dlls

by David.Adam＠math.cnrs.fr

Following Alexandre (and I agree with him :D ), one only needs to export the functions of d3dx9_36 (the latest one) to the older d3dx9_xx dlls. So, we just just need to implement the functions in the d3dx9_36 dll repertory. No wine_d3dx9 is useful. David

Nov. 28, 2007

Re: [try2 1/1] msi/tests: automation: Fix pointer check before calling lstrcpyW.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > The previous patch was last week I think. This fixes a Valgrind error in the test. This is > correct as vtResult is just hte _expected_ return type, and this way we check the actual return type > (new this version) and then the validity of the pointer (same as old patch) before calling lstrcpyW > so we don't pass NULL to lstrcpyW. It seems to me what you really want to do is check that the call succeeded, instead of relying on the variant being cleared on error. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2007

Re: [PATCH] svchost: Implementation of svchost (revised submission 2)

by Alexandre Julliard

Roy Shea <roy(a)cs.hmc.edu> writes: > This is another revised and standalone version of the svchost patch. > Changes in this revision include: > > - Only using HEAP_ZERO_MEMORY in calls to HeapReAlloc. Calls to > HeapAlloc explicitly set the NULL terminator when required. The realloc is overkill too, you can just allocate one extra char from the start, and set it to zero unconditionally. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2007

Re: ole32: Fix two comments in ok strings in the WdtpInterfacePointer tests.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > diff --git a/dlls/ole32/tests/usrmarshal.c b/dlls/ole32/tests/usrmarshal.c > index 9959f74..5819ec1 100644 > --- a/dlls/ole32/tests/usrmarshal.c > +++ b/dlls/ole32/tests/usrmarshal.c > @@ -801,9 +801,9 @@ static void test_marshal_WdtpInterfacePointer(void) > wireip = buffer; > if (size >= 28) > { > - ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x4c instead of 0x%08x\n", *(DWORD *)wireip); > + ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x44 instead of 0x%08x\n", *(DWORD *)wireip); > wireip += sizeof(DWORD); > - ok(*(DWORD *)wireip == 0x44, "wireip + 0x8 should be 0x4c instead of 0x%08x\n", *(DWORD *)wireip); > + ok(*(DWORD *)wireip == 0x44, "wireip + 0x8 should be 0x44 instead of 0x%08x\n", *(DWORD *)wireip); While we are on the subject, why does it say wireip + 0x8 when the pointer is incremented by 4? The rest of the offsets are wrong too, especially the iid comparison. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2007

Re: d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by Stefan Dösinger

Am Mittwoch, 28. November 2007 09:17:04 schrieb tony.wasserka(a)freenet.de: > Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to > choose from.. Perhaps It'd be better if we create a new dll (or at least > directory) called d3dx9 were we implement all d3dx9 stuff and let the other > d3dx9_xx dlls just call these functions? This would improve the clarity of > the code structure, so that people that don't follow this discussion can > also understand what we're doing ;-) Yes, I think this is a good idea. It wouldn't be a wined3dx which is shared among d3dx8 and d3dx9, but it would just be a central place for the common code in d3dx9_xx.dll, which will be a big majority of the code I guess.

Nov. 28, 2007

Re: [1/8] WineD3D: Inform the texture about filtering changes

by Stefan Dösinger

Am Mittwoch, 28. November 2007 09:40:29 schrieb H. Verbeet: > On 27/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Don't you need to mark the sampler dirty if it's bound somewhere? Or > is it guaranteed it never is at that point? This is done by the CTXUSAGE_BLIT setup

Nov. 28, 2007

Re: [1/8] WineD3D: Inform the texture about filtering changes

by H. Verbeet

On 27/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Don't you need to mark the sampler dirty if it's bound somewhere? Or is it guaranteed it never is at that point?

Nov. 28, 2007