wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

Re: [AppDB] new fix for preferences
by Paul van Schayck 13 Jan '05

13 Jan '05

Hey, On Thu, 13 Jan 2005 14:43:49 -0500, Chris Morgan <chmorgan(a)charter.net> wrote: > Good job guys. That was a tricky one to figure out. Yes it was (all honor to Tony and Jonathan for finding it). The memory alloc problems were caused by addmsg() calling itself recursively trying to insert a message, failing, and trying to insert a message again (trough query_error()). And those failures were caused because the connection to mysql was changed to use another database (the bugzilla db, hence the failure just after using a bugzilla function). And that was caused because although we defined a different connection resource internally the same handle was used (as descriped by the PHP manual) Now we are reselecting the database with each call to the query functions. This is still not completely a clean solution. As this will send an additional query to mysql with each query. I will try something with Tony tomorrow to get it completely clean. We also need to protect addmsg calling itself recursively. I was thinking of checking if it send out the same message already and if so exit;. Another solution would be to not use quer_appdb() but just mysql_query(). What do you think? Paul

1 0

COM inheritance Q
by Ann and Jason Edmeades 13 Jan '05

13 Jan '05

Hiya, In the wined3d code I have, for example, a class surface which inherits a lot of methods of Resource. Most of these methods can be called as-is, and I have code which looks like: HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface, IUnknown **pParent) { return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent); } Great idea.... but this fails: IWineD3DResource_GetParent is a macro: #define IWineD3DSurface_GetParent(p,a) (p)->lpVtbl->GetParent(p,a) So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast to a resource its GetParent is in the same place in the table... Hence the call ends up being effectively HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface, IUnknown **pParent) { return IWineD3DSurfaceImpl_GetParent (iface, pParent); } Whats the solution? In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions were prototyped - Is this the only way to solve this? Jason

4 10

heapalloc woes..
by Oliver Stieber 13 Jan '05

13 Jan '05

Hi, I've been doing some DirectX work with Jason and have come across a problem? with heapalloc. As soon as my system ram maxes out heapalloc fails, even though Linux is using some ram for cache and only 500k of swap is used. Wine is using <300Mb I ahve 512Mb ram and 512 swap. I've written a small test app using malloc to make sure swap is working and I can allocate well over 700Mb of ram without any problems. Should I be using something other than heapalloc or is this a 'wine' problem? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

[DPLAYX] Get rid of check for DPSET_REMOTE in dplayx.c
by Paul Vriens 13 Jan '05

13 Jan '05

Hi, as DPSET_REMOTE is 0 we cannot check for it, like it's currently done in dplayx.c: if( dwFlags & DPSET_REMOTE ) we have to use some other method. As DPSET_REMOTE and DPSET_LOCAL (which is 1) are mutually exclusive we could do: if (!(dwFlags & DPSET_LOCAL)) { } or if (dwFlags & DPSET_LOCAL) { } else /* DPSET_REMOTE */ { } The attached patch gets rid of the afore mentioned wrong checks. Remember that because of the changes the code-path changes as well. We now get into places where we 'never' went before. Patch is only compile tested and I changed some of the coding-style. Any comment is welcome. (I'm learning). Cheers, Paul.

1 0

Re: [LOSTWAGES] Add janitorial task to avoid using strncpy
by Joris Huizer 13 Jan '05

13 Jan '05

Mike McCormack wrote: > ChangeLog: > * Add janitorial task to avoid using strncpy > > > ------------------------------------------------------------------------ > > Index: templates/en/janitorial.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/janitorial.template,v > retrieving revision 1.61 > diff -u -r1.61 janitorial.template > --- templates/en/janitorial.template 11 Jan 2005 20:33:41 -0000 1.61 > +++ templates/en/janitorial.template 13 Jan 2005 15:15:44 -0000 > @@ -7,6 +7,24 @@ > Janitor's List</a>), and it's high time that we have one too. > What is there to clean up? Well, lots of things! :) > > + <h2>Eliminate uses of strncpy/strncpyW</h2> > + > + <i>strncpy(dst,src,n)</i> has two subtle > + <a href="http://weblogs.asp.net/oldnewthing/archive/2005/01/07.aspx"> > + problems</a>. The first is that it always fills the whole <i>dst</i> > + buffer (<i>n</i> characters). The second is that it doesn't always nul > + terminate the <i>dst</i> buffer that it's filling.<p> > + > + Wine code should avoid the use of strncpy for these reasons, and instead > + use lstrcpyA/W or memcpy. You can use the following command to find > + occurences of strncpy in the Wine source code:<p> > + > + <tt>find . -name \*.c -exec grep strncpy {} \; -ls</tt><p> > + > + The aim is to make sure that we only copy as many bytes as necessary into > + the <i>dst</i> buffer, and always nul terminate the buffer when we > + intended to.<p> > + > <h2>Regedit fixes</h2> > > Regedit lacks a few features. We need to improve regedit to: Couldn't we just make a sane implementation of strncpy, not adding more '\0' characters than necessary and making sure the last character is an '\0'? (untested ofcourse ;)) char *strncpy(char *dst,char *src,int n) { int i; for (i = 0; (dst[i] = src[i]) != '\0' && i < n; i++) ; /* n - 1 is '\0'; ensures the end of the string is '\0' */ dst[n - 1] = '\0'; } Now, something like this would at least save us of replacing all strncpyW, wouldn't it? regards, Joris

