In our last few posts on Internet Explorer, we’ve looked at ActiveX Controls. Today we’re going to take a look at the Basics of Browser Helper Objects (BHO’s). We’re not going to cover BHO’s and Security in this post, that will be covered in our next post on BHO’s.
First off, what is a BHO? A BHO is a DLL module designed as an extension to Internet Explorer by allowing customization and added functionality. BHO technology was introduced back in 1997 with the release of Internet Explorer 4.0. Applications that install BHO’s are popular because they allow the application developers to provide features and customizations that enhance their applications. For example, the Windows Live Toolbar (shown below) includes a Browser Helper Object (Windows Live Sign-In Helper). This BHO is a control displayed when you try to log into Windows Live services and helps you log in with multiple Windows Live ID’s on the same machine.
Within IE7, you can view what Browser Helper Objects you have loaded on your machine, as well as which BHO’s are currently running within Internet Explorer by using the Manage Add-ons feature as shown below.
Browser Helper Objects are in-process Component Object Model (COM) components. Whenever you launch an instance of Internet Explorer 4.x and higher, it reads a specific registry key to locate the installed BHO’s and then loads the objects whose CLSID is stored there. It’s important to note that BHO’s are tied to the main browser window. That means that if you open multiple instances of Internet Explorer a new instance of the BHO is created when the new browser window is created. The browser initializes the object and asks it for a certain interface. If the interface is found, then IE uses the methods provided to pass its IUnknown pointer down to the helper object. This process is shown in the diagram on the left.
Due to the COM-based nature of BHO’s, being loaded inside the IE process space doesn’t necessarily mean all that much. Although the BHO can do some potentially useful things such as installing thread-local hooks it is left out from the browser’s core activity. To hook on the browser’s events or to automate it, the BHO needs to establish a privileged and COM-based channel of communication. There is a specific interface (IObjectWithSite) that should be used to get the pointer to IE’s IUnknown interface. The BHO can then store that pointer and query for additional interfaces that it may need.
We mentioned above that the information regarding the installed BHO’s is stored in the registry. The relevant registry key is: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects. If this key exists and there are CLSID’s listed underneath it, then Internet Explorer uses that information to create an instance of each object. The CLSID of the object must be listed as a subkey and not a named value. These registry keys can be created manually although the self-registration of the BHO may create the registry key as well. Again, it’s important to note that multiple copies of the BHO are loaded if you explicitly open new instances of Internet Explorer. Opening a new window from IE is different than launching a new instance of iexplore.exe. When you open new windows from Internet Explorer, each window is duplicated in a new thread without originating a new process – and therefore without reloading BHO’s. By comparison, Windows File Explorer will load a separate BHO instance for each new window that is created.
And that brings us to the end of this overview on the Basics of BHO’s. In our next post on BHO’s we’ll go over Security and how Shell Extensions and BHO’s implement common features.
– Brent Goodpaster