grack.com

I’ve managed to replace the built-in IE control in SharpReader with a nice, fast Mozilla ActiveX control.  There’s a few easy steps to follow to get this working:

1. Stop SharpReader.
2. Download and install the Mozilla ActiveX control: MozillaControl.exe (5 MB).
3. Rename the file AxInterop.SHDocVw.dll to AxInterop.SHDocVw.dll.old.
4. Extract the new AxInterop.SHDocVw.dll file from here: (download no longer available) (11 KB).

That’s it- when you start SharpReader, you’ll see a nice Mozilla window instead of IE.  To test if it works, right-click the page and select “Properties”.  You’ll see a Mozilla-style window like this if everything worked:

Can you tell this application is running Mozilla?  :)

Please note that this officially a hack and is not supported by either myself or Luke Hutteman.  Have fun!

For those of you writing Visual Studio.NET 2003 add-ins in C# (or any other .NET-enabled language), you might have noticed that CreateToolWindow doesn’t really work with real .NET controls.  Fortunately, this piece of code fixes this problem.  It’s a bit of hack, but it works for me so far and was created by using Reflector to figure out exactly what was going on.

// Run this code before any CreateToolWindow calls
Type tp = typeof( System.Windows.Forms.Control );
tp = tp.GetNestedType( "ActiveXImpl", BindingFlags.NonPublic );
FieldInfo fi = 
    tp.GetField( "globalActiveXCount", BindingFlags.Static | BindingFlags.NonPublic );
fi.SetValue( null, Convert.ToInt32( fi.GetValue( null ) ) + 1 );

I’m not sure if Craig Skibo would approve of this work-around, but it’s way easier (and cleaner, IMHO) than using that nasty shim control. If you want to figure out how this works, read my posting to the vsnetaddins Yahoo! group.

In his latest post about RSS, Robert Scoble says:

“Now, imagine a new syndication format that brought up a page that showed what a news aggregator was, and explained how the system worked and why it’s more productive.”

My challenge: create a plug-in XSL file that works with RSS to explain to the user what RSS is and point him at a application to read RSS.

This is actually a fairly easy task.  XSL can be plugged into any arbitrary XML file via something called a processing instruction.  In the XML file, these appear as tags of the form:

<?some-processing-instruction some-attribute="some-value"?>  

There is a special processing instruction that ties an XSL transformation stylesheet to an XML document:

<?xml-stylesheet link="stylesheet.xsl" type="text/xsl"?>

Once the XML file was pointed at an XSL file, the next task was creating a quick-and-dirty XSLT transformation that picks out various bits from the RSS feed itself to create a customized-looking HTML page. You can see my XSLT file here: rss.xsl.

It turns out that my hosting provider isn’t set up out-of-the-box to serve XSLT files with the correct MIME type for Mozilla/Firebird to pick up. It’s likely that a few hosting providers aren’t set up correctly for this. It’s easily fixed, however, by adding a simple .htaccess file to the root of your site:

AddType text/xml .xsl

This .htaccess file sets up the correct XML mime-type mapping for .xsl files, allowing correct operation under Mozilla.

Works well, explains what is available and shows the user what they need to do. I’m sure more features could be added.

I have no idea how you might get this into something like Radio Userland, however.

Mental note: FreeTextBox looks really cool.  This would be a great addition to TWiki.

Robert Scoble has written a short response to my previous article.  His first question:

Serving files is one thing. But how much of the “WinFS experience” (which is quite cool) should be shared with older or non-Longhorn OS’s?

Good question, though not really one anyone but Microsoft can answer.  Without interoperability, WinFS isn’t much use to me, personally.

His second question:

Here’s the important question: why? What is the “win-win” for investing the time and work to give these to a standards body? How will Microsoft recoup its investment? Remember, at the end of the day, Microsoft is a business and needs to see a return on investment.

Well, the web was built on standards.  Heck, it was built before Microsoft decided it wanted in.  It’s a standardized, shared protocol (well, if you don’t count all the vender-specific bugs and additions) that we all use to communicate.  It’s gained a fair amount of traction and popularity.  Some of the comments on Robert’s story here indicate that this is a view shared by many:

The difference between tcp/ip and the dozens of competing network protocols is standards, and the commitment to make things work together. IBM had a bigger internal network than the Internet for a *long* time – where is it now? Incompatible and dead. Novell made a fortune off of it’s own network protocol. Where is it now? Incompatible and dead.

Oh yeah.  There’s also the matter of Microsoft’s massive war chest.  Why not use some of that war chest to manoeuvre the company into a healthy competitive position, rather than the monopolistic giant it is now?  This is an illustration of Microsoft’s profit from their latest SEC filing, care of The Inquirer and groklaw:

The Server and Tools unit had costs of $1496 million and generated $370 million, a 24.7% profit.

The Information Worker units, responsible for application software, had costs of just $696 million and that generated $1591 million, a profit of 228.6% of the money they spent.

The grand-daddy of them all was the unit responsible for Windows. It had costs of just $545 million but generated a profit of $2264 million, a staggering 415.4% profit on the money they put into it.

Staggering indeed.  Makes you wonder why they worry about “what’s in it for Microsoft?”