Re: "Known" DLLs
On Fri, Feb 17, 2012 at 03:03, Adam Klobukowski wrote: > W dniu 17 lutego 2012 09:20 użytkownik Frédéric Delanoy > napisał: >> 2012/2/16 Adam Kłobukowski : >>> Hello >>> >>> I've been a Wine user for a long time alreadey, since all Wine could do was >>> running winesweper very slowly ;) >>> >>> I'd like to propose a feature that could be implemented in Wine. >>> >>> Wine does not implement all Windows APIs (yet ;)) and big parts of existing >>> implementations are only stubs. Therefore, it could be usefull if Wine would >>> be able to detect when a program tries to use a DLL that is not >>> implememnted, but is easily available for download. .NET, MSXML, VCRUN* >>> comes in mind. Instead of just failing, Wine could offer advice to the user >>> how to deal with that. >>> >>> This could also help with APIs that are mostly stubbed, work for some use >>> cases, but are expected to fail in other - they could detect if an app is >>> trying to use unsuported case and take action. >> >> Problem is that some applications work even when some DLLs are mostly >> stubbed, and would fail when setting stuff to native/winetricksing, >> while other might do the opposite. >> Worse, even the same app/same version would need different workarounds... > > I think detecting the need for whole APIs (.NET, etc) it could be > possible. Stubs seems more tricky, but maybe it is possible in some > well defined cases This is already done for .NET, see dlls/mscoree/metahost.c -- -Austin
Re: "Known" DLLs
W dniu 17 lutego 2012 09:20 użytkownik Frédéric Delanoy napisał: > 2012/2/16 Adam Kłobukowski : >> Hello >> >> I've been a Wine user for a long time alreadey, since all Wine could do was >> running winesweper very slowly ;) >> >> I'd like to propose a feature that could be implemented in Wine. >> >> Wine does not implement all Windows APIs (yet ;)) and big parts of existing >> implementations are only stubs. Therefore, it could be usefull if Wine would >> be able to detect when a program tries to use a DLL that is not >> implememnted, but is easily available for download. .NET, MSXML, VCRUN* >> comes in mind. Instead of just failing, Wine could offer advice to the user >> how to deal with that. >> >> This could also help with APIs that are mostly stubbed, work for some use >> cases, but are expected to fail in other - they could detect if an app is >> trying to use unsuported case and take action. > > Problem is that some applications work even when some DLLs are mostly > stubbed, and would fail when setting stuff to native/winetricksing, > while other might do the opposite. > Worse, even the same app/same version would need different workarounds... I think detecting the need for whole APIs (.NET, etc) it could be possible. Stubs seems more tricky, but maybe it is possible in some well defined cases > I really don't think we want to replicate the appdb in the code... It does not seem to me as replicating appdb in code, at least for APIs. Stubs, yes may seem so. -- Semper Fidelis Adam Klobukowski adamklobukow...@gmail.com
Re: "Known" DLLs
2012/2/16 Adam Kłobukowski : > Hello > > I've been a Wine user for a long time alreadey, since all Wine could do was > running winesweper very slowly ;) > > I'd like to propose a feature that could be implemented in Wine. > > Wine does not implement all Windows APIs (yet ;)) and big parts of existing > implementations are only stubs. Therefore, it could be usefull if Wine would > be able to detect when a program tries to use a DLL that is not > implememnted, but is easily available for download. .NET, MSXML, VCRUN* > comes in mind. Instead of just failing, Wine could offer advice to the user > how to deal with that. > > This could also help with APIs that are mostly stubbed, work for some use > cases, but are expected to fail in other - they could detect if an app is > trying to use unsuported case and take action. Problem is that some applications work even when some DLLs are mostly stubbed, and would fail when setting stuff to native/winetricksing, while other might do the opposite. Worse, even the same app/same version would need different workarounds... I really don't think we want to replicate the appdb in the code... Frédéric
re: "Known" DLLs
This has been discussed off and on over the years, e.g. http://www.winehq.org/pipermail/wine-devel/2009-September/078441.html http://www.winehq.org/pipermail/wine-devel/2010-September/086465.html http://www.winehq.org/pipermail/wine-devel/2010-September/086469.html There is a kind of notification system in place, the winediag debug channel. I think the intent of that was to make it possible for distros to show those messages to the user (maybe with a dialog), and hide all the other log messages. At the moment, the dll load failure message doesn't go to +winediag. Maybe it should (although there are probably times when it's safe to ignore them, so I'm not sure). Anyway, +winediag or not, one can imagine a wrapper outside wine that notices events like this and offers to assist the user in those few cases (mfc42? vb6run?) where there's a high likelihood of success. Here's a crude example: wine "$@" 2>&1 | tee foo.log if grep -i "Library MFC42.DLL" foo.log then zenity --warning --text "This app seems to need mfc42. Try running winetricks mfc42." fi It would take a bunch of work to get something worth deploying, but if you're interested, go for it...
Re: "Known" DLLs
W dniu 16.02.2012 19:34, Stefan Dösinger pisze: Am Donnerstag, 16. Februar 2012, 18:45:37 schrieb Adam Kłobukowski: Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Well, if a DLL is outright missing you should get an ERR. If the app calls a stub, the stub writes a FIXME. I'm not sure what else we can do - showing up a dialog box in those cases is a bad idea. Or do you mean make the messages more informative, like write "you may want to install the Visual Basic 6 runtime from http://microsoft.com/foo/bar"; instead of something like "could not load msvb60.dll"? While Wine log might be enough for me, for less tech savvy users it is a mistery, and in most cases they do not even know it exists. Log message seems an easy solution, but a dialog box might be much better for a 'customer base' of such feature. Such dialog should be shown only once per program run, In some cases (.NET?) such deature could even offer an auto-fix (using winetricks?). Arguably the worst situation is when the app loads a library at runtime instead of linking and thus doesn't cause linker errors, or if it attempts to load a OLE class and users misinterpret the err:ole: error as an OLE issue rather than a missing library. Still, apps loads some DLL, ant this can be intercepted. I do not know enough about how OLE works, but maybe a sister 'Known OLE keys' feature might me usefull too :) Overall I'd prefer to maintain such information in the documentation or wiki instead of the code. This could be handled by some kind of configuration (xml?) file. AdamK
Re: "Known" DLLs
Am Donnerstag, 16. Februar 2012, 18:45:37 schrieb Adam Kłobukowski: > Therefore, it could be usefull > if Wine would be able to detect when a program tries to use a DLL that > is not implememnted, but is easily available for download. .NET, MSXML, > VCRUN* comes in mind. Instead of just failing, Wine could offer advice > to the user how to deal with that. > > This could also help with APIs that are mostly stubbed, work for some > use cases, but are expected to fail in other - they could detect if an > app is trying to use unsuported case and take action. Well, if a DLL is outright missing you should get an ERR. If the app calls a stub, the stub writes a FIXME. I'm not sure what else we can do - showing up a dialog box in those cases is a bad idea. Or do you mean make the messages more informative, like write "you may want to install the Visual Basic 6 runtime from http://microsoft.com/foo/bar"; instead of something like "could not load msvb60.dll"? Arguably the worst situation is when the app loads a library at runtime instead of linking and thus doesn't cause linker errors, or if it attempts to load a OLE class and users misinterpret the err:ole: error as an OLE issue rather than a missing library. Overall I'd prefer to maintain such information in the documentation or wiki instead of the code.
"Known" DLLs
Hello I've been a Wine user for a long time alreadey, since all Wine could do was running winesweper very slowly ;) I'd like to propose a feature that could be implemented in Wine. Wine does not implement all Windows APIs (yet ;)) and big parts of existing implementations are only stubs. Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Adam Klobukowski
