wine-devel April 2007

wine-devel@winehq.org

139 participants
312 discussions

Re: [04/10] wined3d: Ignore SetTextureStageState on unsupported texture stages
by Stefan Dösinger 16 Apr '07

16 Apr '07

Am Montag 16 April 2007 21:19 schrieb H. Verbeet: > Tests indicate that Windows doesn't actually check the bounds on this > call. However, since our memory layout is almost certainly different > > >from Windows' an application might very well get away with a little > > bit of memory corruption on Windows and not on Wine. It seems to me > that the best way to deal with this is to simply print a WARN and > return WINED3D_OK. > > Changelog: > - Ignore SetTextureStageState on unsupported texture stages Wouldn't it be better to check against MAX_TEXTURES instead of the gl limit? Or do changes get lost on windows too? GetTextureStageState may tell the difference

2 1

re: Which component should I use to create this bug ?
by Dan Kegel 16 Apr '07

16 Apr '07

lauren wrote: >When Navigation is installed, the file DAO350.dll is copied to the >Common Files directory and is regsrved. When running Navigation >after that, it displays an error message about not finding DAO350.dll. > >Copying the file to windows/system32 allows Navigation to find >the file and use it, but it should be able to find it in Common Files too. > >Which component should I choose ? If installing native dcom fixes it, use wine-ole. (e.g. winetricks dcom98) If in doubt, use wine-misc. (Native MSI doesn't seem to work right now, so don't try that... see http://bugs.winehq.org/show_bug.cgi?id=5809 ) > Navigation is a Visual Basic program, using VB methods to load dlls. Be sure to give the app's home page. If you had mentioned it in this message, I would have tried it out myself... - Dan

3 3

Re: advapi32: Added test and fix for GetFileSecurity
by James Hawkins 16 Apr '07

16 Apr '07

On 4/16/07, Nigel Nia-Chiang Liang <ncliang(a)gmail.com> wrote: > Hi, > > Added a simple test case and fix for GetFileSecurity with NULL > pSecurityDescriptor parameter as suggested by James Hawkins. > SetLastError(NO_ERROR); + result = pGetFileSecurityA( directory,OWNER_SECURITY_INFORMATION,buffer,0x40,&outSize); Please don't change the whitespace. The SetLastError call is a part of that test block, so there's no need for an empty line. + result = pGetFileSecurityA( directory,OWNER_SECURITY_INFORMATION,NULL,0x40,&outSize); + ok(result, "GetFileSecurityA should not fail for NULL pSecurityDescriptor parameter\n"); What is the value of outSize in this case? You need to set it to some value before the call and check if it's changed after the call. -- James Hawkins

1 0

Re: crypt32: Constify some variables (4 of 5) (Resend)
by Robert Shearman 16 Apr '07

16 Apr '07

Andrew Talbot wrote: > typedef BOOL (WINAPI *CryptDecodeObjectFunc)(DWORD, LPCSTR, const BYTE *, > DWORD, DWORD, void *, DWORD *); > typedef BOOL (WINAPI *CryptDecodeObjectExFunc)(DWORD, LPCSTR, const BYTE *, > - DWORD, DWORD, PCRYPT_DECODE_PARA, void *, DWORD *); > + DWORD, DWORD, const CRYPT_DECODE_PARA *, void *, DWORD *); > > This declaration needs to match that of CryptDecodeObjectEx in wincrypt.h. -- Rob Shearman

2 1

Random X errors caused by recent cursor patch?
by Dan Kegel 16 Apr '07

16 Apr '07

Looks like there's been a regression lately. I'm getting errors like this X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 54 (X_FreePixmap) Resource id in failed request: 0x2a0006a randomly, about every fourth time I run things that used to work. A user on c.e.m.w. http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/1f41dbd21… speculates that the recent cursors patch introduced the regression. The error doesn't happen often enough to make a regression test easy, and I haven't tried myself yet.

7 8

gdi32 : Questions about SetDIBColorTable and GetDIBColorTable
by Laurent Vromman 16 Apr '07

16 Apr '07

Hi, I am looking deeper inside gdi32 in order to continue helping wine after my first try on WidenPath. Something looks strange to me in SetDIBColorTable and GetDIBColorTable. GetDIBColorTable is structured like this : if (dc->funcs->pGetDIBColorTable) result = dc->funcs->pGetDIBColorTable; else { result = local implementation; } return result; This looks normal. If dc->funcs->pGetDIBColorTable is available, wine uses it, else it uses a local implementation. In both cases, the return value is the result of the chosen operation. But I have more difficulties with SetDIBColorTable : result = local implementation; if (dc->funcs->pGetDIBColorTable) dc->funcs->pGetDIBColorTable; return result; Whatever happen next, the local implementation is used. Then if pGetDIBColorTable is available, it is used too. I see here a second call for the same thing, even if the local implementation succeed. Moreover, the result of dc->funcs->pGetDIBColorTable is not used as a return value. Is there a mistake here, or is there something I do not understand ? GetDIBColorTable uses the local implementation only if dc->funcs is not available. That is not the case for SetDIBColorTable, which runs first the local implementation. What is the right policy to apply here ? I believe the call order of pSetDIBColorTable and the fact its return value is not used are errors. Am i wrong? If someone can confirm I am not, I will provide a patch in the next days. Thank you for your help and time, Laurent Vromman

2 1

Re: winealsa: implement opening and closing of device, and return caps.
by Alexandre Julliard 16 Apr '07

16 Apr '07

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > +/* Note: this thread can be TerminateThread'd, when not in critical section > + * Hence I use alloca here, and a critical section to protect when it is not > + * desired to be TerminateThread'd, assume when the critical section is taken > + * we won't ever get it back and we're signalled to terminate > + */ > +static DWORD WINAPI callback_thread(LPVOID lParam) You can't use TerminateThread for normal termination, it should only be used for fatal erros when cleaning up properly is not possible. Also please don't use alloca. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: D3D9: Rework the converted vertex declaration management
by H. Verbeet 16 Apr '07

16 Apr '07

On 16/04/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I have hope that this fixes the converted decl issues finally(appart of > sorting the array, which will be another patch) > > + convertedDecls = HeapAlloc(GetProcessHeap(), 0, sizeof(IDirect3DVertexDeclaration9 *) * (This->numConvertedDecls + 1)); > + if(!convertedDecls) { > + /* This will destroy it */ > + IDirect3DVertexDeclaration9_Release(pDecl); > + return NULL; > + } > + > + memcpy(convertedDecls, This->convertedDecls, sizeof(IDirect3DVertexDeclaration9 *) * (This->numConvertedDecls)); > + HeapFree(GetProcessHeap(), 0, This->convertedDecls); Growing the array by a single element each time looks a bit expensive. Also note that you could use HeapReAlloc there.

2 1

Re: user32: Fix to succeed reliably in test where it works by accident.
by Robert Shearman 16 Apr '07

16 Apr '07

Jan Zerebecki wrote: > + if (!iconinfo->hbmMask) { > + return 0; > + } > if (iconinfo->hbmColor) > { > Please match the coding style of the rest of the function. -- Rob Shearman

1 0

KDevelop configure error or winebug
by marcel busse 16 Apr '07

16 Apr '07

hi i can't debug with winedbg. it steps until end cause of no line debug info. at the start of the debugging process there is a fixme - it says something about dwarf-2 information. My config: i started a hello world with kdevelop and took as c++ compiler wineg++. that's all. __________________________________ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever

2 1

← Newer
1
...
16
17
18
19
20
21
22
...
32
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 April 2007