Note: The “brain dump” series is akin to what the support.microsoft.com team calls “Fast Publish” articles—namely, things that are published quickly, without the usual level of polish, triple-checking, etc. I expect that these posts will contain errors, but I also expect them to be mostly correct. I’m writing these up this way now because they’ve been in my “Important things to write about” queue for ~5 years. Alas, these topics are so broad and intricate that a proper treatment would take far more time than I have available at the moment.
There are a few notable changes in Win8/Internet Explorer 10’s behavior when it comes to ActiveX controls.
1. The non-Desktop mode of the browser (let’s call it IEPKaM for lack of a better name) only permits instantiation of controls that are considered to be a part of the web platform. The list of permitted objects is hardcoded into Internet Explorer and consists of:
|IE XMLDocument||Not registered – used when hosting XML|
|IE SVGDocument||Not registered – used when hosting SVG|
|IE XHTMLDocument||Not registered - – used when hosting XHTML|
IEPKaM blocks other forms of extensibility outright: toolbars, BHOs, Pluggable Protocols, MIME Filters, and Namespace handlers will not load in IEPKaM.
3. When enabled, IE’s ActiveX Filter permits use the controls listed above, except Adobe Flash, which is still filtered. This enhancement makes ActiveX Filtering far more palatable, as it doesn’t block use of legacy objects like the ActiveX version of the XMLHTTPRequest control.
4. Windows RT devices like the Microsoft Surface cannot download or install ActiveX controls.
- Windows RT’s ActiveX restrictions are additionally backed by the OS loader, which will refuse to run code that hasn’t been signed with a particular code-signing certificate.
- Installed controls that are a part of Windows RT are permitted to run in the Desktop experience.
- In the IEPKaM experience, the list above is still consulted before a control is permitted to load.
5. When the Enhanced Protected Mode feature is enabled, controls will not load unless they have been compiled for 64bit (when run on 64bit Windows). When running on Windows 8, there is the additional requirement that the controls are listed in the CATID_AppContainerCompatible component category, indicating that they have been tested to work properly within AppContainers.
For instance, the controls must not expect to perform a non-brokered read of the local disk or registry; instead, such operations must be conducted on the control’s behalf by a registered broker object running at Medium Integrity. In some cases (like writing to a file), the IE Protected Mode APIs will suffice, but IE10 does not include any new Read brokers, so if your control hopes to read an arbitrary file from disk, you’ll need to write your own broker.
6. IE10 enables Enhanced Memory Protections like ForceASLR, which opts all loaded modules into address space randomization, regardless of whether the /DynamicBase flag was set. You should continue to set this flag directly, but be aware that your control cannot take dependencies on fixed module load addresses even if you fail to do so.