Adam Kinney on Longhorn

Designing and Developing with WinFX

Chronicles of a WinFx Developer: Just Getting Started

Chronicles of a WinFX Developer

Just getting started

When Longhorn and I first met

It was all physical for me, at first.  I saw the spinning semi-transparent windows, the gradient indulgence, and the smooth video playback.  I watched whatever demo movies I could find online.  I didn’t make it to PDC in 2003, but I do believe that I got Microsoft’s message; Longhorn is going to change the computing experience as we know it today.

I read the comments pertaining to the lack of performance when running Longhorn in a virtual environment and I knew the only choice for me was to buy a new pc.  I wanted to experience and develop with in the operating system as effectively as possible and I knew that wouldn’t be possible without giving Longhorn its own hard drive.

Planning to write about my experience with Longhorn, I signed up for a blog on (Thanks Robert!) in addition to my blog.  Blogging about my experience has been a great way to get in contact with those at Microsoft and in the community.

First Impression

After the installation (Longhorn OS, Visual Studio Whidbey, THEN the Longhorn SDK), I was greeted by a new system default wallpaper.  We had left famous green hills of Windows XP for the pre-harvest golden fields of wheat.  I took note; the new Windows operating system was germinating.

A new chunky sidebar to the right now displayed my computer time in the form of an analog clock.   The clock is visually attractive and provides a first look at the visuals possible in Longhorn.  The sidebar will act as a place for information that you would like to constantly monitor.  Imagine the last five emails you received, stock quotes, your music play list or even the last five blog entries from that feed that you just HAVE to keep a close eye on.

Upon opening a few windows, I realized that there was no Aero styling from the PDC videos and that the Internet Explorer toolbar has grown to an inch and a half.  When using explorer to view files you get a nice tool tip-like popup displaying more file details and a thumbnail for images.  When you right-click to rename a file, the selection no longer includes the file extension, as if you were changing the file name as well as the file type.  A lot of nice enhancements have been added for the user, but I believe so far we have only seen the tip of the iceberg.

XAML Samples

                I began my development in notepad.  XAML was the most talked about item and I wanted to get a handle on how it worked, before jumping into compiled code and the use of Visual Studio. 

XAML is not HTML, and I don’t believe that comparing the two is a good approach while learning.  XAML elements correspond to classes, properties and occasionally methods as a easy way to instantiate classes, set properties and add handlers to events.

One of the first things I noticed about XAML is that sizes are set using the new Length structure, a unit of measurement equal to 1/96th  of an inch.  This new measurement type is based on the fact that most PC monitors today display 96 dpi (dots per inch) and is implemented as a future compatible feature.  200 dpi monitors are available today and greater than 96 dpi display screens will become common for devices of the future.  Due to the Length structure, Longhorn applications will only improve in appearance, rather than losing usability when viewed on a future device.

                The absence of a XAML designer was quickly noticed when typing out when hand-coding extended paths for complex shapes.  Drawing shapes with declarative markup is simple and effective, but developing complicated User Interfaces will not be practical until a XAML designer is made available.

The SDK and Whidbey IDE

The SDK – The good, the bad, the missing

                The installed Longhorn SDK weighs in at about 800 MB and mirrors locally what is available online.  I find myself using both at the same time, depending on whether I want the responsiveness of the web search or the “statefulness” of the local application.  I yearn for the day when the SDK is a Smart Client application using ClickOnce to maintain the most current help files covering the topics of my choice.

                65% of the time when I load a new local documentation page, I receive a scripting alert warning my “disk” is full.   I have checked all of my “disks” and they appear to have plenty of room for one more documentation page.  The “How Do I…?” section is promising, but still very empty.  Many methods and properties have little to no definitions.

                The good part is that what’s that there an SDK and without one, testing the technology preview would be very difficult.  The sample code included has been the most beneficial.  The story is that the Program Managers (PMs) were tasked with writing the documentation for the PDC release.  I think they did a pretty good job for not being Programmer Writers.

Visual Studio.NET Whidbey

                Visual Studio “Whidbey” PDC release is the only edition of Visual Studio that is able to compile Longhorn Applications.  As mentioned before there is no design view for your XAML files, but the text editing support is noteworthy.  You may see some interesting errors when using a Canvas element, such as “The active schema does not support the element ‘Canvas’.” and “The element ‘Canvas’ may not contain content.”, but you can still compile without error.

                Current development in code, rather than using XAML, can be puzzling and unclear.  Difficulties can arise from lack of documentation or lack of understanding the Longhorn programming concept.   I have found it useful to examine the generated class file to view how the XAML markup compiler that which I am attempting to emulate.

                The generated class file is hidden from a developer’s view until a run-time error is raised.  To view the file, add a MouseHover event handler to the Window element. When the application is run, a “Method not implemented” exception occurs, which in turn breaks the application and loads the generated class file in Visual Studio.

Worthless Visual Samples


                After posting my first sample “Snow Mountain Textboxes”, I had become comfortable with shapes and brushes in XAML and had decided to move on to Animation.  I have spent a fair amount of time developing within Macromedia Flash, and was eager to compare the two platforms.

                The first obvious advantage of Avalon is the usage of the GPU to render visuals to the screen.  Another advantage is when setting the timing of animations, a specific frame is not defined but rather a TimeSyncValue.  This allows for the system to optimize the frame rate per second of the animation based on the capability of the current device.  The flexibility of animation in Avalon is a great advantage.  Properties, Transformations, Colors and Fills can all be animated with their respective animation type, ColorAnimation, DoubleAnimation, LengthAnimation and PointAnimation. 

