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
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:XXXX 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.
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:XXXX 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
2012/2/16 Adam Kłobukowski <adamklobukowski(a)gmail.com>:
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
W dniu 17 lutego 2012 09:20 użytkownik Frédéric Delanoy <frederic.delanoy(a)gmail.com> napisał:
2012/2/16 Adam Kłobukowski <adamklobukowski(a)gmail.com>:
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 adamklobukowski(a)gmail.com
On Fri, Feb 17, 2012 at 03:03, Adam Klobukowski <adamklobukowski(a)gmail.com> wrote:
W dniu 17 lutego 2012 09:20 użytkownik Frédéric Delanoy <frederic.delanoy(a)gmail.com> napisał:
2012/2/16 Adam Kłobukowski <adamklobukowski(a)gmail.com>:
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
participants (5)
-
Adam Klobukowski -
Adam Kłobukowski
-
Austin English -
Frédéric Delanoy -
Stefan Dösinger