re: oleaut32: Add tmarshal conformance test

2006-10-07 Thread Dan Kegel
James wrote: On 10/6/06, Michal Okresa wrote: --- dlls/oleaut32/tests/tmarshal.c | 1099 dlls/oleaut32/tests/tmarshal.idl | 159 + dlls/oleaut32/tests/tmarshal.rc| 30 + dlls/oleaut32/tests/tmarshal_dispids.h | 34 + 4 files chang

Re: dsound.dll, dlls/dsound/mixer.c -- DSOUND_MixerVol() optimization

2006-10-07 Thread Vijay Kiran Kamuju
Hi, using MMX/SSE2 means it would be platform/architecture specific code. we should be platform independent as possible. Thank, VJ On 10/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I was reading through dlls/dsound/mixer.c and I came across the function DSOUND_MixerVol() that really sto

Re: [D3D9] fix for SetFVF memleak [2nd try+patch]

2006-10-07 Thread Ivan Gyurdiev
Ivan Gyurdiev wrote: Karsten Elfenbein wrote: * don't prevent IUnknown_Release of pDecl in the exit section and fix for http://bugs.winehq.org/show_bug.cgi?id=5656 This seems wrong, d3d9 does not keep an internal reference of the vdecl. Try the attached patch instead, let me know if it works

Re: [D3D9] fix for SetFVF memleak [2nd try+patch]

2006-10-07 Thread Ivan Gyurdiev
Karsten Elfenbein wrote: * don't prevent IUnknown_Release of pDecl in the exit section and fix for http://bugs.winehq.org/show_bug.cgi?id=5656 This seems wrong, d3d9 does not keep an internal reference of the vdecl. Try the attached patch instead, let me know if it works... --- dlls/d3d9/d3

Re: [D3D9] fix for SetFVF memleak [2nd try+patch]

2006-10-07 Thread H. Verbeet
On 07/10/06, Karsten Elfenbein <[EMAIL PROTECTED]> wrote: * don't prevent IUnknown_Release of pDecl in the exit section and fix for http://bugs.winehq.org/show_bug.cgi?id=5656 As mentioned on IRC, this can't work. Releasing the declaration there will cause it to be destroyed and break GetVertex

dsound.dll, dlls/dsound/mixer.c -- DSOUND_MixerVol() optimization

2006-10-07 Thread baggett . patrick
I was reading through dlls/dsound/mixer.c and I came across the function DSOUND_MixerVol() that really stood out. The purpose of the code it to apply a volume amplification by multiplying the channel data by the amplification factor. What *really* struck me was the parallelism that could be achieve

Re: ListView_InsertColumn() question {revised]

2006-10-07 Thread Andrew Talbot
Dmitry Timoshkov wrote: > I really can't type today. > I'm glad I'm not the only one. :)) -- A.

Re: ListView_InsertColumn() question [revised]

2006-10-07 Thread Andrew Talbot
Dmitry Timoshkov wrote: > > Sorry for the ambiguous answer, I missed "not" in "am I not", and it > slightly confused me, leading to an inversed logic in thinking. > I should have made the question less verbose. :) I think we are agreeing that LVCOLUMN * const pcol; is the correct equival

Re: ListView_InsertColumn() question {revised]

2006-10-07 Thread Dmitry Timoshkov
I really can't type today. "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: LVCOLUMN * const pcol; This one is an equivalent of 'LPLVCOLUMN pcol'; s/'LPLVCOLUMN pcol'/'const LPLVCOLUMN pcol' -- Dmitry.

Re: ListView_InsertColumn() question {revised]

2006-10-07 Thread Dmitry Timoshkov
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: "Andrew Talbot" <[EMAIL PROTECTED]> wrote: Given (for a type T) that const T * and T const * are equivalent, and given the right-to-left nature of pointer declarations, am I not right in thinking that const LPLVCOLUMN pcol is really equivalent to:

Re: ListView_InsertColumn() question {revised]

2006-10-07 Thread Dmitry Timoshkov
"Andrew Talbot" <[EMAIL PROTECTED]> wrote: Given (for a type T) that const T * and T const * are equivalent, and given the right-to-left nature of pointer declarations, am I not right in thinking that const LPLVCOLUMN pcol is really equivalent to: LVCOLUMN * const pcol; not const LVCOLU

Re: include: Safely discard the const qualifier using the discard_const macro

2006-10-07 Thread Hans Leidekker
On Saturday 07 October 2006 12:03, Andrew Talbot wrote: > The problem with that is that sometimes these functions are called with > writeable strings, and the return value is used to modify the original Yes, that's why I suggested making a copy or writing a local wrapper that removes the constnes

Re: SHELL32: fix product version

2006-10-07 Thread Vitaly Lipatov
В сообщении от 4 октября 2006 20:19 Vitaly Lipatov написал(a): > I discover there is missed correct Product Version for shell32.dll Anybody can check it? > Changelog: > - set ProductVersion for shell32.dll > - fix rule in Makefile for version.rc -- Lav Виталий Липатов Россия, Санкт-Петербург.

Re: include: Safely discard the const qualifier using the discard_const macro

2006-10-07 Thread Andrew Talbot
Hans Leidekker wrote: > An alternative would be to make the return value const. The problem with that is that sometimes these functions are called with writeable strings, and the return value is used to modify the original string, something like: static WCHAR stringW = {'s','t','r','i','n','

Re: shdocvw [3/3]: Add a stub implementation of the IOleCache interface

2006-10-07 Thread Jacek Caban
Hi James, James Hawkins wrote: > Hi, > > Changelog: > * Add a stub implementation of the IOleCache interface. > It's the same situation as in your patch for IRunnableObject. WebBrowser shouldn't implement IOleCache interface. Thanks, Jacek

Re: shdocvw [2/3]: Add a stub implementation of the IRunnableObject interface

2006-10-07 Thread Jacek Caban
Hi James, James Hawkins wrote: > Hi, > > Changelog: > * Add a stub implementation of the IRunnableObject interface. WebBrowser doesn't implement this interface (there is even test which shows that). The bug you try to fix is in OleCreate. OleCreate shouldn't fail if created object doesn't impleme

Re: recent ole32/shdocvw "regression" crashes adobe installers

2006-10-07 Thread Jacek Caban
Hi James, James Hawkins wrote: > Making PersistStorage_InitNew > return S_OK fixes the problem, but I don't know if that is acceptable > or not. The real solution is to implement PersistStorage. What are > people's thoughts on this? Is it OK to return S_OK for now? Yes, it is OK to return S_OK.

Re: include: Safely discard the const qualifier using the discard_const macro

2006-10-07 Thread Hans Leidekker
On Saturday 07 October 2006 10:27, Andrew Talbot wrote: > I think this sort of double casting is the way to go. I would just mention An alternative would be to make the return value const. Although these functions are wide character equivalents of POSIX functions they are Wine internal functions,

Re: include: Safely discard the const qualifier using the discard_const macro

2006-10-07 Thread Andrew Talbot
James Hawkins wrote: > Hi, > > This patch is based on a patch written by Stefan Huehner in 2005. > With the -Wcast-qual warning turned on, these five wine-internal > unicode functions produce over 1400 warnings: > > strchrW, strrchrW, strpbrkW, memchrW, memrchrW > > This patch gets rid of those