Windows Live programs can’t be installed on this operating system

Blogging Software, Computing No Comments »

My Microsoft Annoyance du Jour: Trying to download Live Writer Beta 3 from any computer located in Thailand will bring up a Thai download screen. While I have problem with the Thai page as such I’m not too keen on having the Thai version of the program with all dialogs and help in Thai but this is the only choice:







There is no option to choose another language, and every browser I tested (Opera, IE6, Firefox 1.5) will not let me download the US-English version regardless of browser language settings. I presume this is localization going overboard at Microsoft because there are speakers of many different languages in most countries, including this one. Anyway, here is a download link for the US-English version of Live Writer Beta 3

Happy having found the link, MS delivers another blow (they’re good at that):


I’m running Windows Server 2003 and Windows Live Writer Beta 3 (unlike Beta 2) only supports 32-bit Vista (64-bit hacked, get your hex editor ready to install Live stuff) and XP SP2. Bummer. Microsoft continues the practice of forcing users to upgrade to a newer OS by means of getting users hooked on free MS offerings.
It’s now practically impossible to get a MSN Messenger client for Windows 2000 as older clients are denied entry to the service. I know, I know, Win2K is not supported anymore. But this is no justification for forcing users out of a service they’re used to and have built contacts on if they don’t want to upgrade their OS. Besides that, most Live offerings (especially Messenger) have gone from lightweight and functional to the MS-typical buggy bloat (read some comments), with Liver Writer being the exception. For now I’ll be using Beta 2 while looking at ScribeFire and not hold my breath for any Live offering supporting my OS. 

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Pretty WordPress Permalinks on IIS 6 Shared Hosting

Blogging Software 7 Comments »

We all want pretty and search-engine friendly URLs for our blog posts. The most common format is /%year%/%monthnum%/%day%/%postname%/ as it gives users and search engines optimal information about the topic and the month of the post (er, you might want to check out the URL of this post for an example).

As it turns out, having WordPress generate such URLs is possible on IIS 6 in a shared hosting environment without much effort and there is no need to move to an Apache host with mod_rewrite etc.

The “official” procedure recommended by WordPress is here. It entails editing your Windows Server’s php.ini file. However, most shared-hosting companies (I currently use Crystaltech) will not do this for the entire server just so that your blog can have pretty URLs.

There’s a much easier way:

  1. Create a text file in the root of your blog and name it php.ini. Paste the following two lines:
    cgi.fix_pathinfo = 1
    cgi.force_redirect = 0
  2. Then simply change the permalink structure in your WordPress control panel to:

To get rid of the leading “/index.php/” -which will make it easier to move to another blog engine such as Typo later-;) follow these additional steps:

  1. Download the WordPress – Remove Index.php from Permalinks in IIS Plugin (scroll down), and install it into wordpress (upload to /wp-content/plugins/ folder, then Activate from WordPress control panel).
  2. Change the default 404 error page of your IIS site. Most web hosting companies will offer a web form to accomplish this. At Crystaltech it looks like so:image
    Set the 404 error URL to “/index.php” or the root URL of you blog such as “/blog/index.php”. Then change the permalink structure to /%year%/%monthnum%/%day%/%postname%/.
    Hope it helps.
