My First Chrome Extension

January 8, 2010 2 Comments

I am fairly hooked on Microsoft Outlook and I like to use the RSS reader function. I also have been living in Chrome 4 instead of Firefox for a few weeks now. One of the features of Firefox and IE is the ability to discover RSS and ATOM feeds and pass them to the registered feed reader.

Google has an extension for Chrome that almost does what I want. It discovers the feeds but it will only subscribe them with a web-based feed reader. What I did was hack on the RSS Subscriptions Extension (by Google) so that it would work with Outlook.

screen-shot

Outlook feeds by registering itself as the handler for the FEED scheme.

hkcr-scheme

That means anything that tries to invoke a URI like feed://somewhere.com/feed.rss, Outlook will be invoked with the /share switch like this:

"C:\PROGRA~1\MICROS~2\Office14\OUTLOOK.EXE"/share "feed://somewhere.com/feed.rss”

Outlook is very picky about the scheme on the URL. It has to be feed:// or it won’t work and that is the problem with the Google extension. It always puts the http:// scheme onto the URL and it assumes that you are going to embed this into a larger querystring to a web-based feed aggregator.

It was pretty easy to tweak the extension to do what I wanted. The meat of the change is really just one line of code:

url = url.replace( "%f", feedUrl.replace( "http:", "feed:" ) );

That makes it so that %f is a feed: scheme URI that will invoke the registered feed handler. For me this is Outlook 2010.

edit-shot

There is a little bit of supporting stuff here and there to make this work, but that’s the gist. Now, %f is the magic configuration to invoke the registered feed:// scheme application. It was surprisingly easy to get hacking on the extension and Google made it very easy to publish my work.

If this scratches your itch, you can get it from Chrome Extensions site.

Advertisement

Filed under Uncategorized Tagged with , , , , ,

Raymond Chen answers my question

January 5, 2010 Leave a comment

Nearly four years ago, I asked Raymond Chen why Microsoft has continued to use cryptic 8.3 filenames in Windows even though long filenames have been supported for many years. I wasn’t paying attention when Raymond answered me a year later. I just stumbled across this today.

Commenter Brian Reiter asks a duplicate of a question that was already submitted to the Suggestion Box: Darren asks why operating system† files still (for the most part) adhere to the old 8.3 naming convention.

It comes down to a handful of interesting reasons:

  1. Once a name is chosen, it can’t be changed for reasons of backwards compatibility with applications that may load a system DLL or invoke a system executable.
  2. By default all long file names are given a short file name. Loading a DLL by reference to a short and long file name into a program will yield two separate references of the DLL in memory.
  3. 8.3 filenames are know to work. If it ain’t broke, don’t fix it. Also, a related point here is that the system component installer technology in Windows XP and prior could only support 8.3 filenames. Pretty much any system component developed prior to Vista had to have 8.3 filenames. That includes some components developed for Vista while the new installer system was under development. (There a

My original question was why does the Framework Design Guidelines for .NET applications specify a totally different naming. The gist is that while native code and legacy components have the gotchas above, .NET assemblies are different because they have additional metadata including version number and public key token. In order to dynamically load an assembly, you either need to know its strong name or its full path and filename. There is very little chance of accidentally loading the wrong assembly unless you are the one building and signing the assemblies in question.

Filed under Uncategorized Tagged with , , , , ,

Newer posts →

%d bloggers like this: