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

Re: [Wine]faking network shares

by David Lee Lambert

On Thu, Aug 12, 2004 at 12:42:08PM +0100, Fergal Daly wrote: > I have an app that wants to read from \\server\directory\file.ini and I > don't have an easy way of changing this, so I want to tell wine that > \\server\directory is available in /mnt/smb/server/directory. Is this > possible? What do I need to do? If you try to read from a path starting "\\.\" in Wine (in some versions), you'll get a message saying something like "Fixme: UNC name (%s) not supported.", but there is basic support for Wine to read from a file directly over an SMB link for paths that start with "\\" up until Wine-20040505. It identifies itself as a WfW server and doesn't attempt to provide a username or password, as far as I can tell. It looks like the relevant functions were deleted before 20040615. In principle, Wine could probably provide UNC-name support by calling 'smbclient', or by parsing /etc/mtab for 'smbfs' mountpoints and trying to access them like any other file. Another alternative would be a configuration-file override to alias an arbitrary UNC path as some file, just like the old [Drive X] mappings. In your case, would it be acceptable to have a local, static copy of the .ini file, and just point Wine at that somehow? (Forwarding to the developer's list, since it looks like this is a useful feature that was removed because no one was finishing it.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 15, 2004

Re: [wine] Re: config converting problem

by David Lee Lambert

On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote: > Hi Mike, you wrote: > >I'm not sure what to do about this, except maybe to add back in support > >for ${HOME} style vars. It's clear that people are "using" (at least, > >installing) much older versions than we anticipated. > > Personally I would prefer to merge back the support for ${HOME} > variables because I think many other people have the same problem > if they want to upgrade wine. Not having totally grokked the code, I think this raises an important semantic issue: if ~/.wine/dosdevices and the config-file's text conflict, which has priority? Or should Wine read the config-file and then (effectively) overwrite the settings with the contents of ~/.wine/dosdevices? This won't work if Wine automatically builds ~/.dosdevices from scratch. It seems that mapping one drive to the user's home directory is a common case, since many organizations already do this for users via Samba or Netware. As presently implemented, is there any reason a system administrator shouldn't do ( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. ) where f (for example) is the drive letter used for each user's home directory, and then use a shell script to push the change out retroactively to existing accounts? -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 15, 2004

Windows Default Button Observations

by Zach Gorman

While fixing some compatibility problems in Wine relating to my app, I had the opportunity to compare how Wine handles default buttons to how Windows handles them. [Definition: Default buttons have the BS_DEFPUSHBUTTON style, are drawn with an extra-thick border, and are the buttons chosen when the user types Enter.] I fixed a couple problems today, but there are more issues left: ------- (1) Windows: When a dialog is deactivated in Windows, all buttons are made non-default. When it is activated again, Windows remembers which button was last the default button and makes it default again. It does all this by means of BM_SETSTATE messages. Wine: Default buttons are unaffected by activation/de-activation of their parent dialogs. (2) Windows: When the user clicks and holds on a button, then moves the mouse off that button before releasing it, the button is made default and receives the focus. The existing default button is made non-default. Wine: The button receives the focus but is not made default. -------- My impression is that (1) could be handled by remembering the default button (which, as Krishna Murthy has shown, is not the same as the default button id) in the DIALOGINFO structure. Number (2), however, is more difficult. When a button receives the capture, it can send a BM_SETSTATE to itself easily enough to make itself a DEFPUSHBUTTON, but how does it determine which other buttons to query and make non-default as necessary? It could simply query all its sibling controls, but this wouldn't work if it was contained within a sub-window in the dialog box. How can it determine how far up the hierarchy it needs to go? Any comments would be welcomed. Thanks, Zach

Aug. 15, 2004

Re: wine/dlls/commdlg fontdlg.c

by Jacek Caban

Vincent Béron wrote: >Le ven 13/08/2004 à 20:42, Alexandre Julliard a écrit : > > >>ChangeSet ID: 13294 >>CVSROOT: /opt/cvs-commit >>Module name: wine >>Changes by: julliard(a)wine.codeweavers.com 2004/08/13 19:42:35 >> >>Modified files: >> dlls/commdlg : fontdlg.c >> >>Log message: >> Jacek Caban <jack(a)itma.pwr.wroc.pl> >> Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand >> in FormatCharDlgProcW. >> >>Patch: http://cvs.winehq.org/patch.py?id=13294 >> >>Old revision New revision Changes Path >> 1.69 1.70 +2 -5 wine/dlls/commdlg/fontdlg.c >> >> > >At least the last part of this patch looks wrong. > >- return CFn_WMCommand(hDlg, wParam, lParam, lpcf32a); >+ return CFn_WMCommand(hDlg, wParam, lParam, >(LPCHOOSEFONTW)lpcf32w); > >This cast is absolutely non-sense, as lpcf32w is already a >LPCHOOSEFONTW. Aslo, CFn_WMCommand expects a LPCHOOSEFONTA as its fourth >parameter, not a LPCHOOSEFONTW. > > It should be LPCHOOSEFONTA. Sory for that. >Maybe just changing the cast to LPCHOOSEFONTA would work, but a quick >glance in CFn_WMCommand told me it uses some A fields of that structure, >so maybe it's not enough and we'll need to actually do a conversion (or >transform CFn_WMCommand to expect a LPCHOOSEFONTW). > > I've tested this usng notepad and it works fine. Absolutely non-sense was cast that my patch changes. It didn't work without my patch. Applications failed with segmentation fault. >Vincent > > > I've attached patch. Thanks, Jacek

