Ookii.org

Command line argument parser for .Net

Sven Groot — Sun, 06 Sep 2009 08:59:19 GMT

Every developer has at some point in time written code to interpret the command line arguments of their program. Of course, I'm no exception. When I was recently in need of a quick way to parse the arguments for a whole bunch of different scenarios, I decided to go the extra mile and just write a generalised class that would let you easily define what arguments you want and then parses it for you.

I've now made that class available, in the Ookii.CommandLine class library.

It's very easy to use. Just create a class, and the constructor parameters of that class, as well as properties marked with a special attribute, will make up the command line arguments of your application. It can even create help text for the command line usage of your application.

More information, documentation, downloads and samples at the link above.

Yeah, I know there's a lot of similar stuff out there already. Now there's one more. :)

Mt. Fuji climbing

Sven Groot — Sun, 30 Aug 2009 09:11:04 GMT

It has been a long time since I posted anything about a trip here, but now it's time I do so. Last weekend, the 22nd and 23rd of August, I along with six friends climbed Mt. Fuji.

We set off on Saturday, leaving Tokyo at 12:40 by bus from Shinjuku, and we arrived at the fifth station of the Kawaguchiko trail (at an altitude of 2305 meters) around 17:00. After spending some time getting used to the thinner air, we started climbing around 18:00. Our schedule had us on the summit some time around 2:00 in the morning, but that was hopelessly optimistic. The climb was very exhausting, and I'm not exactly in the best shape, so it took us somewhat longer. The large number of people caused the occasional "traffic jam" which also caused a lot of delay. It's really unbelievable how crowded that mountain is. It's worse than Shinjuku station.

Our goal was of course to reach the summit before sunrise at 5:00 in the morning, but unfortunately we fell short of that goal by about 300 meters (distance, not altitude). Probably a good thing, in retrospect, since it appeared to be much more cloudy on the actual summit so we probably got a better view from where we were. After sunrise, we continued to the summit. Unfortunately, because many people had paused to watch the sunrise, an enormous queue had formed leading up, so eventually we were at the summit around 6:30. Once there, we took some rest, ate some food (despite the high prices I did buy some noodles, just to have something hot to eat, as it was very cold on the summit). Although thoroughly exhausted, we were all glad we made it.

Here's where things started to go wrong, though. For one thing, we hadn't all made it to the summit at the same time, so we were already separated. I was with only two others when we started our descent, and unfortunately we took the wrong trail back down (the trail down was not supposed to be the same one we took up, but we still took the wrong one). Despite the fact that there's signs every twenty meters or so, none of us noticed it was the wrong trail until we were all the way at the bottom. While we did arrive at a fifth station, it was the wrong fifth station. Of course, the others who went down separately did take the right trail so we couldn't meet with them. And because everybody managed to have dead cell phone batteries at the same time, we couldn't even contact each other to try and sort things out. So we could only go back to Tokyo on our own and hope the others did the same (which of course they did). It all worked out in the end, but it was a pretty stupid feeling when we realised we were at the wrong location after climbing all that way down.

