I’m between video games right now, so I thought that I’d take a look at what’s available in the Xbox Live Arcade.  There was one game that caught my eye, simply because of the name.  As you may have guessed from the title of this post, that game is ‘Splosion Man.

Ladies and gentlemen – let me be clear:  If you have not yet played this game, stop doing whatever you’re doing and go play the demo.  All the way through.  I’ll wait.

Done yet?  Ok, now buy the game and play the rest of it.  Seriously.

This is one of the best games I’ve played in the last 5 years – and I’m completely serious about that.  For me, this game is right up there with Portal, with the wonderfully odd plot and the amazingly quirky music.

What a fantastic game!

Back in 2006, I posted an article about how to get Glass running in a VM. 
The trick was to use Remote Desktop on a Glass-enabled machine to TS into a VM which is running the same OS.  If the build of the OS on your workstation is different than the one in the VM, Glass won’t work.

With the release of the Windows Virtual PC for Windows 7 Release Candidate, this subject has come up again in a post from the RedmondPie.com folks.  They noticed that if you enable the Integration Services in a Windows 7 VM, you’ll get Aero Glass!

This may be news, but it’s actually the same ol’ story.  The reason that enabling Integration Services gives you Aero Glass is because it uses Remote Desktop technology to show you the video from the Virtual Machine.  That also helps to explain why installing Vista (or a build of 7 that is different than the one on the host) doesn’t give you Glass.

Now, you might be asking yourself why – if this is true – do you not get Glass in Hyper-V while using VMConnect?  After all, VMConnect uses Remote Desktop technology to show you the VM Video, too. 

To explain this, I asked Ben Armstrong what was going on, just to make sure that I understood it correctly (for the record, I didn’t).  Ben thought deeply for a second, and knew that the best way to explain this to me was to draw pretty pictures on my whiteboard.  I’ve tried to reproduce them below¹:

Windows Virtual PC	Hyper-V

¹Please note that these images are not necessarily technically accurate – their only purpose is to help demonstrate concepts relevant to the conversation.

The Paint.NET Team has announced the v3.5 of Paint.NET will use DirectWrite on Windows 7 for rendering text. DirectWrite is part of Windows 7’s text rendering enhancements. Very cool!

DirectWrite is one of the new additions to the DirectX family of APIs in Windows 7. DirectWrite enables better readability, adds support for a large variety of languages and scripts, and in conjunction with Direct2D provides superior rendering performance for Windows applications. Applications can also use DirectWrite with GDI and carry forward existing investments in the Win32 code base. You can read more about DirectWrite here.

You can download an alpha build (build 3509) of Paint.NET v3.5 here. Please be warned that alpha builds are pre-beta quality and will likely have issues. But if you want to play around, give it a try.

This is the first of several upcoming blog posts on different aspects of Windows Live Essentials. For more information on the Windows 7 + Windows Live experience – click here.

First, I would like to congratulate the Windows Live Messenger Team for 10 years of Messenger! Find out how *you* can celebrate the 10 Year Anniversary of Windows Live Messenger by reading this blog post from the Messenger Team. I have the pleasure of being able to say I’ve been a Messenger user since V1. It’s been exciting to see the progression of Messenger over the last decade.

Today, I use Windows Live Messenger as a primary communication vehicle (outside of email) with friends and colleagues. As you can imagine, I have a pretty big contact list. Being able to manage and customize the layout of my contact list is pretty important.

By default, Messenger will show all contacts in your contact list online or offline, as well as groups. Messenger will also show the tab bar, favorites, and What’s New feed. To customize this default layout of your contact list, you can click the contact list layout button next to the add contact button in Messenger (see below screenshot).

The Options window will appear with the layout options for your contact list.

This is where you can customize the layout of your contacts list in Messenger to fit your needs.

For me, because I have so many contacts in my contacts list, I find that I am doing a lot of scrolling between the different categories. Looking at my own IM behavior, I’m usually chatting with contacts that are online. So to help alleviate some of the scrolling, I have unchecked “Show offline contacts”. This means that contacts that are offline will not appear in my contact list in Messenger until they come online.

You can view contacts on your contact list by different sizes in Messenger: Large, Medium, Small or Status only. To consume less space on my contacts list, I’ve chosen to view contacts by status only. What’s great here is you can choose the sizes of your contacts by your main contact list and favorite contacts just in case you want your favorite contacts viewed differently than the rest.