5 5

Re: NOTIFY_PRE and NOTIFY_POST definitions in include files
by Juan Lang 13 Jan '05

13 Jan '05

Francois wrote: > So I would say the correct values are the ones in npapi.h and that > netspi.h should be moved to dlls/mpr which is the only place where it is > used. But this needs a bit more investigation. I agree. I would conjecture that netspi.h is old, and the declarations in it have been superceded by those in npapi.h. For example, the definitions of NOFIYADD, NOTIFYCANCEL, and NOTIFYINFO don't match MSDN: http://msdn.microsoft.com/library/en-us/secauthn/security/notifyadd.asp http://msdn.microsoft.com/library/en-us/secauthn/security/notifycancel.asp http://msdn.microsoft.com/library/en-us/secauthn/security/notifyinfo.asp but those in npapi.h do. The main use of netspi.h seems to be to declare the NPS functions defined in mpr/nps.c. These aren't documented on MSDN, but are exported by Win9x versions of mpr.dll. Anything that doesn't support these functions should be deleted, and since it's not part of the PSDK, making it a private header is fine, or just moving the required declarations to nps.c should be fine too. --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0

[AppDB] create new users is Br0ck.
by tony_lambregts＠telusplanet.net 13 Jan '05

13 Jan '05

The last patch broke make_bugzilla_version_list() which is used by account.php and admin/editAppVersion.php. That means that new users can not create accounts and maintainers cannot edit their versions. http://cvs.winehq.org/patch.py?id=15387 The same code on my machine works fine with my test databases. I do not know how to fix this other than reversing the patch. -- Tony Lambregts.

4 7

NOTIFY_PRE and NOTIFY_POST definitions in include files
by Paul Vriens 13 Jan '05

13 Jan '05

Hi, just found the following: [paul@penguin include]$ grep -e NOTIFY_PRE -e NOTIFY_POST * netspi.h:#define NOTIFY_PRE 0x00 netspi.h:#define NOTIFY_POST 0x01 npapi.h:#define NOTIFY_PRE 0x00000001 npapi.h:#define NOTIFY_POST 0x00000002 this doesn't look right although they do not seem to be used anywhere in the code currently. Any comments? Cheers, Paul.

2 1

Re: The use of a zero flag
by Rolf Kalbermatter 13 Jan '05

13 Jan '05

Paul Vriens wrote: >a few days ago I found a bug in ole32/compobj.c where we did something >like: > >if ( foo & FLAG) .... where FLAG=0 > >This 'inspired' me to check for more of these kind of checks. > >One that I already found is in dlls/dplayx/dplay.c > >We are checking for DPSET_REMOTE (which is zero) where we should have >checked for !DPSET_LOCAL or something alike. Often flag sets with a zero flag are more like an enumeration than real flags and have some sort of mask defined which specifies which bits are relevant for that group of flags. Microsoft does something mix real flags and enumeration flags in the same integer but always at different bit locations. Something like if ((foo & MASK) == FLAG) will usually work fine then. Rolf Kalbermatter

1 0

[COMCTL32] The use of the PGS_VERT flag
by Paul Vriens 13 Jan '05

13 Jan '05

Hi, the flag PGS_VERT is zero and should not be checked against. It's only the lack of PGS_HORZ that should be checked. Is the following piece of code needed in dll//comctl32/pager.c: 851 if (!(dwStyle & PGS_HORZ) && !(dwStyle & PGS_VERT)) 852 { 853 dwStyle |= PGS_VERT; 854 SetWindowLongA(hwnd, GWL_STYLE, dwStyle); 855 } The check is whether any of the flags is set, but PGS_VERT is already the default when there is a lack of PGS_HORZ. Cheers, Paul.

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
35
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 January 2005