Those of you who regularly read my editorials will already be familiar with my Hamurabi.NET project. For those of you who aren't, at the start of this year I began fooling around with a modern-day .NET implementation of the classic mainframe computer game Hamurabi. Besides my personal fondness for the game, I also had the vision that it could - if done right - serve as a much more interesting demonstration vehicle for teaching .NET technologies than the classic "Hello World" example.

As luck would have it, I was soon given the opportunity to test my theories about Hamurabi's usefulness as a teaching tool. Microsoft asked me to put together a six-part Webcast series on mobility to run over the month or so leading up to their Tech Ed conference at the end of May in San Diego. I began by creating versions of the Hamurabi User Interface for both the Compact Framework and the ASP.NET Mobile Controls. In this article, we will examine the flavor I created for Longhorn using the new WinFX technologies of XAML and speech recognition.

Setting Up Longhorn
In order to do any serious Longhorn development, you will need three things:

1. Longhorn
2. Visual Studio "Whidbey" PDC build
3. The Longhorn SDK

If you attended the PDC, you already have all of these things on the DVDs you were given at that conference. If not, your next best chance at obtaining them is to be (or to become) an MSDN Universal subscriber. If neither of these options works for you, you might consider joining Microsoft's Longhorn Readiness Program for ISVs.

Regardless of how you obtain the materials, there are a couple of things you should know before you begin installation. The first thing is that friends and associates of mine who have tried installing Longhorn on virtual environments (specifically, Virtual PC and VMware) have not been very happy with the performance they achieved. Whether this is a problem with Longhorn, a problem with their virtual machines, or the simple result of Longhorn's increased performance demands, I don't know, but I can tell you that I installed Longhorn on a native partition on my hard drive and have achieved completely acceptable performance on a 2GHz laptop with 512MB of RAM.

The other thing you need to know is that installation of the above three pieces is very order dependent. Specifically, you must (of course) install Longhorn first. Then you should install Visual Studio Whidbey.

Important Note: Make sure you install the PDC build of Visual Studio on the PDC build of Longhorn. Even if you have the more recent build of Visual Studio from Microsoft's Mobile Developer's Conference, there is no guarantee that it will work.

You should install the Longhorn SDK last. This will allow you to access all of the new Project Types that relate to new Longhorn technologies.

Once you have everything installed, the next thing you will want to do - assuming you want to actually be able to use the speech recognition facilities we are about to build - is set up your audio properly. I strongly encourage you to invest in a halfway decent microphone for your computer. Trying to get speech recognition working via your computer's built-in microphone (if it even has one) is no fun. You want to decrease the amount of background noise as much as possible, and talking directly into a microphone is a lot less noisy than talking into the air.

Besides investing in a microphone for your computer, you should make sure that you have the recording level for your microphone set to an optimal level. Experiment with the Sound Recorder under "Accessories > Entertainment" on the Windows Start menu. Specifically, you will want to go under "Edit > Audio Properties", click "Volume" under "Sound Recording", and adjust your microphone volume until you can record a sound sample of your voice that is neither too soft (increase your volume) nor distorted (decrease your volume).

Getting Started with XAML
The first step in building our Longhorn flavor of Hamurabi is to start up Visual Studio .NET. Once the IDE finishes launching, you can choose "New Project" and you will be presented with a dialog like the one in Figure 1.

As you can see, there are a number of new projects available for building Longhorn applications. You want to choose the standard "Longhorn Application," which should be the first project on the list. This is roughly equivalent to the standard Windows application under previous versions of the operating system, but it will default to using XAML and the Avalon presentation system, rather than the traditional Windows Forms user interface.

It seems appropriate, then, to begin by examining the XAML for our implementation of Hamurabi, as shown in Listing 1.

Window1 is the primary window in my application. It begins with an attribute-packed "Window" root node. The attributes basically serve to tell the world that this is an XAML document, where to find the code-behind for this document (much as you would have a code-behind for an ASP.NET page), and also that the method WindowLoaded in the code-behind should be run immediately upon loading this page.

