https://bugs.winehq.org/show_bug.cgi?id=44005
Bug ID: 44005 Summary: ieproxy registration breaks Internet Explorer 8 Product: Wine Version: 2.20 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: piotr.caban@gmail.com Distribution: ---
Internet Explorer 8 no longer starts in wine. Steps to reproduce: sh winetricks ie8 wine iexplore
This is a regression caused by this commit: commit 448ac0e9c439c5a8095e2e8a150997caebcb32ab Author: Zebediah Figura zfigura@codeweavers.com Date: Thu Aug 10 13:52:31 2017 -0500
ieproxy: Add proxy/stub for IInternetExplorerManager.
Signed-off-by: Zebediah Figura zfigura@codeweavers.com Signed-off-by: Jacek Caban jacek@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
Setting the ieproxy dll to native is not helping because builtin gets registered on prefix update (different installation path). The dll path is different depending on Internet Explorer version. So it kind of makes it impossible to use native.
The dll is missing a proxy/stub for C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6 (undocumented).
https://bugs.winehq.org/show_bug.cgi?id=44005
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |448ac0e9c439c5a8095e2e8a150 | |997caebcb32ab
https://bugs.winehq.org/show_bug.cgi?id=44005
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=44005
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |austinenglish@gmail.com, | |jacek@codeweavers.com, | |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #1 from Piotr Caban piotr.caban@gmail.com --- I've checked what proxy/stubs are needed for IE8 to start: ITabWindow (FF18630E-5B18-4A07-8A75-9FD3CE5A2D14) IEnumRecoveryCredential (D358F4E1-0465-4965-9DD5-CAE303D2C345) IEnumRecoveryCookieJar (B40C43F1-F039-44D2-AEB7-87F5AF8ABC3D) IDestinationStreamFactory (8A87781B-39A7-4A1F-AAB3-A39B9C34A7D9)
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- I only seem to need 8a7476f4-d264-4e13-ae72-20cd9831d98c (ITabRecoveryData) and b40c43f1-f039-44d2-aeb7-87f5af8abc3d (IEnumRecoveryCookieJar). Is adding these the correct solution? If so, how should they be added? On the other hand, perhaps setupapi should be modified not to attempt to re-register a DLL for which there is an override listed.
https://bugs.winehq.org/show_bug.cgi?id=44005
Qwerty Chouskie asdfghrbljzmkd@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asdfghrbljzmkd@outlook.com
https://bugs.winehq.org/show_bug.cgi?id=44005
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ieframe
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #3 from Qwerty Chouskie asdfghrbljzmkd@outlook.com --- Any chances of this getting fixed soon? This breaks a lot of software.
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- What seems to make the most sense to me is that dlls which are overridden as native-only shouldn't have their resources registered by setupapi.
In particular I think it makes sense that setupapi should use DllRegisterServer() to register DLLs, instead of accessing the WINE_REGISTRY
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- Sorry, that got cut off.
What seems to make the most sense to me is that dlls which are overridden as native-only shouldn't have their resources registered by setupapi.
In particular I think it makes sense that setupapi should use DllRegisterServer() to register DLLs, instead of accessing the WINE_REGISTRY resource directly. This would mean firstly that the correct version of the DLL would be loaded, and secondly that we could get rid of the magic list of DLLs which do unusual things in their DllRegisterServer entry (RegisterDllsSection).
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Loading all the dlls on prefix update is slow and fragile, we don't want to do that.
The fakedll shouldn't get registered again once native is installed over it. If for some reason IE uses a different path, winetricks should replace it explicitly. But of course fixing builtin is the preferred solution.
https://bugs.winehq.org/show_bug.cgi?id=44005
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alexandre Julliard from comment #6)
The fakedll shouldn't get registered again once native is installed over it.
It does, because setupapi bypasses the DLL override code completely. (Even using LOAD_LIBRARY_AS_DATAFILE wouldn't work, because that still bypasses the DLL override code).
If for some reason IE uses a different path, winetricks should replace it explicitly. But of course fixing builtin is the preferred solution.
I'm not sure if this is what you meant, but winetricks now copies native ieproxy to system32: https://github.com/Winetricks/winetricks/commit/bd8c584691f66f93bb7e35dab1e4...
Since this is fixed on the winetricks side, I'm marking this bug fixed.
https://bugs.winehq.org/show_bug.cgi?id=44005
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |NOTOURBUG
--- Comment #8 from Gijs Vermeulen gijsvrm@gmail.com --- I think NOTOURBUG is more appropriate here.
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- (In reply to Zebediah Figura from comment #7)
(In reply to Alexandre Julliard from comment #6)
The fakedll shouldn't get registered again once native is installed over it.
It does, because setupapi bypasses the DLL override code completely. (Even using LOAD_LIBRARY_AS_DATAFILE wouldn't work, because that still bypasses the DLL override code).
That's why the file has to be replaced. Dll overrides can be per-application, and can be changed at any time, they can't be relied on for prefix updates.
In general it shouldn't make any difference because the registrations should be compatible between builtin and native. If they aren't it's a bug in builtin.
https://bugs.winehq.org/show_bug.cgi?id=44005
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alexandre Julliard from comment #9)
That's why the file has to be replaced. Dll overrides can be per-application, and can be changed at any time, they can't be relied on for prefix updates.
Sure, that makes sense enough.
In general it shouldn't make any difference because the registrations should be compatible between builtin and native. If they aren't it's a bug in builtin.
Arguably yes, but the problem is that the native path to ieproxy differs between versions.
https://bugs.winehq.org/show_bug.cgi?id=44005
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Zebediah Figura z.figura12@gmail.com --- (In reply to Gijs Vermeulen from comment #8)
I think NOTOURBUG is more appropriate here.
Closing then, as the bug has been fixed upstream.
-
wine-bugs＠winehq.org