[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Moving to WordPress from DasBlog/ThinkJot

ASP.NET, Blogging Software 2 Comments »

Those looking for ASP.NET-driven blog engines will have a similar experience as those seeking ASP.NET driven discussion boards or Wiki applications: The choices are few and far between, and newer projects are rather immature and buggy. Compare this to the offerings available on the LAMP/PHP stack (WordPress), or even for CGI/Perl (Movable Type), the options are much more mature and varied.

The Problem with ASP.NET 2.0

What are the reasons for this dearth in the ASP.NET field? After almost two years after its release it has become clear that ASP.NET 2.0 was quite disruptive for developers, not only those moving from ASP.NET 1.1 but also those starting afresh with 2.0: The much anticipated new version more than ever emphasises configuration over convention, making it harder to get up to speed in development. It also offers more ways of doing things, causing developer anxiety about best practices, security issues, personalization, localization etc. Add to that the slowness and relative (compared to VS 2003) buggyness of Visual Studio 2005 and it’s conceivable that ASP.NET has hurt developer productivity. The platform is so feature rich (read: bloated) that more and more developers are looking to simplify things, with projects like SubSonic (whose approach would have violated three-tier best practices not long ago) and the like (Monorail, NHibernate etc.) or by moving to Ruby on Rails entirely. And as if the built-in bloat isn’t enough we recently had the platform extended with Web Application Projects, AJAX (RoR has it built in), and the whole ASP.NET 3.5/C# 3.0/LINQ/Silverlight/Orcas smorgasbord that is looming towards the end of the year. This again leads to a wait-and-see approach with developers who are frantically listening and learning the new technologies and new apps such as the Expression Studio Stuff, and yes, IronPython, IronRuby, CSS, AJAX, JavaScript, Flex etc. I’m sure quite a few projects out there are not proceeding as fast as they should because of the current maelstrom of new technologies released in the wake of the Web 2.0 hype.
All the while PHP developers have taken the move to PHP 5 in their stride (with a one year head start over ASP.NET 2.0) and they now have quite a mature platform which they can bring to bear against ASP.NET’s technological superiority and feature-richness. With The Ruby on Rails ”innovation” is also going more slowly, especially with fewer big announcements, which soothing for developers.

Right now ASP.NET looks more and more like the new J2EE. And not in a good way.

ASP.NET 2.0 Blog Engines

DasBlog is still the primary ASP.NET blog engine and is now under more active development than it had been in the past. An ASP.NET 2.0 Medium Trust compatible version should be available REAL SOON NOW. As for other choices, .TEXT was incorporated into Community Server and forked into SubText.

For want of Medium Trust in the best engine DasBlog I had been using ThinkJot (a controversial DasBlog fork) since the start of this blog and was quite content with it. I’m just missing the modularity, maturity and community support of the most most prominent blogging app on the market, which is WordPress. Yep, and the prettiness of the themes didn’t make this choice any harder…

Wanting to stay with an ASP.NET offering at first I had a look at Blogengine.NET and found it promising but a little immature and spotty in support of Unicode. However, development of this project is going rapidly so you might wanna check it out. There is another project out there, an ASP.NET blog engine driven by Subsonic which sounds like a good match. However, the project is not nearing completion as of now.

Making the Move to WordPress

So, back to WordPress. As my hosting provider Crystaltech supports MySQL and PHP even on the cheapest hosting plan, I foresaw few issues with the migration and indeed it all went quite smoothly.

Here are some pointers as to the procedure I would recommend:

  1. DO NOT DELETE or modify your old blog, rather back it up with FTP to your local machine.
  2. Download WordPress and unpack it into a directory on your local hard drive (such as C:\Wordpress).
  3. Create a MySQL database to host the app on your remote (hosting) server.
  4. Download SQLyog if you haven’t already done so do manage and monitor your remote MySQL database. The community edition is free.
  5. Edit the <Wordpress>/wp_config.php file to reflect the connection information of your remote database.
  6. Upload all files in the WordPress directory to your remote web server. YOU DO NOT have to upload the files to the root directory, it might be more maintainable to create a directory on the remote server, name it /wordpress or sth. and upload the files to this directory.
  7. Run /<install dir>/wp_admin/install.php which will guide through the installation in just two steps. It is essential here that the e-mail address you enter exists and is registered with your mail server. If the address does not exist, the installation will abort without any verbose error message and you’ll have to start over, dropping the tables from the database (using SQLyog) etc.
    The table structure will look like this in SQLyog:
  8. The installation will generate a password which will be displayed in the browser in step 2 of the installation. Note this password.
  9. You can now configure your application at <blog path>/wp-admin/, especially this process if you haven’t uploaded the WordPress files to your root directory and still want the blog in your root.

Working with Windows Live Writer

Read this first, before you import your data! Aside from Blogjet, the blog editor with the most promise these days (for the Windows platform) is arguably Windows Live Writer. Since the Beta 2 version which is snappy and feature-rich at the same time, everybody should check out this app. It’s free too. Then again it’s still Microsoft software which causes problems as usual…
After a few trials importing my data I actually thought I had a WordPress bug on my hand. Of course it wasn’t, the problems the problems were caused by a Microsoft app, Liver Writer. The usual suspects…
There are (at least) two issues with the Live Writer/Wordpress match that you should be aware of before importing your data.

Unicode Bug

The first is the Unicode support. Live Writer supports Unicode (UTF-8) as do PHP and MySQL, but Live Writer has an issue with needlessly prepending a byte-order mark:

Here is the workaround:

Non-ASCII characters render incorrectly on UTF-8 encoded blogs

Description: On WordPress 2.1+ and PHP versions older than 5.0.2, publishing posts using Writer results in non-ASCII characters showing up as either squares or question marks.

Reason and Solution: Writer erroneously prepends the UTF-8 Byte Order Mark to XML-RPC requests that are UTF-8 encoded. This prevents WordPress from correctly detecting the UTF-8 encoding declaration, so ISO-8859-1 is assumed instead.

Run regedit.exe and find the following key: HKEY_CURRENT_USER\Software\Windows Live Writer\Weblogs\<your-blog-id>

Verify that the subkey ManifestOptions contains a characterSet=”UTF-8″ value. If so, under the subkey UserOptionOverrides, add a new String Value named characterSet and leave its value empty.


The second issue is with Live Writer throwing an ArgumentOutOfRangeException when you try to load posts which contain <pre>,<script> or <style> tags that are not upper-cased. More information is here. So follow the steps I outlined below for importing from an RSS feed to avoid this issue.

Importing your Data 

With the above issues in mind, you can start importing your data.

Please note that this procedure is based on RSS export and therefore does not import comments. You might have to use BlogML to achieve this. The process is probably: Export from DasBlog and save as BlogML (XML) with the exe downloaded here, then convert to WordPress WXR format with XSLT, and import.

To export/import via RSS proceed as follows:

  1. In your DasBlog/ThinkJot settings increase the number of items in your RSS feed to cover all the posts:
    Max. Days in Main RSS Feed**
    Max. Entries in Main RSS Feed
  2. Load the RSS into your browser by clicking on the RSS icon on your blog home page  or by entering navigating to http://<blog url>/SyndicationService.asmx/GetRss
    Save the XML displayed in your browser into a text file on your local drive, like c:\wordpress_export.xml
    You have to edit the file now For most users, Word is probably the most appropriate application, because now end-of-line characters have to be removed, otherwise they will be transformed into line breaks during import into WordPress, messing up the layout.
  3. Take the following measures:
    • In MS Word>Edit>Replace>More>Special>Paragraph Mark  -> Replace with nothing (empty string). This leaves all HTML line breaks and paragraph markings intact but removes the invisible “\n” at the end of some lines.
    • Then replace two spaces with single spaces repeatedly to have only one space between words.
    • Then look for  <pre>,<script> or <style> tags and upper-case them, i.e. <pre> becomes <PRE> etc. If you’re using a code plug-in for Windows Live Writer, these might be the source of many of those tags. I’m using Steve Dunn’s Code Formatter Plugin which I like best. This plugin as most others use the <pre> tag. So upper-case it. Remember to save the edited file as plain text, not in doc or HTML format.
  4. Then you can import your file into WordPress:
    In the Admin Dashboard of Worpress, go to Manage>Import or directly to <blog url>/wp-admin/import.php
    Click the RSS-link, browse to the file you edited above and click the “Import File and Upload Button”. This should import your old posts just fine. You can now load the posts into Live Writer with Recently Posted>More.. If it still bombs with an ArgumentOutOfRangeException you can edit the offending post in the WordPress interface upper-casing the said tags and then try again.

To conclude, what took me a number of hours (as usual mostly due to Microsoft bugs [in one of their best products though]) should take you not more than an hour or so. Hope it helps.

Technorati Tags: , ,
[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Testing image upload with Microsoft Live Writer

Blogging Software No Comments »

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Using ThinkJot with Medium Trust on ASP.NET 2.0

Blogging Software No Comments »

Most hosting providers will only allow Medium Trust applications under ASP.NET 2.0, which means vanilla dasBlog is not a viable blogging platform in these cases. ThinkJot 1.0 (2.0 is coming soon) is a stripped-down fork of dasBlog and it will compile and run under Medium Trust ASP.NET 2.0 without any problems.

However, connecting with blog editors like Zoundry or Microsoft Live Writer might fail with a “Operation could destabilize the runtime” error. The issue is rooted in the runtime and described here. To solve it, you have to download the latest version of, grab the source of ThinkJot 1.0, update all references to CookComputing.XmlRpc.NoSN.dll in all apps references by the web to the new version CookComputing.XmlRpcV2.dll and recompile. The blog software connection will then work without a hitch.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]