But no matter how grueling the journey (especially the wind and the dust on the way down were very bad), and no matter the mistake with the descent, I'm still glad we did it, and I'm very happy I made it, of course. In fact, I still have trouble believing it. It's the longest single climb I've ever done, and the highest I've ever been (3776 meters at the summit, prior to this the highest I'd been was 3400m in the Sierra Nevada in Spain). The beautiful sunrise (the pictures don't do it justice, really), and the sheer satisfaction of reaching the goal, make it worth it.

Enjoy the pictures!

There are 47 images attached to this post. Click here to view them.

Let's Play: Riven

Sven Groot — Sun, 26 Jul 2009 15:44:52 GMT

You may have heard of something called a Let's Play video. These are videos on the Internet (typically YouTube) where someone plays through a game from start to finish, often providing commentary along the way.

I quite enjoy watching these videos. When done well, they can provide some nice added value to the game, and provide an opportunity to catch up on classic games that you never had the chance to play.

For quite some time now, I have harboured the plan to make a Let's Play of my own. Now, I have finally done so. The game I have chosen to play is Riven: The Sequel to Myst. This is my favourite game of the Myst series, and perhaps my favourite game of all time. Its level of depth and immersion is unparalleled by anything else I've seen, and because I know a great deal about the world of the Myst games it presented an ideal target for a Let's Play.

The first video of the series is embedded below:

Watch the video on YouTube

Today, I have finally uploaded the final video of the 32-part series. The whole thing was recorded in a single weekend, and uploaded one by one over the period of two weeks.

All of the videos are available in this playlist.

Enjoy!

Windows 7 ISO Verifier

Sven Groot — Mon, 06 Jul 2009 08:50:58 GMT

Windows 7 is about to hit RTM, and many of you might want to verify that the ISO image you downloaded hasn't been tampered with or was damaged as the result of some error in the download process. Of course you can use existing checksum tools and compare the result to published values, but it can be a bit of a hassle.

At the request of Long Zheng I created a small application that makes this process easier. Simply drag and drop your ISO file onto the application (or start the application and browse to the ISO file) and it will verify the EXE and tell you which build you have from a list of known builds. It downloads this list from the web automatically, so you don't need to re-download the application after Windows 7 RTM is released.

The Windows 7 ISO Verifier can be downloaded from Long's website.

Priority Queue for .Net

Sven Groot — Wed, 29 Apr 2009 06:17:48 GMT

A priority queue is a queue data structure where the element with the lowest (or highest) value is always at the front. A common analogy is to think of a queue of people ordered by some criteria such as age or height. Many programming languages include a priority queue in their standard library, including C++ and Java. However, the Microsoft .Net Framework does not include a priority queue, which is why I provide one here.

You might wonder why you can’t just use a sorted list to get the same effect as a priority queue. And the answer is, you can. A sorted list is a perfectly valid way to implement a priority queue. However, with a priority queue we are only interest in the smallest element at any time, and not any of the other elements, which means it is not necessary to maintain a total order of all the elements. Because of this, we can use an implementation that maintains only a partial order, which can provide better performance.

The most common such implementation is one that uses a binary heap. A binary heap is a binary tree with the property that any element in the tree is always smaller than both of its children. This guarantees that the smallest element is always on top, although the binary heap does not maintain a total order like a binary search tree. Efficient operations exist to maintain this heap property when inserting and deleting elements, making the binary heap perform better for priority queues than a sorted list. My PriorityQueue class for .Net uses a binary heap implementation.

The PriorityQueue<T> generic class that I provide here is written to conform to the conventions used by .Net’s built-in collection classes in the System.Collections.Generic namespace, particularly the Queue<T> class. The PriorityQueue<T> class implements IEnumerable<T> and ICollection.

The three main operations provided are Enqueue, which adds an item to the queue; Dequeue, which removes and returns the first element of the queue; and Peek, which returns the first element without removing it. In this implementation, these operations are O(log n), O(log n) and O(1) respectively. A special operation, AdjustFirstItem, allows you to change the value of the first item and re-evaluate its position in the queue, in less time than it would’ve taken to remove the element and add a new one (note that this is only possible with reference types that are not immutable).

The PriorityQueue<T> class provides several constructors, including one that allows you to create a priority queue from an existing list of elements with O(n) time complexity, faster than individually adding each element to the list with Enqueue.

You can put any type of element in the priority queue as long as it implements IComparable<T>, or you provide a custom IComparer<T> for the type. Note that the PriorityQueue<T> class will always put the smallest element at the front. If you want to have the largest element at the front, you can use the included InvertedComparer<T> class.

A short example of how to use the PriorityQueue<T> class is provided below.

PriorityQueue<int> queue = new PriorityQueue<int>(new[] { 4, 7, 3, 9, 12 }); // create a priority queue with the specified elements.
int n = queue.Dequeue(); // returns and removes 3; the front element is now 4.
queue.Enqueue(5); // the front element is still 4.
queue.Enqueue(2); // the front element is now 2.
n = queue.Peek(); // returns 2, but does not remove it.

Download the PriorityQueue<T> class for .Net (class library, sample application, and source code provided).

Read the documentation for the PriorityQueue<T> class.

New download: Ookii.Dialogs

Sven Groot — Wed, 28 Jan 2009 11:54:11 GMT

I have made available a new download: Ookii.Dialogs.

Ookii.Dialogs is a class library that provides a number of common dialogs for use in .Net applications. The dialogs provided are the task dialog, progress dialog, credential dialog, input dialog and Vista-style common file dialogs.

The download contains two class libraries, one for Windows Forms and one for Windows Presentation Foundation (WPF). The contents are nearly identical; only the input dialog is not available for WPF. Some utility classes are provided for Windows Forms; these are not available for WPF either.

Most of these dialogs are wrappers around Windows API functionality. The TaskDialog class wraps the task dialog API provided in Windows Vista and later. The ProgressDialog class wraps the IProgressDialog API available since Windows 2000. The CredentialDialog class wraps the CredUI API introduced in Windows XP, and the VistaOpenFileDialog, VistaSaveFileDialog and VistaFolderBrowserDialog classes wrap the IFileDialog API introduced in Windows Vista. Only the InputDialog is not a wrapper; this is a custom dialog that performs the same functionality as the old Visual Basic InputBox function. Visit the link above for more details on each dialog.

Each class has been designed to be not merely a wrapper around their respective native API, but to provide a programming interface that is natural to .Net developers, with full support for the component designer. The complete source code of the class libraries, as well as documentation and a sample application are provided.

The classes aim to give the best experience possible on each OS, where applicable. In the case of the CredentialDialog class, this means that the new Vista-style dialog is automatically used on operating systems that support it (Vista and newer). The Vista-style file dialog classes will automatically fall back to the old style dialogs when using Windows XP. This is also true of the VistaFolderBrowserDialog class for WPF, even though WPF itself doesn't provide a folder browser dialog; the VistaFolderBrowserDialog class is a full folder browser dialog implementation for WPF supporting XP and newer.

This library replaces the Ookii.VistaDialogs library, which contained only the Vista-style file dialogs and didn't offer any support for WPF.

This library is a collection of classes that I have developed for personal use over the years. Because of the difference in age of some of the code, and the many modifications made over time, there may be some inconsistencies.

Let me know what you think of it, if you use it.

Randomizing a list with LINQ

Sven Groot — Fri, 16 Jan 2009 14:12:44 GMT

There are many ways to randomize a list; perhaps the most common is to simply iterate over the list and swap each element with a random other element. Some libraries even include built-in methods for randomizing a list, but .Net isn’t one of those.

The introduction of LINQ in .Net 3.5 provides an easy way to manipulate lists and collections in all sorts of ways. So naturally one question that may come up is, can we use it to randomize a list? The answer is yes, you can. There’s probably more than one way to do it, but here’s one I like myself.

Random rnd = new Random();
var randomizedList = from item in list
                     orderby rnd.Next()
                     select item;

The orderby clause will use the specified expression to compare elements to determine their order. Here, it is using random values to do that comparison, so the end result is a randomized list.

Of course we can easily create an extension method to make things even easier (here I use an alternative syntax to use orderby, just to demonstrate how to do it with that):

public static IEnumerable<T> Randomize<T>(this IEnumerable<T> source)
{
    Random rnd = new Random();
    return source.OrderBy<T, int>((item) => rnd.Next());
}

The effects of x64 on your .Net application

Sven Groot — Thu, 08 Jan 2009 12:58:50 GMT

When you run an application created using .Net 2.0 or later on an x64 version of Windows, it will execute as a native 64 bit application. This is generally a good thing; your application gets to use the larger virtual address space and other advantages of x64 without you needing to change anything.

There are however a few consequences of running as a 64 bit process which need to be understood. There are three main differences when your application is running as a 64 bit process:

You cannot use 32 bit DLLs.
File and registry virtualization is always disabled.
DEP is always enabled.

The first issue is relatively well known. A 64 bit process cannot load 32 bit DLLs, and .Net is no exception. This isn’t a problem if you use PInvoke to use native Windows APIs; all the Windows DLLs come in both 32 and 64 bit versions. But if you’re using a third party (or your own) native DLL or COM component, you need to be aware of this. Also some .Net libraries, such as Managed DirectX and XNA, indirectly depend on 32 bit DLLs and will therefore not work in a 64 bit process. If you try to run such an application on Windows x64, it will crash with a BadImageFormatException.

If your application depends on any external native DLLs and you cannot provide a 64 bit version of those DLLs, or if the application is otherwise incompatible with x64, you should change the target CPU of your executable to x86. For C# projects in Visual Studio 2008, you can find this setting on the “Build” tab of the project properties; the “Platform target” setting is the one you want. For Visual Basic projects, look under the “Compile” tab, click the “Advanced Compile Options…” button, and change the “Target CPU” setting. When you change this setting, the compiler adds an attribute to the executable to tell the CLR to always run the program as a 32 bit process. You can also set this setting to x64 or ia64 which means your application will fail to run on systems that don’t support those architectures.

The second issue is less well known, and it applies to Windows Vista and newer only. If you have UAC enabled your application will run with limited rights, and cannot write to many locations such as Program Files or HKEY_LOCAL_MACHINE in the registry. For compatibility, Windows will redirect attempts to write to these locations to a different folder in the user’s profile (in %LocalAppData%\VirtualStore, to be precise). For 32 bit processes, this behaviour is enabled by default (you can manually disable it using a manifest), but for 64 bit processes, it is always disabled (it cannot be enabled at all) so if you attempt to write to these locations, it will fail.

File and registry virtualisation can be disabled for 32 bit processes using a manifest, and to make your application behave consistently on both 32 and 64 bit systems I strongly recommend you do this. Visual Studio 2008 will automatically embed a manifest in your application that disables the virtualisation. If you are using Visual Studio 2005, you can use this method to embed the manifest.

The final issue has to do with Data Execution Prevention. XP and Vista will not apply DEP protection to a 32 bit process unless the executable is marked with the NXCOMPAT flag, but for 64 bit processes, DEP is always enabled. If you interop with native code which might be incompatible with DEP you need to be aware of this. Visual Studio 2008 (and Visual Studio 2005 as well, provided you’re using .Net 2.0 SP1) will mark the application with the NXCOMPAT flag so DEP will be enabled for 32 bit processes as well. If your application is not compatible with DEP, and you cannot fix it for some reason, you must set the platform target to x86 as described above, and remove the NXCOMPAT flag.

.Net Remoting and IPv6

Sven Groot — Sat, 03 Jan 2009 08:19:06 GMT

.Net Remoting is quite an old technology, and has been superseded by Windows Communication Foundation in .Net 3.0. However, that doesn’t mean it’s useless; you may have an old application that already uses it, or you may need to target clients that don’t have .Net 3.0, or maybe you’re even working with Mono, which currently doesn’t support WCF. In all these scenarios, using .Net Remoting is still perfectly valid.

.Net Remoting was introduced in .Net 1.0, and broad support for IPv6 was not introduced until .Net 2.0. For reasons of backwards compatibility, a .Net Remoting server still listens on IPv4 by default, even in .Net 2.0 and higher. Only if your networking configuration supports only IPv6 (IPv4 is disabled completely) will .Net Remoting automatically listen on IPv6.

It seems like that should be fine. After all, if your network supports IPv4, what is the problem with using it? It turns out there is one, and it’s quite subtle. If your network is configured to use both IPv6 and IPv4, and your Remoting clients are using host names to connect to the server, those host names will resolve to both an IPv6 and IPv4 address. Windows will then try to connect using IPv6 first – which fails because the server is listening only on IPv4 – causing a delay of a few seconds on the initial connection.

You can easily reproduce this problem by having a .Net Remoting client connect to a server on the local host on a computer running Vista with the default networking setup which has IPv6 enabled. If you use localhost in the well-known service URL it will attempt IPv6 first, causing a delay. If instead you use 127.0.0.1 it will be much quicker. However, using IP addresses instead of host names may not be practical, and disabling IPv6 is also a bit of a sledgehammer solution. A better idea is to make .Net Remoting listen on IPv6.

Although it can be rather hard to find out how to do this from the documentation, it turns out to be quite simple. If you use the app.config file to configure remoting you can use the bindTo attribute of the channel to listen on IPv6. If you just add that attribute, the server will no longer listen on IPv4 however; if you want both IPv4 and IPv6, you need to define two channels. An example is given below:

<system.runtime.remoting>
  <application>
    <service>
      <wellknown mode="Singleton" type="MyApplication.MyServer, MyAssembly" objectUri="MyServer" />
    </service>
    <channels>
      <channel ref="tcp" name="tcp6" port="9000" bindTo="[::]" />
      <channel ref="tcp" name="tcp4" port="9000" bindTo="0.0.0.0" />
    </channels>
  </application>
</system.runtime.remoting>

As you can see, the IPv6 addresses are enclosed in square brackets. By using [::], the server will listen on all IPv6 addresses; you can of course also specify an explicit IPv6 address to listen on, same as for IPv4. For example, [::1] would cause it to listen on the local host only. This example uses a TCP channel, but the same principle works for HTTP channels as well.

If you configure remoting programmatically, you can use the same approach:

IDictionary properties = new Hashtable();
properties["name"] = "tcp6";
properties["port"] = 9000;
properties["bindTo"] = "[::]";
TcpServerChannel channel = new TcpServerChannel(properties, null);
ChannelServices.RegisterChannel(channel,  false);

Again, if you need it to listen on both IPv6 and IPv4, you need to configure two channels. The client does not need to be changed at all, for both methods of configuration.

A small note for people who are using Mono: on Linux, if you bind to an IPv6 address, it will automatically bind to the equivalent IPv4 address as well. In that case, you don’t need to specify two channels, just create a channel for IPv6 and it will listen on IPv4 too. This behaviour is exclusive to Linux, other flavours of Unix (e.g. FreeBSD) don’t do it.

New year trip to Mt. Haguro

Sven Groot — Fri, 02 Jan 2009 06:31:40 GMT

First of all, happy new year to those of you that still read my increasingly infrequently updated blog! Let's hope 2009 will be a good year.

I certainly got it off to an interesting start, as I took a trip with some friends from the Soshigaya International House. Over four days, we visited several nice places in Tohoku, the north of Honshu, the main island of Japan. We left by night bus, not my favourite method of transportation but it is cheaper than the alternatives (such as Shinkansen) and arrived at Morioka in the morning of the 29th. From there we took a regular bus to Matsukawa Onsen, a small hot spring resort in the mountains. Here we enjoyed the beautiful snowy surroundings and the various hot springs. Taking a bath in an open air hot spring surrounded by snow is certainly a unique experience!

The next day we travelled to Tazawa-ko by train, a town between Morioka and where we would spend new year, to see the lake there, the deepest in Japan or so I've been told. It was funny seeing the beach all covered with snow. The lake itself never freezes, probably due to its depth, although according to legend it's because Princess Tatsuko fell in love with a dragon god and that it's their passionate love making that keeps the lake from freezing over.

On the 31st we took the Shinkansen to Akita, and from there a local train (which was delayed a lot) to Tsuruoka and finally a bus to the top of Mt. Haguro. There we would stay at the temple itself, and attend the fire festival during the night. The festival was very interesting. It involved a competition between two local villages. First some young men from each village would have a debate, which involved enormous amounts of sake, to decide who would run the race later. The winners of the debate (incredibly drunk of course) of each village would race against each other pulling a giant burning rope. There was also a ceremony inside involving monks trying to fly as a bird, and some monk wearing a rabbit mask. Near new year, the temple bell would ring 108 times to get rid of the troubles of the previous year. Finally, another fire was lit at new year itself.

It was an amazing experience and very different from how I usually celebrate new year. I'm glad I could witness it.

So what will 2009 hold? I don't know of course. I do know that the first part will involve lots of bureaucracy as my first two years in Japan come to an end. This means I have to renew my visa (made more complicated by the fact that my passport will also expire this year), and move out of the international house. I've already started looking (online only at the moment) at apartments in the area. I plan to visit a housing agent (which a lot of the international students use because of their low fee and English speaking abilities) next week. Then I'll have to notify everybody like the insurance to the city hall of my address change. So I've certainly got my work cut out for me. Besides my actual research work, that is. :)

