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

More winecfg todos

by Mike Hearn

On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote: > Log message: > James Hawkins <truiken(a)gmail.com> > Under the Drives tab, remove the 'Windows Drive' section. You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff. Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be. Other things are: - Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of '' - Browse in the "Add/Edit drive" dialog is a WRITEME - Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates. - "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab. - The Add/Remove application buttons are *way* too big! - Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab. - Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin" - We ask the user to understand a magic * symbol to set the default - what is up with that? - There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override. - We have way too many (eg, more than zero) tree controls in this app. - Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to. Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/ it's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg. thanks -mike

Aug. 1, 2004

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

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > What is left to change? > - DWORD keytype, type, len; > + DWORD keytype, type, len, size; Why do you need new 'size' variable? 'len' works fine. > - CRYPT_Free(keyname); > - r = RegQueryValueExA(key, "Name", NULL, &keytype, NULL, &len); > - if( r != ERROR_SUCCESS || !len || keytype != REG_SZ) > + CRYPT_Free(keyname); > + r = RegQueryValueExW(key, nameW, NULL, &keytype, NULL, &size); Please do not change formatting here and everywhere else, use tab equal to 8 spaces by default, not 4. > - r = RegQueryValueExA(key, "Image Path", NULL, &keytype, NULL, &len); > + size = sizeof(DWORD); > + r = RegQueryValueExW(key, imagePathW, NULL, &keytype, NULL, &size); It was already explained. There are another similar cases. Take into account that CryptEnumProvidersA/W, CryptEnumProviderTypesA/W, CryptGetDefaultProviderA/W take number of bytes for in/out buffer in all cases: when making cross calls to them and in internal implementation. > - if (RegSetValueExA(hKey, "Name", 0, REG_SZ, pszProvName, strlen(pszProvName) +1)) > + if (RegSetValueExW(hKey, nameW, 0, REG_SZ, (LPBYTE)pszProvName, strlenW(pszProvName) +1)) Already was explained. -- Dmitry.

Aug. 1, 2004

c:\\windows is not accessible message

by Mike Hearn

Hi guys, It seems quite a few people have been seeing this message lately, and I'm not sure why. This occurs even with a non-existant ~/.wine directory, so wineprefixcreate should set up a correct system for them. Examples: http://www.linuxquestions.org/questions/showthread.php?s=&threadid=204255&h… http://forums.devshed.com/archive/t-166324 This one seems to imply that the symlinks aren't being created properly: http://www.winehq.org/hypermail/wine-users/2004/07/0022.html but that sounds like a migration issue rather than something you'd see with a clean .wine If anybody has any ideas I'd love to track this one down. I am wondering if it's to do with packaging, I have never been able to reproduce this with Wine CVS builds (ie from source) but I know some packagers are still shipping custom ~/.wine building scripts. thanks -mike

Aug. 1, 2004

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

by James Hawkins

What is left to change? On Sun, 1 Aug 2004 20:14:58 +0900, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "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. > > -- James Hawkins

Aug. 1, 2004

Re: cleanup a->w cross calls in commdlg/fontdlg.c

by Dmitry Timoshkov

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * fix cross-call functions > - return DialogBoxIndirectParamA(COMDLG32_hInstance, template, > + return DialogBoxIndirectParamW(COMDLG32_hInstance, template, > lpChFont->hwndOwner, FormatCharDlgProcA, (LPARAM)lpChFont ); You can't pass a not unicode dlgproc to DialogBoxIndirectParamW and hope that it will work. -- 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 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