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

Re: urlmon: Wrap heap functions.

by Michael Stefaniuc

Alexandre Julliard wrote: > Michael Stefaniuc <mstefani(a)redhat.com> writes: > >> I therefor propose to standardize all the internal HeapAlloc wrappers to >> a common name and form, Something along the lines of: >> walloc() >> wzalloc() >> wrealloc() >> wzrealloc() >> wfree() >> It's short and concise and doesn't conflict with the Win32 API. > > Standardizing them is OK, but the names aren't very good, especially > walloc looks too much like malloc. It's suggest something like > heap_alloc, heap_alloc_zero, etc. Yeah, i went for the convention used by the Linux kernel replacing 'k' with 'w'. But I don't mind how they are named as long as it is consistent. I'll do a janitorial task page for this and start sending patches. 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. 27, 2007

Re: urlmon: Wrap heap functions.

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > I therefor propose to standardize all the internal HeapAlloc wrappers to > a common name and form, Something along the lines of: > walloc() > wzalloc() > wrealloc() > wzrealloc() > wfree() > It's short and concise and doesn't conflict with the Win32 API. Standardizing them is OK, but the names aren't very good, especially walloc looks too much like malloc. It's suggest something like heap_alloc, heap_alloc_zero, etc. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007

Re: user32: Fix a couple of typos