There are 50 images attached to this post. Click here to view them.

Improving Japanese fonts in Internet Explorer and Firefox on Vista

Sven Groot — Fri, 10 Oct 2008 09:32:00 GMT

If you've visited Japanese sites, you're probably used to the text looking something like this:

The font used here is called MS PGothic. It's quite an old font, and it actually uses bitmaps for smaller sizes like that one. This means there's no anti-aliasing at all, including ClearType. So Japanese text ends up looking a lot less nice than western text, especially if you've got ClearType enabled (which you probably do; it's on by default in Vista).

Windows Vista includes a brand new, much better, Japanese font, called Meiryo, which is optimized for screen reading and is fully ClearType enabled. Unfortunately, MS PGothic is still the default Japanese font in both Internet Explorer and Firefox.

Fortunately, we can change that by doing the following:

Click Tools, Internet Options;
Click the Fonts button;
Under Language script, choose Japanese;
Under Webpage font, choose Meiryo;
Now, under Language script, choose Chinese (simplified);
Again, set Webpage font to Meiryo.

You must do this for both Japanese and Chinese, otherwise not all characters will be displayed with the new font. Now your fonts should look something like this:

You can achieve the same effect in Firefox. The following instructions apply to Firefox 3:

Click Tools, Options;
Click Content;
Under Fonts & Colors, click Advanced;
Set Fonts for to Japanese;
Set the desired fonts to Meiryo;

