More IE8 Extensibility Improvements

We’ve made a few improvements to our extensibility model in IE8 RC1 based on feedback we’ve received both internally and externally.

WebBrowser (WebOC) Rendering Mode Changes

About a year ago, I posted an entry talking about WebBrowser Control Rendering Modes in IE8. You may recall that applications using the WebBrowser Control (also known as the WebOC, or Trident hosts) can use a Feature Control Key to select the default rendering mode of webpages they load.

Since our release of IE8 Beta 1, we’ve changed the name of the Feature Control Key that is used to toggle that behavior. The key was previously called FEATURE_NATIVE_DOCUMENT_MODE. IE8 now refers to it by the key FEATURE_BROWSER_EMULATION, and the values for both IE7 Standards Mode and IE8 Standards Mode have changed.

For compatibility purposes, the WebBrowser control will run in IE7 Standards Mode by default if no Feature Control Key value is defined for an application.

To run a WebBrowser control in IE8 Standards Mode, use the following new value into the registry:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"MyApplication.exe" = dword 8000 (Hex: 0x1F40)

To run in IE7 Standards Mode, use the following registry value:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"MyApplication.exe" = dword 7000 (Hex: 0x1B58)

For IE8 RTM, we’ve added a new “forced” IE8 Standards Mode value. When an application opts into this mode, the Web Browser control will use the IE8 User-Agent string and Browser Emulation mode strictly. It will also ignore fallback features such as the built-in Compatibility View list and the user-generated Compatibility View list when loading pages. To run in “forced” IE8 Standards Mode, use the following registry value:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"MyApplication.exe" = dword 8888 (Hex: 0x22B8)

In all of these examples, “MyApplication.exe” refers to the name of your application.

Besides the control key name update for RTM, you may have noticed that these values differ from our Beta 1 release. If you are migrating your application from a Beta or RC1 build of IE to RTM, this value chart will help you replace old rendering mode settings:

  IE8 Beta 1 IE8 Beta 2 IE8 RC IE8 RTM
Feature Control Key


IE8 Standards Mode

80000 (0x13880) 8 8

8000 (0x1F40)

IE7 Standards Mode

70000 (0x11170) 7 7

7000 (0x1B58)

IE8 Standards Mode (Forced)

- - - 8888 (0x22B8)

For more information on how this will affect the way your application renders webpages, please refer to my older post, disregarding the old Feature Control Key information. If you would like to learn more about compatibility view and the differences between IE7 and IE8 modes, check out Scott’s post on Compatibility View.

ActiveX Logging Using the Application Compatibility Toolkit

The Application Compatibility Toolkit (ACT) helps customers understand their application compatibility situation by identifying which applications are compatible with Vista, IE7, and IE8, and which require further testing. To aid developers and IT Pros with ActiveX installations, we’ve added logging points for installation, instantiation, and loading of ActiveX controls. This data may help in determining whether or not a control is working properly, and may indicate if Line-of-Business applications need to be updated before IE8 is rolled out in enterprise scenarios.

For more information about how to use the Application Compatibility Toolkit, check out Jatinder’s post here. You can also take the toolkit out for a spin yourself by downloading it from

Deprecation of

A few years back, when ActiveX controls were first emerging as a web technology, Microsoft set up to allow for the distribution of popular controls.

As of IE8, Internet Explorer will no longer check for control installations and updates. From a technical standpoint, this means that the domain was removed from our default CODEBASE lookup locations; when attempting to download a control from webpages, this domain will no longer act as a fallback when no control location is provided or when a provided location fails.

Enterprises using their own codebase download paths will not be affected by this change.

Feedback and Suggestions