by Alexandre Julliard

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > Changelog: > user32: Fix a couple of typos. The patch is clearly correct but it causes test failures, so it looks like more work is needed here: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so dde.c && touch dde.ok dde.c:250: Test failed: Unhandled msg: 000080c2 dde.c:243: Test failed: client failed with 1 error(s) make[2]: *** [dde.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007

Re: msvcrt heap: fix _aligned_offset_realloc (move correct block of memory); add a comment to explain why. [1/2]

by Alexandre Julliard

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > + Therefore, "size" bytes of actual data have to be moved from the offset > + they were at in the old block (temp + old_padding) to the offset they > + have to be in the new block (temp + new_padding == memblock). > +*/ > if (new_padding != old_padding) > - memmove((char *)memblock + old_padding, (char *)memblock + new_padding, size); > + memmove((char *)memblock, (char *)temp + old_padding, size); You also have to take into account the fact that the size may have changed. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007

Re: Reading Registry Example

by Alexander Nicolaysen Sørnes

On Tuesday 27 November 2007 04:28:07 James McKenzie wrote: > All: > I would like to work on the eventlog.c and would like pointers to an > example of reading a registry example under Wine. > > Thank you. > > James You can access the registry using the same functions that you would use on Windows. Our wordpad and notepad clones read/write to the registry; look in the 'programs' folder of the Wine source. Alexander N. Sørnes

Nov. 27, 2007

Re: USER32: win16 applications should not see long filenames returned from dialog control (try 4) (RESEND)

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * Win16 applications should not see long filenames. Change directory > listbox to return short names when called from the 16-bit wrappers. You are still calling GetShortPathName on potentially uninitialized data. You simply can't do this with a wrapper around the 32-bit DlgDirSelect, you have to duplicate the code. But first it would be worth checking if the listbox shouldn't rather be populated with short path names in the first place. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007

Re: David Adam : d3dx8: Implement D3DXQuaternionInverse.

by David.Adam＠math.cnrs.fr

Robert Shearman <rob(a)codeweavers.com> a Ã©critÂ : > Alexandre Julliard wrote: >> /*_________________D3DXQUATERNION________________*/ >> -D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION * >> pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION * pq2) >> +D3DXQUATERNION* WINAPI D3DXQuaternionInverse(D3DXQUATERNION *pout, >> CONST D3DXQUATERNION *pq) >> +{ >> + D3DXQUATERNION temp; >> + FLOAT norm; >> + >> + norm = D3DXQuaternionLengthSq(pq); >> + if ( !norm ) >> + { >> + pout->x = 0.0f; >> + pout->y = 0.0f; >> + pout->z = 0.0f; >> + pout->w = 0.0f; >> + } >> + else >> + { >> + D3DXQuaternionConjugate(&temp, pq); >> + pout->x = temp.x / norm; >> + pout->y = temp.y / norm; >> + pout->z = temp.z / norm; >> + pout->w = temp.w / norm; >> + } >> + return pout; >> +} >> + >> +D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION >> *pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION *pq2) >> { >> pout->x = pq2->w * pq1->x + pq2->x * pq1->w + pq2->y * pq1->z - >> pq2->z * pq1->y; >> pout->y = pq2->w * pq1->y - pq2->x * pq1->z + pq2->y * pq1->w + >> pq2->z * pq1->x; > > This change causes the following warnings for me: > math.c: In function ‘D3DXQuaternionInverse’: > math.c:695: warning: ‘temp.x’ may be used uninitialised in this function > math.c:695: warning: ‘temp.y’ may be used uninitialised in this function > math.c:695: warning: ‘temp.z’ may be used uninitialised in this function > math.c:695: warning: ‘temp.w’ may be used uninitialised in this function > > $ gcc --version > gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > I believe that this is causes by D3DXQuaternionConjugate not writing > to temp in one case (pq being NULL) and the compiler not recognising > that this case is already covered by the !norm branch above, since > D3DXQuaternionLengthSq will return 0.0f if pq is NULL. > > The attached patch works around the warning. However, there are > currently no tests for the case of pq being NULL so I don't know > whether it is correct. > > -- > Rob Shearman I have just tried with a native d3dx8 dll. Giving a null pointer to pq leads to a crash. So, the application must take care to not send such a pointer. So, I think that to avoid the warning that you see, we could just initialize the variable temp before the if condition. David

Nov. 27, 2007

Re: David Adam : d3dx8: Implement D3DXQuaternionInverse.

by Robert Shearman

Alexandre Julliard wrote: > /*_________________D3DXQUATERNION________________*/ > > -D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION * pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION * pq2) > +D3DXQUATERNION* WINAPI D3DXQuaternionInverse(D3DXQUATERNION *pout, CONST D3DXQUATERNION *pq) > +{ > + D3DXQUATERNION temp; > + FLOAT norm; > + > + norm = D3DXQuaternionLengthSq(pq); > + if ( !norm ) > + { > + pout->x = 0.0f; > + pout->y = 0.0f; > + pout->z = 0.0f; > + pout->w = 0.0f; > + } > + else > + { > + D3DXQuaternionConjugate(&temp, pq); > + pout->x = temp.x / norm; > + pout->y = temp.y / norm; > + pout->z = temp.z / norm; > + pout->w = temp.w / norm; > + } > + return pout; > +} > + > +D3DXQUATERNION* WINAPI D3DXQuaternionMultiply(D3DXQUATERNION *pout, CONST D3DXQUATERNION *pq1, CONST D3DXQUATERNION *pq2) > { > pout->x = pq2->w * pq1->x + pq2->x * pq1->w + pq2->y * pq1->z - pq2->z * pq1->y; > pout->y = pq2->w * pq1->y - pq2->x * pq1->z + pq2->y * pq1->w + pq2->z * pq1->x; This change causes the following warnings for me: math.c: In function ‘D3DXQuaternionInverse’: math.c:695: warning: ‘temp.x’ may be used uninitialised in this function math.c:695: warning: ‘temp.y’ may be used uninitialised in this function math.c:695: warning: ‘temp.z’ may be used uninitialised in this function math.c:695: warning: ‘temp.w’ may be used uninitialised in this function $ gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I believe that this is causes by D3DXQuaternionConjugate not writing to temp in one case (pq being NULL) and the compiler not recognising that this case is already covered by the !norm branch above, since D3DXQuaternionLengthSq will return 0.0f if pq is NULL. The attached patch works around the warning. However, there are currently no tests for the case of pq being NULL so I don't know whether it is correct. -- Rob Shearman diff --git a/dlls/d3dx8/math.c b/dlls/d3dx8/math.c index 04072bf..8edd1d3 100644 --- a/dlls/d3dx8/math.c +++ b/dlls/d3dx8/math.c @@ -696,7 +696,7 @@ D3DXQUATERNION* WINAPI D3DXQuaternionInverse(D3DXQUATERNION *pout, CONST D3DXQUA FLOAT norm; norm = D3DXQuaternionLengthSq(pq); - if ( !norm ) + if ( !norm || !pq ) { pout->x = 0.0f; pout->y = 0.0f;

Nov. 27, 2007

Re: [dbghelp 1/11] Update some mscvpdb.h definitions and descriptions

by Alexandre Julliard

"Jason Green" <jave27(a)gmail.com> writes: > The Original Author for the following set of patches is Eric van > Beurden from TransGaming, Inc. When submitting patches written by someone else please include a valid From: line in the patch header with his full name and email. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007

Re: [dbghelp 2/11] Return TRUE in SymInitializeW if process is already initialized and add a number of TRACEs

by Alexandre Julliard

"Jason Green" <jave27(a)gmail.com> writes: > @@ -216,11 +216,17 @@ static BOOL WINAPI process_invade_cb(PCSTR name, ULONG base, ULONG size, PVOID u > char tmp[MAX_PATH]; > HANDLE hProcess = (HANDLE)user; > > - if (!GetModuleFileNameExA(hProcess, (HMODULE)base, > - tmp, sizeof(tmp))) > + > + TRACE("found module %s {base = 0x%08x, size = 0x%08x, user = %p}\n", debugstr_a(name), base, size, user); > + > + if (!GetModuleFileNameExA(hProcess, (HMODULE)base, tmp, sizeof(tmp))){ > + WARN("could not find the full path name of the module. Using the base name of %s instead\n", debugstr_a(name)); > lstrcpynA(tmp, name, sizeof(tmp)); > + } > > + TRACE("loading the module %s {base = 0x%08x}\n", debugstr_a(name), base); > SymLoadModule(hProcess, 0, tmp, name, base, size); > + TRACE("done loading the module\n"); > return TRUE; You are adding way too many traces, most of which are not necessary. Here for instance, SymLoadModule already contains traces, so there's no need to add traces around the call. It's fine to do that sort of thing to help following things when you are trying to understand the code, but afterwards they should be removed. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2007