Of course this only applies to sites that don't specify a font. If a webpage specifies in the HTML or CSS that it wants t use PGothic or another Japanese font, it will use that instead of your selection. In Firefox you can choose to have your choice override whatever font the page specifies; in IE, you cannot.

Enumerating the lines of a file

Sven Groot — Fri, 26 Sep 2008 07:25:52 GMT

If you've done any programming at all, you'll probably have read a file line by line at some point. Fortunately, most libraries provide an easy way of doing that, and .Net is no exception: the TextReader.ReadLine method provides what you need. If you've used this method, you'll have written something like the following C# code.

using( StreamReader reader = File.OpenText("myfile.txt") )
{
    string line;
    while( (line = reader.ReadLine()) != null )
    {
        // Do something with the line
    }
}

While it does the job, personally I think it would be nicer and more semantic if we could use the foreach keyword for this. It's possible of course to use File.ReadAllLines for this purpose (we can use foreach to enumerate over the array it returns), but that reads the entire file into memory at once, so it's not a good solution if the file you want to read is big.

Fortunately, we can make it possible to do this with very little code indeed, thanks to extension methods (introduced in .Net 3.5) and the yield keyword (introduced in .Net 2.0).

public static class TextReaderExtensions
{
    public static IEnumerable<string> EnumerateLines(this TextReader reader)
    {
        if( reader == null )
            throw new ArgumentNullException("reader");

        string line;
        while( (line = reader.ReadLine()) != null )
        {
            yield return line;
        }
    }
}

