wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

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 26 Nov '07

26 Nov '07

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

2 1

1.0 bugs
by Dan Kegel 26 Nov '07

26 Nov '07

[putting on tastemaster hat] So far, 82 bugs have been nominated to be fixed for 1.0. I checked a bunch of them, and so far most look reasonable. Some even look easy or have patches, e.g. http://bugs.winehq.org/show_bug.cgi?id=5402 http://bugs.winehq.org/show_bug.cgi?id=5884 http://bugs.winehq.org/show_bug.cgi?id=7544 http://bugs.winehq.org/show_bug.cgi?id=7571 http://bugs.winehq.org/show_bug.cgi?id=9104 http://bugs.winehq.org/show_bug.cgi?id=10147 The list looks meaty enough that it's probably worth folks going through and seeing what they can pick off. Stuff that's silly or too hard - just skip it for now, we'll defer those for later. - Dan

1 1

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Stefan Dösinger 26 Nov '07

26 Nov '07

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.

1 0

Re: Re: urlmon: Wrap heap functions.
by Lionel Debroux 26 Nov '07

26 Nov '07

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

1 0

Re: widl [1/7]: Output working exception handling macros. [take 2]
by Alexandre Julliard 26 Nov '07

26 Nov '07

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

1 0

Re: d3dx8: Implementation of D3DXAssembleShaderFromFileA using D3DXAssembleShaderFromFileW
by Dmitry Timoshkov 26 Nov '07

26 Nov '07

<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.

1 0

Fontforge and building wine
by Dan Kegel 26 Nov '07

26 Nov '07

It's been mentioned many times, but building Wine without a recent fontforge yields a wine that doesn't work too well. Tonight, for instance, I built wine on an updated dapper system, and forgot; here are the commands I had to use to recover (just in case somebody needs to do this again). The fontforge I chose just happens to be the latest; the --without-freetype-bytecode option is there to keep configure from searching the whole freaking hard drive for the nonexistent freetype source tree. tar -xjvf fontforge_full-20071110.tar.bz2 cd fontforge-20071110/ ./configure --prefix=/usr/local/fontforge --without-freetype-bytecode make sudo make install cd ~/wine-git cd fonts make clean PATH=/usr/local/fontforge/bin:$PATH make - Dan

1 0

Re: shdocvw: Silence common invalid QueryInterface FIXMEs.
by Alistair Leslie-Hughes 25 Nov '07

25 Nov '07

> hres = IUnknown_QueryInterface(unk, &IID_IRunnableObject, > (void**)&runnable); > ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > ok(runnable == NULL, "runnable=%p, ezpected NULL\n", runnable); > + > + hres = IUnknown_QueryInterface(unk, &IID_IPerPropertyBrowsing, > (void**)&propbrowse); > + ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > + ok(runnable == NULL, "runnable=%p, ezpected NULL\n", runnable); > + > + hres = IUnknown_QueryInterface(unk, &IID_IOleCache, (void**)&cache); > + ok(hres == E_NOINTERFACE, "QueryInterface returned %08x, expected > E_NOINTERFACE\n", hres); > + ok(cache == NULL, "runnable=%p, ezpected NULL\n", runnable); > } Hi Jacek, The tests seem wrong. Is there a reson your printing runnable twice, and not propbrowse and cache. Best Regards Alistair Leslie-Hughes

1 0

Re: bug fix: Prevented strlen(NULL) in PRINTDLG_CreateDevNames()
by Stefan Dösinger 25 Nov '07

25 Nov '07

Am Sonntag, 25. November 2007 12:35:36 schrieb Jorma Laaksonen: > Hello! > > wine-0.9.49 (as well as many earlier versions) seems to crash when > PRINTDLG_CreateDevNames() is for some reason called with DeviceDriverName > equal to NULL. The real cause of this problem might be somewhere else > where the NULL is assigned, but this simple fix prevents NULL being > passed to strlen(). If you suspect that the real problem is somewhere else, it is recommended to write a test case to see how Windows deals with this situation. Windows could return an error if the device driver name is NULL. If Windows crashes as well, your patch would only hide a bug instead of fixing it.

1 0

Re: [Bug 10488] GIT of 16.11 Exeption becaus of VBA while analysing a text
by Zac Brown 25 Nov '07

25 Nov '07

wine-bugs(a)winehq.org wrote: > http://bugs.winehq.org/show_bug.cgi?id=10488 > > > > > > --- Comment #14 from Yolande Haneder <yolande(a)haneder.biz> 2007-11-25 00:30:20 --- > Re: > > err:ole:StdMarshalImpl_ReleaseMarshalData could not map object ID to stub > manager, oxid=3700000038, oid=d > err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error > 0x8001011d > > Which I have been told to be a memory conflict in C > > and > > err:ole:apartment_getclassobject DllGetClassObject returned error 0x80040111 > > Could someone tell me which file in Wine is concerned so that someone my look > at it? > > Thank you > > Looks like dlls/ole32/marshal.c by the dump. I believe Dan Kegel had reported a bug for Wine 1.0 based on the dlls/ole32/tests/marshal.c in which it failed. The relevant bug is as follows: http://bugs.winehq.com/show_bug.cgi?id=10076 -Zac

1 1

← Newer
1
...
5
6
7
8
9
10
11
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2007