If you someone who’s not using Windows Live Groups, you can uncheck “Show groups” so this category doesn’t appear on your contact list. You can also do this for other parts of the window on this menu too.

Hopefully talking about this helps those of you with large contact lists like me manage and customize the layout for a better experience in Messenger!

One last thing – did you know that Windows Live uses a unified contacts “store”? That means the same contacts you have in Messenger are the same contacts you have in Hotmail or in Windows Live Mail on the PC. More on this and other aspects of Windows Live Essentials in upcoming blog posts!

This is the first part of a new blog series that will describe, in detail, all major aspects of the widget framework available in Windows Mobile 6.5.

The widget manifest is an XML file that describes the corresponding widget in detail so that Windows Mobile can actually do something with it.  This is the first file we look at when the widget is being installed or executed so, even though it is simple, it is extremely important.

For Windows Mobile 6.5 we implemented widgets based on the W3C Widgets 1.0: Packaging and Configuration standard dated Dec-22-08. While the standard continues to evolve, our implementation remains backwards compatible with very few exceptions – notable exceptions will be called out in this blog series.  To save you some W3C reading time, in summary, the widget manifest has to be called config.xml and its presence is required in order for the widget to be considered valid.  Technically you could provide an empty widget manifest and thus get something installed, since all elements inside config.xml are optional.  That said, I recommend that at the very least you define the elements that are present in the following example:

<?xml version="1.0" encoding="utf-8" ?>

<widget xmlns="http://www.w3.org/ns/widgets"

        version="1.0"

        id="http://someSite.com/MyUniqueWidgetID">

  <name>My first widget</name>

  <content src="widget.htm" type="text/html" />

  <access network="true" />

  <icon src="icon.png"/>

  <icon src="icon.ico"/>

  <description>

    This is my first widget,

    it won't make a lot of money on the

    marketplace but at least is cute!

  </description>

  <author href="http://www.windowsphone.com/blog"

          email="jorgeperaza@hotmail.com">Jorge Peraza</author>

  <license>

    Example license (based on MIT License)

    Copyright (c) 2008 The Foo Bar Corp.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS

    OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

    IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY

    CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,

    INSULT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE

    SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

  </license>

</widget>

The Widget Element: What Makes Me… Me?

The first element I would like to cover in detail is the <widget> element, the father of all other widget configuration elements.The document can have only one and, from the many attributes that can be specified, we only honor the following two in the current release:

•  version="1.0" This attribute specifies the widget version number, we use this to check if, when trying to install a new widget with the same id it should be allowed as an upgrade or not.
• id ="http://someSite.com/MyUniqueWidgetID" This attribute is actually extremely important, this is the unique per widget ID that the framework uses to identify installed widgets.This has to be a well-formed URI but it does not have to be valid.

Some of the child elements like <name>, <description>, <author> and <license> are self-explanatory so I won’t bore you with details for them. See? I’m nice sometimes :-).

Now, let’s talk about one of the most important child elements which happens to be <content src="widget.htm" type="text/html" />This element tells the widget framework which source file to load to execute the widget.You might also notice that the MIME type is also specified here… however on WM 6.5 we only support "text/html" so don’t get any ideas!!

The next group of interesting child elements are the set of <icon src="icon.png"/> which allow you to specify one or more icons for your widget. Icons are very important because they give your widget their unique personality.  Now, there are some important limitations widget writes should be aware of.  Windows Mobile Professional (touch screen) supports both PNGs and JPGs as image file formats to be used as widget icons, however, Windows Mobile Standard only supports ICOs (Please, don’t ask :-)) Soooo, in order for your widget to show best on both platforms I recommend having both and listing the PNG or JPG first.

Last but not least let’s talk about  <access network="true" />. This is an optional element that is required to be “true” if your widget accesses network resources, otherwise you can leave it out (but all cellular network calls will fail).

I went to all the effort for defining all fields in the manifest… can I at least access them from my widget?

Glad you asked, and the answer is… of course!  You can do this by using the widget metadata API available to you courtesy of the “widget” javascript object.  Below are the relevant properties that you can use to get information out of the manifest:

• widget.version
• widget.identifier
• widget.name
• widget.description
• widget.authorEmail
• widget.authorName
• widget.authorURL
• widget.height
• widget.width
• widget.locale

That’s it for now.  Please stay tuned for more information and happy widget writing!