January 2005 - Wine-Devel - list.winehq.org

Re: [AppDB] new fix for preferences
by Paul van Schayck Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

Hi, just found the following: [paul(a)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 Jan. 13, 2005

Jan. 13, 2005

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 Jan. 13, 2005

Jan. 13, 2005

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