Browser Wars 2.0 - the Plug-in

March 23rd, 2010

0

If browser vendors believe he who has the most plugins wins BrowserWars 2.0 then make it easy for developers to write and distribute plugins. Chrome and Firefox do this:
• Both use javascript as the plug-in Lingua Franca.
• Both compete on providing the most powerful javascript engine in a browser;
• Both make it easy for developers to add plug-ins to browsers.

All browsers run javascript the difference being which runs it fastest. And Google’s hegemony is powerful – if Google is focused on plugins then you need to check it out.

Microsoft does not maker it easy to write up a plugin:
• You write a dll;
• You register the dll so IE can find and load it.
• You write unmanaged code or you’ll need interops to hook the browser.

Nonetheless it can be done. in .Net. We will show you how.

Client-side Javascript Includes:

Most web sites include javascript scripts in their web-pages. The ‘script’ downloads along side of the markup and images when you visit a page. When the user leaves the page the javascript functions are also left behind. The next site gets to download it’s own script.

Browser-resident javascript:

When a user ‘installs’ a browser plug-in, and then starts her browser, the browser loads the ‘plugin’ code even before it loads the user’s home page.
• FireFox allows plugin developers to load their javascript from a XUL ‘super page’. The script loads at the the same level as the browser’s menus and frames. It stays resident along with the menus as the user surfs from page to page.
• Chrome provides a code-behind super-page for plugin developers to attach a load-and-stay-resident script at browser startup. It stays resident in the code-behind as the user surfs from site to site.
• Not so with Microsoft Internet Explorer – Microsoft’s requires a dll known as a Browser Helper Object – a “BHO”. The dll must be registered using a unique GUID to be accessible to Windows. The GUID must then be added to the “Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Browser Helper Objects” key. When the user starts IE the IE Windows process loads the dll. The dll code stays resident running inside IE’s Window’s process.

Writing an MS BHO:

You can combine c# managed code with the webbrowser COM object to implement your own BHO. A small amount of boiler-plate in your dll and a few system settings will free you up to focus on your plugin’s features and functions using C#. Let’s get past the boiler plate and system settings first so you can get down to business.

There are 2 Windows APIs most Microsoft shops are used to:
• The older 32 bit ‘Win32 API unmanaged’ code frameworks.
• The newer object-oriented ‘Dot.Net managed’ code frameworks.

COM objects – such as the “webbrowser” COM object used in Internet Explorer – were mostly created in Windows using the 32bit Windows API. COM objects typically provide ‘interfaces’ to for you to program against.

.Net runs C# at the Common Intermediate Language “IL” level – an object-oriented assembly language outputs byte code that runs on a virtual machine, much like Java’s JVM. .Net provides objects to program against.

To use .Net’s c# language and internet explorer’s webbrowser COM object you have to ‘inter-operate’ between C#‘s managed code and the webbrowser COM’s unmanaged code – Microsoft “InterOp” wrap types to make them compatible between frameworks.

Our ‘boiler-plate’ implementation of a windows BHO plugin will:
1. Program a .net dll assembly that exposes itself to COM.
2. Register our assembly exposing it’s public classes to Windows.
3. Set our windows registry to tell IE to load the BHO assembly when it starts up..

Why Windows:

Border Stylo is a *nix shop biased towards open-source technologies. Like all businesses we have a strategic requirement to serve the broadest possible audience. I focus on Windows development at Border Stylo. Programming for Windows IE could extend our plugin utilization to 60% of the browser user population who otherwise would not be exposed to it.

Simple Sample Windows BHO:

You could easily use a text editor, command-line compiler and .net registry functions to write a simple sample BHO. This simple sample uses VS 2008. Visual Studio includes powerful debugging, object browsing and ‘intellisence’ utilities. MS provides time-limited versions of Visual Studio you can download for free.

We will set the registry keys manually and use VS2008 and C# to compose our first BHO.

Create the project:

Use the name ‘smplBHO’ for this project. Create a VS2008 C# “Class Library” project “smplBHO” in a new folder in your root_drive:\smplBHO:

In VS 2008 naming the project smplBHO and locating it in the root drive – mine is “c:\” – creates a folder C:\smplBHO for your project files and a folder “C:\smplBHO\bin\Debug” for your compiled debuggable output “smplBHO.dll”.

