views:

203

answers:

2
+1  Q: 

Embed IE6 with MFC

Hi guys,

I'm looking to use the "Microsoft Web Browser" ActiveX control in an MFC app, but we need it to be IE6 in order to support legacy stuff and all that not-so-fun stuff. The systems that it will be deployed upon, however, may have IE7 or IE8 installed.

I'm not much of a COM/ActiveX guy, although I know my way around C++ and MFC. I've been reading about and playing around with DLL redirection and SxS DLLs over the past few days, but they haven't gotten me very far (in fact, I believe MSDN mentions SxS doesn't work with system-protected DLLs or OCX files).

I found the IE deployment kit builder and was hoping that I could utilize that in combination with DLL redirection, but to this point have had little luck. I would truly appreciate it if anyone could help.

Thank you!

Nathan

A: 

There used to be a "Multiple IE" installer that would hack things on Windows XP to allow multiple versions of IE to coexist. It has been discontinued for a while, as the page notes:

Multiple IE is no longer maintained and there are no plans to continue maintaining it!

The tactic also apparently resulted in random IE crashes, only worked on Windows XP, and was broken (at least once) by a Windows update.


Instead of trying to hack together a similar solution (which appears to be quite brittle, and will likely be a pain to keep patched with the latest security fixes), it might be easier to consider a completely different approach to the problem:

Fix the Cause:

  • Fix/upgrade the underlying legacy code. You may gain compatibility with other, more recent, standards-based browsers as a nice bonus. (Admittedly, this is sometimes not a possible approach.)

Control the Environment:

  • Set up a virtual machine running Windows XP with IE6. With a VM, you can ensure the required environment in a stable, tested configuration. There are deployment/integration tools that might be useful as well (users don't necessarily have to know that the app is running in a completely separate instance of Windows XP).

Go Crazy, but (Slightly More) Maintainable*:

  • If you can't fix the underlying legacy stuff, it probably isn't being changed much either. Figure out how to actually fix it, and patch it "on-the-fly" to ensure IE7/IE8 compatibility. (i.e. Edit the scripts/CSS/page content/formatting/etc. to resolve issues after it's downloaded, but before the browser engine renders it.)

*(Than trying to get multiple versions of IE working together.)

Those are just ideas, but hopefully they help inspire something useful. Good luck.

breakingobstacles
Thanks for responding. I had played around with multiple IE already, and it does concern me that it doesn't work on Vista at all. I was hoping maybe it was due to something other than the DLL interoperability, but I guess that might be wishful thinking. ;)Unfortunately, I don't have access to the legacy stuff to fix it, so solution A just isn't possible. The VM also isn't practical given how often the legacy stuff gets used, and given the people who use it. The third option is a valid point, although it seems ridiculous if that's the easiest way. ;)Thanks for your response nonetheless!
Nathan
A: 

A Webbrowser ActiveX Control, when in Quirks mode, will use the old IE5 (!) rendering. (see IEBlog for details - the quirks/standards distinction applies in IE[6-8]) You mentioned "legacy stuff" - from that I assume not-so-valid pages, and therefore Quirks mode.

What that means: Embedded controls, for pages that are not standards-compliant (most legacy stuff isn't), will use the old IE5 Quirks mode rendering, even in IE8. To test your code in them, you can use the MS Internet Explorer Application Compatibility VPC Images - a set of disk images for Virtual PC (free as in beer) with IE6,7, and 8 respectively installed.

I'm developing new features for such legacy applications, and all the three browsers behave the same way when in Quirks mode (IE8 has some very minor quirks-mode quirks, but those can be worked around easily).

Piskvor
Hey, thanks for the response. In our case, it's a situation where the application uses browser sniffing to determine whether it's IE6 (one of those == instead >= lack-of-foresight situations), so unfortunately it actually needs to be IE6. Thanks for taking the time to answer, though. :)
Nathan