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

Re: ole32: Add tests for WdtpInterfacePointer_* functions.

by Juan Lang

Hi Rob, + ok(*(DWORD *)wireip == 0x44, "wireip + 0x0 should be 0x4c 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); Shouldn't these be "should be 0x44 instead of..."? --Juan

Nov. 26, 2007

Re: [PATCH 3/3] advapi32: Add support for using the Mac Keychain services as a backend for the credential functions instead of the registry.

by Robert Shearman

Juan Lang wrote: > Hi Rob, > > @@ -232,6 +239,198 @@ static DWORD registry_read_credential(HKEY hkey, > PCREDENTIALW credential, > return ret; > } > > +static DWORD mac_read_credential_from_item(SecKeychainItemRef item, > BOOL require_password, > + PCREDENTIALW credential, > char *buffer, > + DWORD *len) > > You're missing compilation protection here (and elsewhere) on non-Apple systems. > Ah, yes. Thanks! -- Rob Shearman

Nov. 26, 2007

Re: [PATCH 3/3] advapi32: Add support for using the Mac Keychain services as a backend for the credential functions instead of the registry.

by Juan Lang

Hi Rob, @@ -232,6 +239,198 @@ static DWORD registry_read_credential(HKEY hkey, PCREDENTIALW credential, return ret; } +static DWORD mac_read_credential_from_item(SecKeychainItemRef item, BOOL require_password, + PCREDENTIALW credential, char *buffer, + DWORD *len) You're missing compilation protection here (and elsewhere) on non-Apple systems. --Juan

Nov. 26, 2007

Re: 1.0 bugs

by Dan Kegel

On Nov 25, 2007 10:10 PM, Dan Kegel <dank(a)kegel.com> wrote: > So far, 82 bugs have been nominated to be fixed for 1.0. Forgot to mention: http://wiki.winehq.org/WineReleaseCriteria has a handy link to a bugzilla query that shows the list of 1.0 bugs.

Nov. 26, 2007

Re: [keyboard] GetAsyncKeyState: request for fixing #5623

by Stefan Dösinger

Am Montag, 26. November 2007 12:17:07 schrieb Rafał Miłecki: > 2007/11/7, Rafał Miłecki <zajec5polish(a)gmail.com>: > > Bug is quite well decribed in: > > http://bugs.winehq.org/show_bug.cgi?id=5623 but if you don't > > understand this, I can try to explain more detailed. > > > > So my request is someone try to fix this bug. Anyone have a free > > moment for this, please? > > Really, not a chance for fixing this? I know you are busy, have own > life, efc. but... maybe? Anyone, please? The usual way for that is either to offer payment to someone to fix it, or fix it yourself. Offering bug bounties was tried in the past, but I don't know how well they worked. The issue is that usually affordable bounties are not comparable to usual salaries and the issues involved with handling the bounty and reading into the code. $100 for a bug bounty is quite a lot already, but at codeweavers we have some estimation that fixing a minor bug costs about $1000 to $1500 to fix(http://www.codeweavers.com/services/engagements/) . So the most efficient way to get a bug fixed is to read into the code yourself. The bottom line is that while a free software project may be freely downloadable, but it is not a place where one can expect service for free.

Nov. 26, 2007

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW

by Stefan Dösinger

Am Montag, 26. November 2007 11:37:28 schrieb luis.busquets(a)ilidium.com: > --- > dlls/d3dx8/d3dx8_main.c | 22 ++++++++++++++++------ > include/d3dx8core.h | 4 ++-- > 2 files changed, 18 insertions(+), 8 deletions(-) Please watch out with indentions. You are mixing tabs and spaces in D3DXAssembleShaderFromFileA, so the code looks a bit dissorted here.

Nov. 26, 2007

Re: Re: urlmon: Wrap heap functions.

by Lionel Debroux

Hi, > In Wine HeapAlloc gets wrapped in different places, each using a > different name and even a different naming convention. This makes the > code harder to understand for people that browse the code (people doing > janitorial work) as they have to check every time if the function is yet > another wrapper around HeapFree or if the function is doing more than > that. And this makes it even harder for static code analyzing tools. I second Michael on that. A number of spurious entries previously in his list of potential issues detected by Smatch ( http://people.redhat.com/mstefani/wine/smatch/bugs_all.html ) were due to the wrappers around HeapFree that the script wasn't yet aware of. Currently, the list of functions that allocate memory, in the unfree_wine script, contains 33 entries. The list of functions that free memory contains 34 entries. > I therefore 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. I like that solution. Bye, Lionel. ____________________________________________________________________________________________ Yahoo! Mail innove : interface hyper pratique, messenger intégré, couleurs - http://mail.yahoo.fr

Nov. 26, 2007

Re: widl [1/7]: Output working exception handling macros. [take 2]

by Alexandre Julliard

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This is essentially the same as the last attempt but doesn't add a wine- > internal function to kernel32. It just puts the code directly in the > widl-generated exception handler. An alternative is to handle these access- > based page faults for which we can continue in the signal handler (signal_i386, > etc., in ntdll) so they never actually result in an exception being raised. > I'm not sure if anything depends on the current behavior and didn't want to > mess much more with the exception handling code than I had to. You shouldn't have to do anything of the kind, there's no reason that the generated code has to duplicate the unhandled exception filter. What you have to do is to filter properly and not catch exceptions you are not interested in. For cases where Windows would catch the access violation exception, then the unhandled filter won't be called on Windows either, that's the way it's supposed to work. -- Alexandre Julliard julliard(a)winehq.org

Nov. 26, 2007

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW

by Dmitry Timoshkov

<luis.busquets(a)ilidium.com> wrote: > + LPWSTR pSrcFileW = NULL; > + DWORD len; > + HRESULT ret; > + if (pSrcFile) > + { > + len = MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, NULL, 0 ); > + pSrcFileW = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); > + MultiByteToWideChar( CP_ACP, 0, pSrcFile, -1, pSrcFileW, len ); > + ret=D3DXAssembleShaderFromFileW(pSrcFileW, Flags, ppConstants, ppCompiledShader, ppCompilationErrors); > + HeapFree( GetProcessHeap(), 0, pSrcFileW ); > + return ret; > + } > + else return D3DXERR_INVALIDDATA; > } Usually it's much more readable and helps to avoid not necessary indentation to check parameters at the start of the function and return right away with appropriate error code. Besides you are mixing tabs and spaces. > -HRESULT WINAPI D3DXAssembleShaderFromFileW(LPSTR pSrcFile, DWORD Flags, > +HRESULT WINAPI D3DXAssembleShaderFromFileW(LPWSTR pSrcFile, DWORD Flags, You marked pSrcFile parameter 'const' in D3DXAssembleShaderFromFileA declaration but not in D3DXAssembleShaderFromFileW, any reason for that? -- Dmitry.

Nov. 26, 2007

Re: [keyboard] GetAsyncKeyState: request for fixing #5623

by Rafał Miłecki

2007/11/7, Rafał Miłecki <zajec5polish(a)gmail.com>: > Bug is quite well decribed in: > http://bugs.winehq.org/show_bug.cgi?id=5623 but if you don't > understand this, I can try to explain more detailed. > > So my request is someone try to fix this bug. Anyone have a free > moment for this, please? Really, not a chance for fixing this? I know you are busy, have own life, efc. but... maybe? Anyone, please? -- Rafał Miłecki

Nov. 26, 2007