We’ll write a class that uses the System.Windows.Forms namespace. System.Windows.Forms gives us access an the ‘alert’ function via the ‘messagebox’ object’s .show()’ method.
1. Add a reference to System.Windows.Forms assembly to your project.

In the Solution Explorer right-click on References→Add Reference and under the .Net tab find System.Windows.Forms. This assembly will find it’s way into the project’s build via ‘makes’ in your .csproj project file.

2. Use the messagebox.show() function to popup a “hello world” message.
System.Windows.Forms.MessageBox(“hello world smplBHO”);

We’ll need to give our class some COM-visibility attributes so Windows can see it and a unique GUID so IE can find it in the registry. Then we can register the class publicly, and register the class’s GUID as a BHO, and popup our “hello world” message when IE starts. Use the ‘create GUID’ tool in VS or generate a guid from the command line “guidgen” utility. Replace mine below with yours (or try mine – it should be unique on your machine…).

• VS studio automatically adds some includes when we create a “class library” dll project.
• VS automatically declares a namespace using the project’s name.
• We’ll add another include ‘System.Runtime.InteropServices’ (from the mscorlib.dll assembly) to help us marshal calls between IE and our c# code.
• We’ll add a public class ‘classBHO’ with a constructor that pops up a windows meassagebox when it is instantiated. The class must marked ‘public’ to expose it externally:

Build the code and you should see ‘smplBHO.dll’ in the C:\smplBHO\bin\Debug\ directory.

You can easily register the assembly C:\smplBHO\bin\Debug\smplBHO.dll exposing the public class by it’s GUID for general access using the “regasm.exe” utility:
• “regasm /codebase C:\smplBHO\bin\Debug\ smplBHO.dll”

The /codebase parameter will register the dll at this location instead of putting it in the GAC (Global Assembly Cache). You’ll get some warnings but the response should end with “Types registered successfully”. For our simple sample we will avoid strong names and the GAC – every time we recompile we’ll be able to use the new compilation at this location without worrying about strong-name rules.

Now that we’ve registered this assembly using ‘regasm’ you can find your GUID (mine is “2216CCD9-9C53-4081-87D4-4BE181FE8979”) for smplBHO.classBHO in the HKEY_LOCAL_MACHINE\Software\Classes\Clsid key. Objects in the HKEY_LOCAL_MACHINE hive are available to any user on the local machine – ie anyone who uses IE on your local machine.

Let’s add this class to the registry key where IE looks for add-ons when it starts up. Use the “regedit” utility:
• Start → Run → enter “Regedit”
• Navigate to the “HKEY_LOCAL_MACHINE\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Browser Helper Objects” key.
• right-click and select “new → key” and paste in the GUID of your Class:

Notice I pasted in my GUID above “{2216CCD9-9C53-4081-87D4-4BE181FE8979}”. You should paste in yours.

Start up Internet Explorer and before it loads anything your alert should pop up:

The process is a bit contorted, certainly not as friendly as FireFox or Chrome, but a plugin developer can’t afford to ignore 2/3s of the population. The good news is you’ve plugged in the windows shell requirements – now you can focus on playing with your plugin.in C#. It’s as simple as recompiling. To demonstrate let’s recompile our BHO with a new message – simply replace:

System.Windows.Forms.MessageBox.Show(“hello world smplBHO”);
with System.Windows.Forms.MessageBox.Show(“goodbye smplBHO”);

and recompile.

Caveat: All syntax and capitalization are subject to mistypes!

You’ve done the hard work, now you can play. Try some of the ideas below.

Goodbye smpBHO. – nmurray@BorderStylo.com

Addendum – BHO stuff

• SHDocVW.dll defines interfaces that expose the webbrowser shell. The webbrowser shell can navigate and host web-pages.
• mshtml.dll defines interfaces to HTML objects – the elements and events hosted by a web-page.

Tagged with: browser, plugin, javascript

Related Posts

• Poor Man's Webspider
• YAJ: Yet Another Javascript?
• Javascript dependency management made easy like Sunday morning
• The Many Flavors of Curry

Author