I’ve released my first add-on for Internet Explorer and I’ve almost finished a second one. Developing for Internet Explorer was a very different experience than developing for the other browsers I’ve worked with before – Firefox, Firefox Mobile, Google Chrome, Safari and Opera.
Overall Architecture
Internet Explorer extensions are called Browser Helper Objects (BHO). They are libraries (DLL) implementing a specific interface. They must be registered as a BHO through a registry key in order to be used by Internet Explorer.
The BHO is loaded per tab or window, meaning there is no built-in communication between tabs/windows. BHOs can interact with the browser and the document through native code or injected JavaScript.
BHOs can be written in C++, C# or VB.Net. Since I’m most familiar with C#, this is the language I’ve used. Unfortunately, there are many limitations with .Net based BHOs:
- The BHO name, displayed in the Internet Explorer “Manage Add-on” page, displays the namespace of the application. I could not therefore display “Zscaler Safe Shopping”, so I had to cheat and use Zscaler as the namespace, and SafeShopping as the main class name to display “Zscaler.SafeShopping“.
- Many important functions are not implemented in C# and unmanaged C++ code has to be imported.
- Internet Explorer is very picky about performance – if an add-on takes more then 0.20 seconds to load, IE suggests to users that they disable the plugin (see more details below). Due to the fact that .Net add-ons require IE to load the .Net framework, it is pretty much impossible to stay below this limit.
Because the extensions are comprised of compiled code, I could not download extensions to check out their source code as examples, unlike extensions for other browsers, which are written in JavaScript. In addition, Microsoft has only high-level documentation about BHOs and very few code examples (with most leveraging C++).
Protected mode
Starting with Windows Vista and Internet Explorer 7, Internet Explorer works in Protected Mode by default. This means BHOs are limited in the places they can read/write to disk and read/write to the registry. You need to call special functions to know where you are allowed to write to the disk, but these functions are available in C++ only. I had to use a mix of hardcoded values and unmanaged C++ DLL import to add all necessary functionality.
Because there are no built-in debugging functions to understand what is going on inside the extension, and limited documentation from Microsoft, it took me quite a while to understand how to deal with Protected Mode.
Inconsistent environments
On other platforms, extensions are relatively compatible between browser versions and operating systems. With Firefox extensions, for example, it doesn’t matter if the browser is running on Linux, Windows 95 or Mac OS X. These browsers are also very good at maintaining forward compatibility: extensions working on one version usually work fine on newer versions of the same browser. Internet Explorer is a different beast.
Some of the API belongs to the Windows OS, while other portions belong to Internet Explorer. For example, Protected Mode exists on IE 7 on Windows Vista, but not on Windows XP. The API to manage disk access is also different on the two OSs. Calling Windows Vista’s API will crash Internet Explorer on Windows XP, for example. Add-ons are definitely not forward compatible.
Some API calls also get “randomly” broken. For example, the event BeforeNavigate2 is broken on Windows 7. This was reported during for Release Candidates, but never fixed and the event is not triggered anymore.
No love for extensions
Microsoft does not seem to have much love for browser extensions. In fact, I think they actually hate them!
There is no good website to download IE extensions. The official Microsoft website, Internet Explorer Gallery, contains very few extensions. Add-ons are not even shown on the front page, instead they promote pinned sites (introduced with IE 9)
Developers don’t get much love either. In addition to the problems and limitations listed above, the add-on infrastructure in Internet Explorer is very weak. Developers have to write their own installer to install and register their BHOs. They also have to write the uninstaller, as IE lets users disabled BHOs, but not uninstall them. There is no simple way of adding an option page for to configure the extension either.
If this was not enough to discourage add-on developers, IE regularly asks users whether they want to uninstall add-ons. Even if all add-ons are loading under 0.200 seconds, Internet Explorer still suggests that the add-ons be disabled to improve the start up time!
A Bad Reputation
BHO is a dirty word. If you look for BHO in Google, most search results are about how to remove malware installed as a BHO.
Users are also more wary, as they should be, of downloading executables that must be executed outside of their browser, and require Admin rights to register themselves, as opposed to Firefox .xpi files, which are handled entirely inside the browser.
References
If I have not yet discouraged you to write a .Net BHO, here are a couple of references I used:
- StackOverflow: the BHO tag has only 249 questions, but still a good source of information
- The Code Project has several tutorials and code samples
- vcsjones with 5 blog posts about managed BHO
- Free VPC images to test your add-on different versions of Windows and Internet Explorer
- MSDN documentation of the WebBrowser class
Leave a reply