Note that the extension is defined on TextReader, so you're not limited to using it with StreamReader; you can also use it with StringReader or anything else that inherits from TextReader.

With these few lines of code, we can now use foreach to enumerate over the lines of a file:

using( StreamReader reader = File.OpenText("myfile.txt") )
{
    foreach( string line in reader.EnumerateLines() )
    {
        // Do something with the line
    }
}

While this isn't much shorter than the original, it looks much nicer in my opinion.

FormatC source code formatting

Sven Groot — Sat, 06 Sep 2008 09:46:27 GMT

I am proud to announce a new utility here on Ookii.org: FormatC.

FormatC is a utility that allows you to add syntax highlighting to your C#, Visual Basic, C++, XML, HTML, Transact-SQL or PowerShell source code, so you can publish it on a web page or blog post.

Why does the world need yet another syntax highlighter? Mainly, because of none of the existing .Net based ones had the features I needed. That's right, FormatC is the utility I've been using to format source code for my own blog. So if you read my site you've already seen many examples, including this one which demonstrates one of those features I mentioned: Visual Basic XML literals. I dare say I'm one of the first to actually support that, although it does have some limitations (which are mentioned on the FormatC page). In fact, I have support for all C# 3.0 and Visual Basic 9.0 features, including Linq.

You can format your source code using the interface on my site and simply copy/paste the results into a webpage or blog post, and customize the highlighting by editing the provided style sheet (or simply keep the default). You can also download FormatC as a class library to use in your own application, or look at the source code. It's designed to be easily extensible, so you can add your own languages if you want.

