[Bug 44005] New: ieproxy registration breaks Internet Explorer 8
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(a)winehq.org Reporter: piotr.caban(a)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(a)codeweavers.com> Date: Thu Aug 10 13:52:31 2017 -0500 ieproxy: Add proxy/stub for IInternetExplorerManager. Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |448ac0e9c439c5a8095e2e8a150 | |997caebcb32ab -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |austinenglish(a)gmail.com, | |jacek(a)codeweavers.com, | |z.figura12(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #1 from Piotr Caban <piotr.caban(a)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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #2 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Qwerty Chouskie <asdfghrbljzmkd(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asdfghrbljzmkd(a)outlook.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ieframe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #3 from Qwerty Chouskie <asdfghrbljzmkd(a)outlook.com> --- Any chances of this getting fixed soon? This breaks a lot of software. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #4 from Zebediah Figura <z.figura12(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #5 from Zebediah Figura <z.figura12(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #6 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |NOTOURBUG --- Comment #8 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- I think NOTOURBUG is more appropriate here. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #9 from Alexandre Julliard <julliard(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 --- Comment #10 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44005 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org