Immediately within the root node is a "DockPanel" node. Panels are one of the most important innovations in the XAML technology, because for the first time they give developers an easy way to create user interfaces that can be resized at run time without falling apart. They do this by positioning elements according to general rules rather than specific coordinate-based positions. In the case of the "DockPanel," it positions elements either at one of the four edges of a document (top, bottom, left, or right) or in whatever space remains (specified as "fill").

There are two elements within our DockPanel. Starting at the bottom of the listing, we have a TextBox that will go at the top, which will contain the "running narrative" telling us what is happening, just like in the original mainframe game. At the top of the listing is a GridPanel that will go at the bottom of the window. This will contain all of the TextBoxes and Buttons to receive user input.

Each of the buttons has an OnClick attribute specified, which tells Longhorn which method in the code-behind class to call when the button is clicked. If you look at Listing 2, you will find the code for each of these methods.

Speech Recognition
In addition to the code for responding to events from the graphical user interface (GUI), the Window1.xaml.cs file in Listing 2 also contains code to enable speech recognition. This code begins right from the start of the listing by including the System.Speech. Recognition and System.Speech.Srgs namespaces. These namespaces enable our application to understand spoken words and to dynamically build - at runtime - grammars capable of defining exactly which words (and in what combinations) can be understood, respectively.

Important Note: In order to use any of the speech-related features of Longhorn in your code, you must include a reference in your project to the System.Speech.dll assembly. However, this assembly is not put into the GAC by default in the PDC build of Longhorn. Instead, you must browse to it at %windows%\microsoft.net\windows\v6.0.4030!

Begin your inspection of the speech-related code by looking at the YearlyReport function. At the end of this method you will find a call to the CreateHamurabi Grammar method, which tells us that a new grammar for our game is generated after every turn.

If you look at the Create HamurabiGrammar method, the reason for this soon becomes obvious. Our grammar wants to support phrases of the form "<verb> <number> <objectType>", where objectType is optional. For example, we could either recognize the command "Sell 12 acres," or just "Sell 12" (because we know that acres are the only thing we can sell). The reason we regenerate the grammar for every turn is that the specific number of anything that we might be able to work with (e.g., how many bushels we can plant, how many acres we can buy, etc.) will vary from one turn to the next, depending upon how well - or how badly - we are doing in the game. We enforce this in many ways, but the first line of defense is to refuse to even recognize requests that would exceed our capabilities. This means, for example, that a spoken request to "Plant 5000 bushels" won't be recognized if we only have 300 bushels, but a request to "Plant 299 bushels" will be!

WindowLoaded specifies that the method RecognitionEvent should be fired whenever the system understands something that is being spoken to it. If you look at this method, you will see that it:

1. Fills in the txtInput field with the number of things being acted upon
2. Points a delegate at the correct method for whatever verb is being used

For example, the command "Buy 12" would result in a "12" in the txtInput field and the cg delegate being pointed at the btnSell_Click method. You can try this out for yourself by running the code and then either speaking legitimate commands into the microphone on your system or typing valid commands into the txtEmulate input field and clicking the btnEmulate button.

The last thing that I would hasten to point out in the code is the use of the new UiContextOperationDelegate class. Basically, XAML-based GUIs in Longhorn have the same restrictions as WinForms-based GUIs in terms of not allowing threads to write to them other than the thread by which they were created. Because speech recognition happens on a background thread, we need to use the UiContextOperationDelegate as shown to have it request updates to the GUI.

Final Thoughts
This implementation of Hamurabi is fully functional. If you try resizing the main window on your display, you will see that the XAML allows it to resize appropriately. If you try speaking commands into your computer, you will see that it usually responds appropriately (albeit a bit slowly, given the large number of values it has to sort through in the "number" field of its grammar). The complete Visual Studio Whidbey project has been posted to my Hamurabi.NET Workspace at www.gotdotnet.com; I encourage you to download it and try it for yourself!

• Figure 1
• Figure 2
• Source Code