Dynamic Animations and Timelines

                Defining animations within XAML works well but does not allow for much user interaction.  Property Triggers can be used for basic responsiveness and are simple to implement, but do not readily provide for dynamic animation.  To provide the type of UI reaction I was looking for, I began creating pseudo-animations based on the MouseMove event.  The user would move their mouse on the screen and I would handle the event by clearing the screen of custom-drawn shapes and then redrawing the objects based on the analysis of the new data.  Needless to say, this was not going to be a long-term solution and ran rather choppy (view sample).

                Thankfully, I then discovered the TimeLine class.  Avalon applications have a main timeline that spans the life of the application.  When setting the Begin property of an animation, a TimeSyncValue is set.  A very descriptive structure name explaining that value given defines when to synch the animation with the application’s main timeline.

                To fully use the features of a timeline, I instantiated my own timeline instance and synchronized it with the main application timeline.  My user-owned timeline could then be paused, restarted, accelerated, decelerated, reversed and stopped without affecting the application’s timleine.  This afforded the ability to analyze user input and manage animations dynamically every frame (view sample).

Worthy Applications

Difficulties in Obtaining Worthiness

                At this point, I was ready to step up and create something useful.  Something that did a little more than move shapes around the screen.  I had plenty of ideas for applications to write that would show off the where Longhorn is headed.  Unfortunately building an application was not such an easy task.  The operating system is pre-alpha, the documentation is thin, the community is small and sometimes the explorer process decides to eat up 100% of my processor.

                Was it time to kick back and let it become a more mature system with better documentation?  No, I couldn’t do it.  I was hooked, I was sitting at work (the job that pays the bills) thinking about how I could write this application if I had WinFS.  Or how I could share application data with Indigo.  Or how I could clean up this UI if had the power of Avalon.  So, I pushed on.              

Ocel: Longhorn RSS Aggregator

                Ocel is the most linked sample of anything I have posted on my blog.  Of course, it rode on the coattails of RSS, but I received a lot of good feedback and interest.  Ocel was released as a very barebones RSS Aggregator testing the implementation of WinFS and the usability of Avalon as a working application’s interface.

                I have read in many of the “tweaking Longhorn” guides that you should turn WinFS off completely, but since I am running Longhorn on its own computer, I believe I have had better luck with performance.  WinFS is going to be very valuable and will allow for some flexible and extendable data usage.  Although currently, finding and filtering data is currently slow and the lack of being able to create custom types within WinFS is disappointing.

                In order to use WinFS for Ocel, I saved RSS feeds as Albums and entries as Album Tracks, which are both existing classes in the System.Storage.Audio namespace.  With some good hands-on experience in using WinFS, I can tell you WinFS is going to be a great aid to developers and end-users.  You’ve heard the ideas on one central store for contacts and how users will be able to actually find desired files on there 100GB hard drives; but as developers we will gain simplicity.

                When saving an RSS feed, I would create a new Album, set a few properties and then call its Save method.  I didn’t have to write the Save method and recovering the information can be accomplished by using the predefined AlbumSearcher.

Support and the Community


                If you are looking for answers to your Longhorn development questions, the newsgroups under the header are the place to go.  A lot of Microsoft employees are participating and a small group of developers have become regulars there, as well.  The winfx newsgroups are currently being indexed by Google Groups so that’s a great place to start before searching for answers to Longhorn questions.

PDC Sessions Online

                From those of us who did not make it to PDC 2003, thank you Microsoft for posting all of the PowerPoint presentations as well as the audio recording from each session.   Watching the session and actually hearing the lecture is a great way to begin understanding Longhorn.  I quickly became addicted to these sessions and would download multiple sessions for a night full of Longhorn goodness.


                I am a big advocate of blogs.  Microsoft’s openness through writing and reading blog entries, I believe, has lead to some valuable customer feedback. is a great place to find bloggers talking about Longhorn.  In addition, a list of independent blogs should appear soon on the MSDN Longhorn Developer Center once the Longhorn blog landscape has solidified.


                The Longhorn Developer Center on the MSDN website has a lot of information to read through regarding the different aspects of Longhorn.  The Longhorn FAQ cover a lot of the initial questions on getting started and some basic concepts.  A lot of good articles are available online as well as the complete “Introduction to WinFX” book.  I actually purchased the paperbound version of the book and found that it is a good primer for learning purposes, but some of the code samples do not work in the PDC Build of Longhorn.

What’s next?

I am very interested in XAML as documents.  With the assistance of a simple XAML editor I can see XAML files becoming the .txt file of the future.  Perhaps some day Styles could be imported similar to external CSS files.  Data could be saved in XAML files that share one style document to maintain appearance and themes.

I am watching closely for news regarding 3D support in Avalon.  Microsoft has not committed to anything, right now most information is just conjecture based on the progression of DirectX and now the new XNA platform that has been announced.

I plan to spend most of my time with Avalon, Aero and the user interfaces of the future.  Avalon is all I’ve dreamed of thrown together, vector-based, styles from CSS, markup from SVG, animation from Flash, GPU usage and hopefully 3D support from DirectX.   I will continue to post about my Longhorn exploits on my blog at, where Longhorn entries will be syndicated to  If you have any questions or comments, please feel free to contact me.

Adam Kinney
WinFX Developer