Aug. 15, 2004

Re: wine/dlls/commdlg fontdlg.c

by Vincent Béron

Le ven 13/08/2004 à 20:42, Alexandre Julliard a écrit : > ChangeSet ID: 13294 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/08/13 19:42:35 > > Modified files: > dlls/commdlg : fontdlg.c > > Log message: > Jacek Caban <jack(a)itma.pwr.wroc.pl> > Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand > in FormatCharDlgProcW. > > Patch: http://cvs.winehq.org/patch.py?id=13294 > > Old revision New revision Changes Path > 1.69 1.70 +2 -5 wine/dlls/commdlg/fontdlg.c At least the last part of this patch looks wrong. - return CFn_WMCommand(hDlg, wParam, lParam, lpcf32a); + return CFn_WMCommand(hDlg, wParam, lParam, (LPCHOOSEFONTW)lpcf32w); This cast is absolutely non-sense, as lpcf32w is already a LPCHOOSEFONTW. Aslo, CFn_WMCommand expects a LPCHOOSEFONTA as its fourth parameter, not a LPCHOOSEFONTW. Maybe just changing the cast to LPCHOOSEFONTA would work, but a quick glance in CFn_WMCommand told me it uses some A fields of that structure, so maybe it's not enough and we'll need to actually do a conversion (or transform CFn_WMCommand to expect a LPCHOOSEFONTW). Vincent

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Hi, >> >> Changelog: >> Don't fail a connection because an input pin does not expose the >> IMemInputPin interface (pull pins typically). > > > > This seems wrong. The FileAsyncReaderPin (and any other output pin > that connects to a pull pin) should override the pConnectSpecific > function so that it doesn't query for IMemInputPin. I can't explain > why this isn't currently done. You're simply right. This is wrong. Ok, I will resent a patch without this change for the moment. > > > I don't really like the (%p/%p)->... notation, but if it helps you in > debugging then it's fine. Well, I won't repeat what Lionel said but this has been very usefull for debugging the quartz code. Christian

Aug. 14, 2004

Re: [QUARTZ] Some bug fixes

by Christian Costa

> > >> Avoid indefinite wait when calling GetOverlappedResult. > > > This shouldn't happen. GetOverlappedResult should do a wait on the > event object, just like the wait above that succeeds (and > GetOverlappedResult is called) or times out (and GetOverlappedResult > is not called). I suspect that the bug is elsewhere, perhaps an event > should be created for each request and then WaitForMultipleObjects used. > BTW, I meant infinite wait... Well, some lines above the GetOverlappedResult, there is a WaitForSingleObject on the event and since the event is resetted automatically there (the event is not manual) GetOverlappedResult will wait forever. There is no bug elsewhere its a rather simple win32 related problem. Anyway, we may make use of a manual event for real asynchronous requests. The avi splitter don't do that at the moment so the current implementation is enough. Thanks for the comments. :-) Christian

Aug. 14, 2004

Re: [QUARTZ] Some bug fixes

by Robert Shearman

Christian Costa wrote: >> >>> Avoid indefinite wait when calling GetOverlappedResult. >> >> >> This shouldn't happen. GetOverlappedResult should do a wait on the >> event object, just like the wait above that succeeds (and >> GetOverlappedResult is called) or times out (and GetOverlappedResult >> is not called). I suspect that the bug is elsewhere, perhaps an event >> should be created for each request and then WaitForMultipleObjects used. >> > BTW, I meant infinite wait... > > Well, some lines above the GetOverlappedResult, there is a > WaitForSingleObject on the event and since the event is resetted > automatically there (the event is not manual) GetOverlappedResult will > wait forever. > There is no bug elsewhere its a rather simple win32 related problem. > Anyway, we may make use of a manual event for real asynchronous requests. > The avi splitter don't do that at the moment so the current > implementation is enough. Ah, yes. In that case the patch is correct. > Thanks for the comments. :-) You're welcome. Rob

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Lionel Ulmer

> I don't really like the (%p/%p)->... notation, but if it helps you in > debugging then it's fine. Well, I introduced this notation in the D3D code to log both the interface given by the application AND the 'base' object from the Wine side. Which is sometimes useful to debug when we get problems with object version mismatch. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Robert Shearman

Christian Costa wrote: > Hi, > > Changelog: > Don't fail a connection because an input pin does not expose the > IMemInputPin interface (pull pins typically). This seems wrong. The FileAsyncReaderPin (and any other output pin that connects to a pull pin) should override the pConnectSpecific function so that it doesn't query for IMemInputPin. I can't explain why this isn't currently done. > Fixed a bug that made the connection possible whereas no suitable > media type has be found during the negociation. Good catch. > Fixed the release of the media sample in PullPin_Thread_Process. Again, good catch. I see now that without this fix we would have leaked ref counts on the IMediaSample object. > Added and fixed a lot of traces. I don't really like the (%p/%p)->... notation, but if it helps you in debugging then it's fine. Rob

Aug. 14, 2004