If you use it, let me know what you think.

Find As You Type and IE8 beta 2

Sven Groot — Thu, 28 Aug 2008 08:36:50 GMT

In case you missed it (which I think is only possible if you read no blogs except mine), Internet Explorer 8 beta 2 was released today. Beta 2 fixes some of the issues that beta 1 had and brings a lot of new stuff to the table especially for the casual user (beta 1 really was only a developer preview, after all). It's definitely worth checking out.

Some of you may remember that my Find As You Type add-on didn't exactly work very well in beta 1. So what's the story with beta 2?

First of all: IE8 now includes functionality similar to Find As You Type! This will surprise precisely no one since the feature was originally planned for IE7 but postponed. Now with IE8 beta 2, it's finally in there. IE8's new find functionaly works pretty much the same as my FAYT add-on, so there's really not much reason to keep using FAYT.

However, for those of you that do wish to keep using FAYT (for instance for some of features that IE8's new built-in find lacks, such as customization, auto-start, and immediate search while using an IME), there is good news also: unlike with beta 1, Find As You Type works fine with IE8 beta 2. The only thing that appears broken is that if you press CTRL-F when the focus is on the browser chrome (e.g. the address bar or search box), the FAYT toolbar does not open, instead IE's own find opens. If you press CTRL-F while a page has focus, the FAYT toolbar will open just like it does in IE7. I suspect this has something to do with the modified process model that IE8 uses for tabs.

Please let me know your experiences with FAYT and IE8, if you have any.

Win an MSDN subscription

Sven Groot — Sat, 28 Jun 2008 14:22:25 GMT

My good friend Christian Liensberger is giving away two MSDN Premium with Visual Studio Team System subscriptions, worth nearly $11,000! To be eligable you need to create a short screencast about a Microsoft technology, e.g. "how to get started with Silverlight 2". The competition runs from July 1st until July 31st. I will be helping with the judging.

See Christian's blog for full details.

Windows Search 4.0 released

Sven Groot — Wed, 04 Jun 2008 04:36:25 GMT

Microsoft has just released a new version of Windows Search, which is well worth getting if you have Vista because it's much faster than the built-in Vista search. Searching using the start menu search box feels at least five times faster now!

Get it here.

Report your Windows Vista UI annoyances

Sven Groot — Tue, 03 Jun 2008 09:32:04 GMT

Long Zheng has started the Windows UX Taskforce. The goal: to create a list of all the little UI inconsistencies and annoyances in Windows, so that Microsoft might fix them for Windows 7.

So if there's anything that bothers you about the Windows Vista UI, now's your chance to let people know.

Send your name to the moon

Sven Groot — Fri, 02 May 2008 11:21:15 GMT

As you may or may not know, NASA aims to return to the moon. In 2010, the Space Shuttle will fly for the last time, to be succeeded in 2013 by the Orion crew vehicle (part of project constellation), a capsule which looks a lot like a modern version of the Apollo command modules that between 1968 and 1972 sent 24 humans to the moon, half of which walked on it (one major difference is that the Orion will be reusable up to ten times; the Apollo capsules could be used only once).

The Orion will not only be used for supply missions to the International Space Station (taking over those duties from the Space Shuttle), it will also take humans to the moon (no later than 2020, according to NASA). Further plans include establishing a permanent settlement on the moon, learning to live and work on another planet, and to use this knowledge and technology for human exploration of Mars in the first half of the 21st century (again according to NASA). As a fan of space exploration I regret not having witnessed any of the original moon landings, so it would be great if they could pull all this off (especially if they go to Mars in my lifetime that would be awesome).

To gather detailed information about the moon (e.g. about possible landing sites) NASA is first sending the unmanned Lunar Reconnaisance Orbiter. And you can send your name with it. If you register your name on this site, it will become part of a database that will be put on a chip on the LRO, so your name will be in orbit of the moon.

Yes, it's completely pointless. I don't care, it's just a fun idea. :)

Awesome flight simulator video

Sven Groot — Sun, 20 Apr 2008 03:23:42 GMT

As some of you know, I play Flight Simulator. I tend to go for the serious, realistic simulation.

This video shows you can also have fun with Flight Simulator when you relax realism a bit. :)

