August 2004 - Wine-Devel - list.winehq.org

Re: cleanup a->w cross calls in advapi32/crypt.c

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed even more bugs spotted by Dmitry. > > Changelog > * cleanup cross-call functions The quality of the patch still is not good enough. -- Dmitry.

Aug. 1, 2004

Re: Question about mmap issues on FreeBSD/NetBSD

by Yorick Hardy

Try the patch below, I am not yet sure why this would be necessary. Perhaps it helps. >I've got some cross platform issues i cannot resolve. There are some >obvious issues like the assumption that round() is in the math library >and not linking in the math library itself. i've worked passed those. >Currently, I'm working with a patched version of the latest cvs source >on Solaris 9x86. After applying Robert Lunnon's patch kit to the latest >cvs course and substituting rint for the round function in >wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got a >clean compile. however running the wine binary results in the following: > >try_mmap_fixed: vfork: Resource temporarily unavailable > >I'm not intimately familiar with how wine manages it's memory so I >hesitate to guess what is going on. I've attached the output of the >truss if anyone has any ideas on what it going on or how to fix it >please let me know. Kind regards, -- Yorick Hardy --- libs/wine/mmap.c.orig Thu Jul 29 20:03:03 2004 +++ libs/wine/mmap.c Sun Aug 1 13:07:07 2004 @@ -135,6 +135,8 @@ has exited. Furthermore, Wine sets SIGCHLD to SIG_IGN, so we don't need to wait for the child. */ + waitpid(pid, &pagesize, 0); + return result == addr; } #endif /* (__svr4__ || __NetBSD__) && !MAP_TRYFIXED */

Aug. 1, 2004

Re: [RESENT] Make wine work with freedesktop.org MIME system

by Mike Hearn

This was checked into CVS a few days ago, no need to resend. thanks -mike On Sun, 2004-08-01 at 11:35 +0200, Christian Neumair wrote: > Mike felt good enough to explain me on IRC where I should hook into the > wine build system. I've put up a tiny patch that works like a charm with > GNOME/shared-mime-info HEAD. It associates wine with the MIME type used > for DOS/Win32 binaries. > > regs, > Chris

Aug. 1, 2004

Wine leaking GDI handles?

by Jon Griffiths

Hi, I am trying to track down some GDI leaks in a large application I am porting. To make things easier I added logging to GDI_AllocObject and GDI_FreeObject in order to find mismatches at program termination, and hacked a script to find allocations that weren't deallocated. The patch to dlls/gdi/gdiobj.c and the script used are both attached below. My first question is; Is this a valid approach to tracking leaks, or are some GDI objects deallocated in another way? i.e. Should there be a GDI_FreeObject call for every GDI_AllocObject call or not? I run this analysis by setting WINEDEBUG="+all" and executing my app redirecting the results to a file. I then run the matching script to generate a list of addresses from GDI_AllocObject that have no corresponding GDI_FreeObject, along with the line number in the trace that the allocation occurred. This produced a rather overwhelming list which has thus far enabled me to find several application bugs causing leaks. However investigating several of the calls makes me suspect that Wine itself may have some leaks. If you follow the directions above against Wines clock.exe it lists here 121 unmatched deallocations (winver has 126). Some of these are for things like stock objects which arguably aren't very important, since they are only created once. But it appears that window creation/destruction may have leaks which is of definite concern here since my app creates many windows while generating screens on the fly (I see in my app that when GetDC is called for the first time on a window, causing a CreateDCW call, a region is leaked, or at least thats what it looks like to me). I seems a good idea to attempt to diagnose the leaks on a simple program like clock/winver before trying a more complicated app. Could someone with more experience in GDI verify that these leaks are genuine? I am a little lost amongst the GDI/user code... Thanks, Jon p.s. The script below does not handle GDI realloc, but I have yet to see it in any of my traces yet. ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

Aug. 1, 2004

Re: cleanup a->w cross calls in advapi32/crypt.c

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed more bugs spotted by Dmitry. > > Changelog > * cleanup cross-call functions If you could use 'static const' as everywhere else and not 'const static' that would be nice. > + size = sizeof(DWORD); > + r = RegQueryValueExW(key, nameW, NULL, &keytype, NULL, &size); Why did you add size initialization here? If that wasn't done before there was a reason for that. > + provNameLen = *pcbProvName * sizeof(WCHAR); > + if ( pszProvName && (str = CRYPT_Alloc(provNameLen * sizeof(WCHAR))) ) > + CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > + ret = CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, str, &provNameLen); Remove double sizeof(WCHAR) multiplcation here and everywhere else. > - DWORD size = sizeof(DWORD); > + DWORD size = sizeof(pdwProvType); > HKEY subkey; > - if (RegEnumKeyA(hKey, dwIndex, pszProvName, *pcbProvName)) > + if (RegEnumKeyW(hKey, dwIndex, pszProvName, *pcbProvName)) RegEnumKeyW takes number of characters, not bytes. Why did you change that since your previous patch? Please read documentation first, otherwise you are wasting your and our time. -- Dmitry.

Aug. 1, 2004

Re: cleanup a->w cross calls in advapi32/crypt.c

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed bugs spotted by Dmitry > > Changelog > * cleanup cross-call functions Still there are bugs in the patch. 1. RegQueryValueExW/RegSetValueExW take bytes in the last parameter 2. Do not use 'strlen' as a name of the variable, that at least very confusing. -- Dmitry.

Aug. 1, 2004

Re: for whoever maintinas winrash

by Ferenc Wagner

Chris Morgan <cmorgan(a)alum.wpi.edu> writes: >>> Also, during the installation process, after I entered >>> my email address, the installer removed what it called >>> 'invalid characters' - i.e., underscores. All my main >>> email addresses contain underscores, so I was forced to >>> enter an old one that is not very reliable. > > We could support underscores but Feri tells me that they > aren't supported by winetest so I strip them out both > during the install and when the email address is being used. > > Feri, anyway we can add support for underscores in > winetest and remove this requirement? Hmm, I suspect some misunderstanding here. I told winetest didn't allow underscores in the Tag (which is given by the -t option). On the other hand, winetest doesn't even know about email addresses, therefore it doesn't require anything in this respect. I will add support for them, and only require that they don't contain newline characters, ok? ;) -- Feri.

Aug. 1, 2004