I love to hear from developers, IT Pros, and users about feature suggestions, comments, complaints, etc. As always, feel free to email me ( with your thoughts on how we can improve.

Matthew David Crowley
Program Manager
Internet Explorer Extensibility

Update 3/11: Added a sentence indicating that the WebBrowser control runs in IE7 Standards mode by default when there is no Feature Control Key defined.  Also, updated the registry values to indicate they apply in either HKCU or HKLM.

Comments (26)
  1. Florin says:

    In RC1 the IE7 Standards mode is the default rendering mode of the WebBrowser control. Are you going to change this and make IE8 Standards the default rendering mode in the final version of IE 8 or in the future versions of the browser?

  2. mattcrow [msft] says:

    @Florin Yes, IE7 mode is still the default mode for applications; we needed to do this from a compatibility standpoint.  Looking at it from an IE8 and Win7 perspective, we wanted to make sure we didn’t break existing applications that depended on the web browser control.  As new versions of apps are released and legacy ones are replaced, we’ll revisit which mode will be the default one in future versions of IE.

  3. @MattCrow

    Let developers also choose the rendering mode programmatically with a new API in addition to the registry setting.

    We also need APIs for tab management, enable/disable/query the state of InPrivate mode, new event when the user refreshes the page, offical APIs for getting the information form SSL (EV) certificates, etc.

  4. Sheldon says:

    do I read this correctly that I have to set a GLOBAL value for my emulation mode?  e.g. this value will apply to ALL embeded IE instances?

    Shouldn’t this RegKey be "per" application, not assigned per user in the OS?

    Or am I missing something here?

  5. Jeffrey Gilbert says:

    Which mode allows it to function as well as ff 1.0 from a decade ago?

  6. [Update 11/3] IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo

  7. mattcrow [msft] says:

    @Sheldon Yes, this will apply to all embedded IE instances for a given EXE name.  You can assign this key to individual users (HKCU) or to the whole system  (HKLM).

    I wasn’t super clear on those items.  I’ve sent in an update request for this post to clarify.  Thanks for the comments.

  8. 8675309 says:

    so this means donwloadable pogo games might or might not work?

  9. 8675309 says:

    so this means donwloadable pogo games might or might not work?

  10. Ian Boyd says:

    Dogfood IE8 at 120dpi or higher, and live with its slow rendering day after day. See how long it takes you before you can’t stand it, and force IE to run at 100% (96dpi) on a 125% (120dpi) machine.

  11. Giacinto says:

    when are available the final version of ie8?

  12. David says:

    So, when are you guys going to release the official copy of IE8? I was also hoping you guys could find a way to make it render pages faster then it does now. When I open it up sometimes, pages load really fast, then something happens and pages end up loading slow again. I have emptied out my Internet Cache, and that still has not fixed the problem.

    Keep up the good work!

  13. PatriotB says:

    Quite unfortunate that its a per-process setting — and can’t even be set via CoInternetSetFeatureEnabled.

    Unfortunately it looks like WebOCs used by toolbars or extensions in IE *and* Windows Explorer are defaulting to IE8 mode, simply because of the process name.  Why wasn’t this done on a per-WebOC basis?

  14. David W. says:

    I can only pray this interface has been guarded against say, people adding keys for "explorer.exe" and "iexplore.exe".

    Please confirm we won’t suffer another 10 years of abusive apps!

  15. Anonymuos says:

    Microsoft needs to design another extensibility layer for Internet Explorer which allows writing extensions in XAML, XML and JavaScript so lots more free killer and quick extensions can be written. The current compiled/binary extensions model makes development of extensions slow and limited to predefined interfaces.

  16. Aaron says:

    I know its somewhat unimportant, but I found that the ease of use of IE6 far out wieght that of IE7, and used stayed with IE6 just for the purpose of having an easy to use control panel about the address bar. But in IE7 the features I commonly used where moved or taken away, things like the history feature. I haven’t gotten a chance to see IE8, but I think it would be simpler to use if the layout was more similar to IE6 than IE7.

  17. pete.d says:

    The last comment, by Microsoft, found at the blog article "WebBrowser Control Rendering Modes in IE8", claims (and I quote) "We’ve made a few improvements to our extensibility model in IE8 RC1 based on feedback we’ve received"

    Well, you certainly didn’t make improvements to the rendering modes for the WebBrowser control based on the feedback you’ve received.  You got clear, unequivocal feedback that a global settings, that doesn’t even use any sort of signed/unique identifier for the application is an AWFUL strategy, and that we would much prefer a programmatic API with which to control this.

    Even ignoring the issues that have been brought up already, you are completely screwing new applications, which may need to render web pages with different modes, or which need IE8 standards mode in a secure, reliable way, just to preserve backward compatibility.

    Not that backward compatibility isn’t important, but you REALLY need to come up with a better solution.  Such as that already suggested: provide a proper API to control this on a per-instance basis.

  18. pete.d says:

    And yet another reason this registry value thing is flawed: when you run your program in Visual Studio, it’s actually hosted by the "<program name>.vshost.exe" executable. So to get the IE8 standards mode, you need to add both your regular program name, AND the "<program name>.vshost.exe" name to the registry.

    Come on.  You can do better.

    At the very least, get the X-UA-Compatibility "meta" tag to work correctly, so we have _some_ option that’s more reliable and less global than a registry hack.

  19. pete.d says:

    That last comment might have made more sense had another comment I’d posted made it through. In particular, while using the X-UA-Compatibility "meta" tag is documented as an alternative to the registry value, it does not appear to have any effect, at least for me.

    Which is too bad. Injecting a "meta" tag into the HTML is IMHO not great, but still a better approach than setting some registry value. It allows per-document control over the rendering mode, which is almost as good (and in some cases, better) as per-control control, and provides nearly the same benefit (it’s simply less convenient) than an actual API (e.g. new property) in the WebBrowser control.

    But, it doesn’t work, so I’m stuck using the registry value.  YUCK!

  20. jiangsheng says:

    Now Visual C++’s add variable wizard is broken… seems it opted it self in whatever feature IE team provides.

    Is Visual C++ used by the IE team? This is the second time IE’s new feature break Visual C++’s add variable wizard.

  21. I completely second Viktor Krammer and pete.d. Even we had already posted about this on this same blog, on March 28, 2008.

    The application IMHO needs to be able to programmatically choose the compatibility mode at runtime, last but not least because it may be multitasking. Have you never had TWO browser windows open, showing different content? Other API features would also be desirable.

  22. Pissed_developer says:

    MSIE8 in release has broken the Add New Projects wizard for Smart Device Projects in Visual Studio 2008, and removing IE8 restored this functionality.  Needless to say, IE8 will not be placed on any of my systems anytime soon.

    Of course, I know the IE team doesn’t use Visual Studio, preferring Source Depot and the internal MS command line build environment.  That’s fine, but out here in the real world we use VS2008 so fix the problem!

  23. Vyacheslav Lanovets says:

    In fact, I filed a bug today against Visual Studio 2008 that IE8 breaks Smart Devices Wizard. I see this on Vista 64-bit. If anyoone can validate in other environments (like 32-bit), please, validate!

    The reason why I filed that for VS2008 is  because of huge gap I see between qualification of MS developers of desktop tools and MS developers of Windows CE tools. So I beleive this is a bug in Visual Studio 2008 for devices.

    Only because I found solution here I did not spend too much time with this problem.

  24. EricLaw [MSFT] says:

    @Vyacheslav: We’re working with the VS Team to resolve the issue with the VS wizards.  Thanks!

  25. I just tried to do some recherche on how to set the WebBrowser control of Windows Forms to a newer standard than IE 7.

    I did read…/more-ie8-extensibility-improvements.aspx – and my first thought was:

    “This cannot be serious. Binding the behavior to the name of the executable. How can someone do such a crazy thing.”

    This has several serious drawbacks:

    – It will not work out of the box with the visual studio hosting process used for .NET debugging – you also need to add the AppName.vshost.exe to the registry.

    – It will not work when several versions of the same Application are installed. Lots of users have several Versions of Visual Studio or CODESYS installed in parallel. In both cases, newer versions of the application now cannot opt in to newer IE versions because that will most likely break the older versions, as the executable name is the same (CODESYS.exe or devenv.exe).

    – It will not work for plugin architectures (like CODESYS or Visual Studio which have AddOns / Extensions). An AddOn cannot chose a newer rendering version without breaking the host, and the host cannot chose a newer rendering version without breaking older AddOns.

    – It will not work for interpreted languages like IronPython, where the executable name is always ipy.exe or ipyw.exe. Other runtime environments have a similar behavior (e. g. java(w).exe, perl.exe etc.).

    So why in the world did you choose a registry key (which is also slow to lookup) instead of just a method / property one calls to set the IE version before loading the page?

Comments are closed.

Skip to main content