Watch the video on YouTube

Okinawa day 11, 12 and 13

Sven Groot — Tue, 01 Apr 2008 13:14:36 GMT

At last, the final set of photo's from my trip to Okinawa. :)

March 9th we planned to go to the Okinawa Churaumi Aquarium, the world's largest tropical aquarium. Because we've been told regular bus fares to the aquarium are expensive, we took an organised tour which also included several other attractions, lunch, and was still cheaper than a normal bus ticket. The tour first took us to Cape Manza, a very nice cliff. After this we had lunch at a hotel (very fancy lunch, very nice) and then went to the aquarium. The aquarium was very impressive indeed, especially the main tank. They had very large manta rays, more than 2 metres across! They are beautiful animals, and they look almost like birds with the swimming motion they make. This can be seen in the video attached to this post.

After the aquarium we went to some castle ruins nearby, not incredibly impressive, and finally to a pineapple park. I think this was mainly a commercial agreement between the bus company and the park. Anyway, they had pineapple ice cream (very nice, although the nicest ice cream flavour we discovered during this vacation: that title goes to sugar cane ice cream, and sweet potato ice cream is also high on the list), and you could taste (and buy, of course) pineapple wine (also very nice) and eat as much pineapple as you liked.

On March 10th, we went whale watching in the morning. Although we did see plenty of whales (or two of them, very often), they didn't jump out of the water, so it was only backs and tails unfortunately. After this we went to the Sefa Utaki, a holy grove, one of the most sacred places in Okinawa apparently. Unfortunately it started raining pretty hard. The end of the day was spent on Kokusai-dori (international street), a big shopping street where we'd been before but hadn't looked around properly yet. This also gave me the chance to buy some sweets (Okinawan brown sugar of coure, what else) which I could take to the lab (it's a custom in most Japanese work places to bring souvenirs (usually food) if you've been on a trip). I think you could survive in Okinawa purely on the free samples they have on this street. :)

The final day, March 11th, is poorly represented in the photographs because my camera's battery died. We visited the peace park and the associated museum. The museum provided great insight into the Japanese involvement in World War 2, and of course the Battle of Okinawa in particular. Most impressively, the museum was very objective, painting neither side of the conflict as good or bad guys. One of the better war museums I've ever visited, on par with the one in London. It's truely amazing the horrors the Okinawan population went through (at the hands of both American and Japanese soldiers) during that battle, where the Japanese attempted to draw out the battle as long as possible to give the mainland forces more time, and were told to fight to the last man rather than surrender. Some 120,000 Okinawans died during the battle.

After the peace park we visited a nearby memorial dedicated to a group of more than 200 middle school girls who were forced to become nurses for the army. The memorial museum paints a horrible picture of how the lives of these ordinary girls were destroyed by the war. They were forced to nurse the wounded soldiers in horrible conditions until they were suddenly discharged near the end of the battle and sent outside into the crossfire. Many were killed, and many simply pressed a grenade to their chest and blew themselves up. Only a handful survived. Reading their stories and seeing the pictures was a very emotionally powerful experience for me, and it was quite obvious the same was true for most visitors.

Finally, we went to the airport to take our flight home. Because we hadn't realised just how late this flight would arrive in Tokyo we were a bit concerned we might not catch the last train, but everything went very smooth, we got our luggage back in no time and had more than half an hour to spare in the end.

And thus ended a fantastic vacation, my longest tourist trip so far in Japan. I've got a feeling this won't have been the last time I've gone to Okinawa (if not during the rest of my stay in Japan, I will certainly return at some later point in my life).

There are 33 images attached to this post. Click here to view them.