Vista

Vista, How I Love Your Balloons, Let Me Count The Ways...

Jason Olson — Mon, 19 Jun 2006 23:38:00 GMT

As you readers out there may or may not know, I'm a fan of all things games. Heck, you could probably sell me a hunk of plastic if you were able to somehow convince me that it was in fact a game (double-whammy if you were able to convince that it was somehow a football game). This piece of news might help explain why such a little piece of sweet Vista toast can make my evening (although, I must admit, it may have been more "balloon" than it was "toast").

I was in the process of installing Visual Studio 2005 into my VM of Vista Beta 2 this evening when a little nugget popped up to say hello. As Visual Studio was installing, I turned on my XBox 360 to do, well, what we XBox 360 owners do of course (disclaimer: if you do not presently own, or have never owned an XBox 360, it is strongly encouraged that you "waddle right out" and purchase one, post haste [ED: I added the phrase "waddle right out" since the legalese that my "lawyer" (aka "Hugsy, the Bed Time Penguin Pal") came up with was rather drab and boring]).

When the 360's beautiful, glorious, green light came to life and lighted up my life, Vista gave me a little surprise as well. It appears that Vista and the 360 are in fact long lost friends and, to my surprise, Vista shouted with joy when they were finally re-united again. Stargate (aka my Vista box (hey, I've never claimed *not* to be a geek you know)) informed me that not only did he know my 360, but that he would be more than happy to share all his possessions with the 360. The price? Only a few clicks. Heck, that's a price I'm more than willing to pay. After a couple clicks here and there, my Vista machine was ready to share media with my 360 and be inaugurated into our big, happy family. Slap me silly and call me "Mr. Fan-Of-Interconnected-Devices-Who-Are-Easy-To-Setup-And-Share-And-Party-With."

I haven't dug into the depth of this sharing experience yet, but you can bet your bottom dollar that I will start playing around with it this weekend. I'm sorry for such an "over the top" post, but I get so excited when I encounter technology that makes my life better and makes the geek in me cry with joy (and for those who know me, you know I'm large enough to *literally* have an entire geek within me to begin with (dare I say that I, indeed, may actually have a living and breathing geek within my bell-eh (it would certainly explain all the muffled shouting I hear from time to time))).

If only all things in my life could be so easy...

Note: I know that a good amount of this type of functionality is available with Media Center Edition, but alas, I do not have that and this is my first "media sharing" experience with the XBox

[Crosspost from Managed World]

Starting with the Foundations

Jason Olson — Tue, 13 Jun 2006 14:43:00 GMT

I was asked recently what excited me most about the various Vista technologies. While I took a valiant stab at limiting my answer down to a handful of them, the proper answer with the way I feel would have been "what _doesn't_ excite me about the various Vista technologies." Yes, I could get into the various aspects that excite me about Workflow Foundation, Presentation Foundation, and/or Communication Foundation. I will save that for a later blog post though. Save to say, I'm extremely stoked right now about doing some development with all the different Foundation technologies. I think I'm going to do some deep-diving into Workflow Foundation for a while though :).

So, after a hiatus for almost a year (has it really been that long?), I will be spending time again getting into the various Vista technologies that are coming our way. So stay tuned in the future for more Vista updates :).

[Crosspost from Managed World]

Will Longhorn Still Be Longhorn?

Jason Olson — Fri, 27 Aug 2004 19:39:00 GMT

I know it is really premature to even start discussing this, but I would like to ask the question: “Will Longhorn still be Longhorn”? Although the official announcement isn't slated until later today, there has already been some musings about the subject over at Microsoft Watch. How do I feel about this? Mostly, I feel a great sadness (and I remind you: I know this is premature).

[DrasticallyPrematureDiscussion]

It is starting to look like Longhorn will become “Windows XP version 2“ rather than the revolutionary OS all of us were hoping for. While this possibility of course disappoints me, I think there is perhaps a deeper issue to be discovered here. From what has been said, the majority of cuts expected in Longhorn is for the purpose of getting the product out the door sooner. While I would like to ask the question “Does Microsoft really need to push Longhorn out the door quicker to satisfy it's customers?”, I think there is a better question to ask. In order for Microsoft to keep its customers happy, does a new operating system need to be released every five years?

The Apparent Problem

The apparent problem to me is that it appears that Microsoft does feel that it needs to release a new operating system every couple of years. It is no secret that end users don't like change. How much does an end sure appreciate having to upgrade their operating system every five years? Not much, in my opinion. Well, if we are in the software industry “to best satisfy our customers needs”, then why is our approach to product time-lines so contrary to what our customers desires are? Even as a developer, we have to be adapting new technology every couple of years in order to stay “on top of our game.“ To me, this is a problem with the industry as a whole.

The end user wants their computer to be like an appliance, or perhaps like a car. When you buy a car, you fully expect that car to last a long time. You do not expect to be forced to buy a new car every 7 years in order for it be fixed by mechanics. What if your car broke down but the mechanic couldn't fix it because it was “no longer supported“. I don't know about you, but I would be rightfully upset. However, I will admit this analogy breaks down when comparing an operating system to a car because of the level of investment required in a car compared to an operating system. When you buy an oven, you expect that oven to not only work for a long time, but for it to be supported so that you can get it fixed for a long time. While an oven is still cheaper than a car, the analogy still breaks down when comparing directly to an operating system. However, what if you count the amount of investment required for buying applications and the continued support of those applications? The analogy becomes a lot closer. As much as I'm excited about all the new innovations in the computer industry as a developer (I *am* a geek after all), as a consumer I will admit that I am frustrated from time to time.

As much as we claim to be in a “customer-driven“ industry, we are not. The customers do not drive the computer industry, the computer industry drives the customers. We force customers into a never-ending upgrade cycle where if you want to remain “productive“, you must upgrade, upgrade, upgrade. I believe that if you compare the lifetime of applications developed in 1960 to the lifetime of applications developed today, you will find that the lifetime of applications developed today is much shorter than their 1960 counterparts. I highly doubt that I will find a classic ASP site still running and being supported in 40 years. Why? Because it will have been upgraded to the “latest technology“ 36 years prior to that date.

Now, one can argue that this development of shorter lifetimes was necessary with the improvements in technology that have taken place. The question is when we will get to the point that computers are productive enough in order to remain stable for a set length of time. However, are remaining stable and continuing innovation necessarily mutually exclusive areas? No, not at all. Is there a potential solution that we could see start today to combat this problem. Absolutely.

The Possible Solution

I think the possible solution to the above problem can been seen with the release of SP2 for Windows XP. If you ask me, SP2 is a major improvement to the core Windows XP operating system. If SP2 can improve Windows XP as much as it did, what is preventing future service packs from doing the same thing? I would like to think that Windows XP is engineered well enough to the point that continued service pack development can take place to continue evolving Windows XP as an operating system. However, to continue service pack development, should we stop development on Longhorn? Not at all.

Let me ask this: Why must the two be mutually exclusive? I can see a world in which Microsoft devotes many resources to continued service pack development and continues to release those service packs for free to the world. I can't even start to imagine how happy end users would be if they could keep an operating system running for even 10 years and have it continually improve for them without requiring them to drop any more money or time and effort to upgrade applications. While there is naturally a limit to how much improvement can take place, I don't think that limit is anywhere close to being reached with Windows XP. If you need graphical improvements to the OS, one need only look at the 3rd party skinning applications available to realize that there still lies great potential within Windows XP.

This doesn't mean that development on a new operating system should stop though. Only so-many improvements can be made to an operating system until its expandability limits are reached. At that point in time, the underlying internals of the operating system need to be re-written in order for more progress to be made. So the real solution in my mind is to have two development houses. One house is dedicated to the continuing improvement and maintenance of the current operating system. The other house is dedicated to the development of the "next" operating system. In this case, one house would be dedicated to the continued development of service packs for Windows XP, and the other house would be responsible for the development of Longhorn.

Don't cut features out of Longhorn. Continue developing Longhorn until your “nirvana“ is reached. By cutting so many features out of Longhorn, you are only hurting the end customer. The end user doesn't care if Longhorn arrives 2-3 years later. All they care about is if their applications continue to run today. Who are the ones that really care about Longhorn being released earlier? Us developers, and the company actually developing the operating system. I will continue to stand by my belief that the end user doesn't care about when Longhorn comes. As proof, how many customers are still using Windows 98, huh?

Of course, this does have potential to hurt the bottom line in any company that takes this approach. The key is for diversification. And I strongly believe that Microsoft is diversified enough to start down this road. After all, IBM is still around isn't it? Am I the only one who feels this way? Perhaps. Perhaps not.

[/DrasticallyPrematureDiscussion]

I don't want to come off like I'm not seeing the big picture here though. While I put a big negative spin on the news, there is a very bright silver lining to this cloud. The biggest benefit that I see to what Microsoft is doing is that the Longhorn technologies will not be exclusive to Longhorn. They will all be available on Windows XP, I believe. To me, this is a good situation. In the context of Microsoft's current practices, I think this is a very wise decision. However, my thoughts above question whether the current context Microsoft has is the correct context to be in in the first place. And for that reason, I still question the value behind the decisions made because of the reasons that they were made (especially when I feel there is a better decision that will benefit both Microsoft and its customers). The glaring thing to me though is that Bill Gates is the millionaire and I'm just a lonely developer without hardly any monetary worth at all. Perhaps I'm the one who is off-base here?

What do all of you think?

An Avalon Threading Story

Jason Olson — Fri, 09 Apr 2004 03:33:00 GMT

Hello all. I wanted to let you know that I wrote an article on the threading model in Avalon (more specifically, multithreaded UI development in Avalon vs WinForms). You can find it on my blog here. Or you can just view the new article category I started on the left, Longhorn Articles.

I would like to give a quick thanks to Chris Sells for being willing to edit this article and help me get it into shape. Thanks Chris!

It's All About The Contexts

Jason Olson — Tue, 30 Mar 2004 01:48:00 GMT

For any of you becoming interested in Indigo development, you would do yourself some good by becoming familiar with the UIContext object. Why? Well, that will take many more words the first sentence.

For anyone familiar with multi-threaded programming, you are probably already familiar with the concept of Contexts. For those not familiar with multi-threaded programming, let me explain. In the world of Indigo, you might have to deal with Contexts in many places. One is if you derive your own MessageHandler from the SyncMessageHandler. Another might be if you create your own client “callback” interface (maybe by deriving an interface from IDialogPortTypeChannel and then providing any ServiceMessages to communicate with the client).

SyncMessageHandler

You can develop a synchronous message handler in Indigo by deriving your own class from SyncMessageHandler and overriding the ProcessMessage method. If you are wanting to communicate with an Avalon UI though, you need to be aware that when the ProcessMessage is called, the call will come in on a different thread than the UI. To mitigate this issue, your MessageHandler must know the UIContext that the UI is running on. To get the current UIContext (if your MessageHandler “knows about” the Avalon Window), you could always just call the Context property on any of the controls in the window. However, this is not very scalable. The better way, in my opinion, is to pass the UIContext into the MessageHandler's constructor or through a property on the MessageHandler class.

Once you have the the current UIContext, you need to call the BeginInvoke method to invoke a method in your class *in* the context of the UI. This allows you to update and change properties on the UI, and have the changes reflected in your running program. If you don't do this, it will appear that your UI is never being updated when in fact, it *is* being updated, just in a different UIContext. To see how to use the BeginInvoke method, please refer to the Longhorn SDK. *Note: to see it in person, there is an example of how to use it in VB on the MSDN-TV episode, “Lap Around Longhorn” with Don Box and Chris Anderson.

IDialogPortTypeChannel

This one can be a little more simple to solve. One thing that I love about the Dialog capabilities of Indigo, is that if you derive your client interface from IDialogPortTypeChannel, you can have the ServiceMessages show up as events in the class that is produced for that service by wsdlgen. For instance, if I have the following interface:

public interface IClient: IDialogPortTypeChannel
{
[ServiceMessage]
void MessageReceived(string from, string message);
}

and I pass that interface into all my ServiceMessages on my service, then wsdlgen will generate MessageReceived as an event that my client side code subscribes to. If you do use this method, you still need to be aware of the almighty UIContext. Once again, when the event is triggered, the code handling the event is executed in the context that the event came in on (and you guess it, it is a different context than the UI is running in).

Well, depending on your code, this can be a lot easier to mitigate. If you are handling all your event handling in a different class than your UI class, then you will have to do the same as described above for SyncMessageHandler. However, if you are handling the event in your UI class, you don't need to worry about UIContext.BeginInvoke. In this case, the UIContext class has two methods that you can take full advantage of, Enter and Exit. Why don't you have to pass the UIContext around like before? Well, it is because one of the properties of an Avalon Windows Control is a UIContext property (called Context). So, in your code-behind where you capture the event, you can call Enter and Exit methods on the Context property of your Window.

Conclusion

I know I haven't discussed *much* here in this post, but I hope that it will save you from any future headaches when you start programming Indigo-enabled Longhorn applications.

Until next time, this has been Jason Olson and that's how the cheese melts. Ciao!

Longhorn Tip #1 - DockPanel.Dock (XAML != HTML)

Jason Olson — Wed, 24 Mar 2004 22:34:00 GMT

[Disclaimer: Any or all behavior described in this article is against the PDC03 build of Longhorn, and may change or be removed altogether in future builds of Longhorn.]

[Note: This tip may be obvious and already known to people developing in XAML today. I am just sharing it to relieve some of the frustrations web developers might have when learning XAML in the future.]

XAML does NOT equal HTML

While this may seem obvious at first, you really need to get over that barrier when you start developing in it. XAML is not a markup language, per se. XAML is more language, and less markup. Think of it more as a general purpose programming model that is wired directly into the CLR (for the 'softies out there, please correct me if this statement sounds incorrect).

Once you accept that XAML is not HTML, you need to let go of the assumption that the order you see certain XAML tags in, is the order those elements will appear on the screen. Let's take the following code snippet:

<DockPanel Width="100%">
    <Border DockPanel.Dock="Top" Height="25%" Background="Pink" BorderThickness="2" BorderBrush="Black">
          <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Top 1</SimpleText>
    </Border>
    <Border DockPanel.Dock="Top" Height="25%" Background="Pink" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Top 2</SimpleText>
    </Border>
    <Border DockPanel.Dock="Bottom" Height="25%" Background="Cyan" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Bottom 1</SimpleText>
    </Border>
    <Border DockPanel.Dock="Bottom" Height="25%" Background="Cyan" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Bottom 2</SimpleText>
    </Border>
</DockPanel>

At first glance, one might assume that the code above would present the image below (reading “Top 1“, “Top 2“, “Bottom 1“, “Bottom 2“ from the top to the bottom of the screen):

However, this assumption would be wrong. It makes perfect sense when you think about the order that our elements are being processed in. The first element that the parser encounters with a DockPanel.Dock value of “Bottom“ will be the first element locked to the bottom. The next element with the same “Bottom“ value, will be locked on TOP of the prior one (there might be ways to get around this, so please feel free to challenge me if you believe I am wrong). The image actually generated from the code above will look like this (notice how the “Bottom 2“ text is actually on top of the “Bottom 1“ text):

DockPanel.Dock = “Fill“

When first learning XAML, things can get even more potentially confusing if you use DockPanel.Dock=“Fill“. As another example, take the code below. The order of the code seems pretty logical. First the “Top“ docking, then the “Fill“ docking which is in the middle, and then lastly the “Bottom“ docking.

<DockPanel Width="100%">
    <Border DockPanel.Dock="Top" Height="25%" Background="Pink" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Top</SimpleText>
    </Border>
    <Border DockPanel.Dock="Fill" Background="White" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Fill</SimpleText>
    </Border>
    <Border DockPanel.Dock="Bottom" Height="25%" Background="Cyan" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Bottom</SimpleText>
    </Border>
</DockPanel>

Unfortunately, this does not produce the intended. Because the “Fill“ is presented before the “Bottom“, the “Fill“ element will take up the entire bottom part of the screen, effectively “covering“ the “Bottom“ element. See the image produced below to see what is rendered from the code above.

Obviously, this is not what we expected to happen. To fix this, we simply move the “Fill“ element below the “Bottom“ element (like shown below) and everything renders as expected.

<DockPanel Width="100%">
    <Border DockPanel.Dock="Top" Height="25%" Background="Pink" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Top</SimpleText>
    </Border>
    <Border DockPanel.Dock="Bottom" Height="25%" Background="Cyan" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Bottom</SimpleText>
    </Border>
    <Border DockPanel.Dock="Fill" Background="White" BorderThickness="2" BorderBrush="Black">
        <SimpleText VerticalAlignment="Center" HorizontalAlignment="Center">Fill</SimpleText>
    </Border>
</DockPanel>

If you are using a flow layout instead of an absolute-positioning layout, order of elements in your XAML is quite important. Remember that, and you shall always be blessed with Longhorn Zen!

Until next time, this has been Jason Olson and that's why the sky is blue. Ciao!

Great, now I'm tainted, all mad-cow like!

Jason Olson — Mon, 22 Mar 2004 02:35:00 GMT

You heard me, my friends. I am now completely contaminated. I'm more tainted than a bovine with mad-cow disease. 'Nix that. I'm more tainted than a syphilitic prostituting leper. 'Nix that. I'm more tainted than a syphilitic, prostituting, leprous walking hamburger patty. That's right, THAT tainted. (Dear John Doe, if you are offended by my use of the phrase “syphilitic, prostituting, leprous walking hamburger patty” then I apologize dearly. Obviously, no offense was meant by it. If you happen to suffer from the condition mentioned above, then I gravely offer my apology knowing full well that you will most likely be dead within the next week).

Why am I so tainted you might ask? Well, because I've been programming in Longhorn and Whidbey all weekend. Now why this normally might be a very good situation, I ask you this: How am I supposed to return to work and program in ASP.NET 1.1? I feel like I will be going back to program, only with the aide of punch cards and duct tape (Oh, the hanging chads! Oh woe is me!).

Enough kidding. You may ask how I really feel. Well, how do I feel? Excited! I am greatly excited for the future that this group of technologies will bring us. Don't get me wrong, there are plenty of places that still need polish. My favorite is getting a “method not implemented yet” exception. That's a great one! In preparation of developing the game I dropped a teaser about, I developed a simple chat application that utilized the new MessageBus namespace in order to build the client/server architecture. It only took just about half the day to get most of it running (and I have a feeling it would have been shorter if I was more familiar with the new platform). And Oh!, the beautiful generics. I am so glad to finally be using them. I am thinking of posting an article on the small application when I am finished with the next article in my game development series (no, I haven't forgotten about that series :~)). Below is a screenshot of the application I wrote (I apologize to all dial-up users out there for two large images in a row (speaking of, why aren't you on Broadband yet?!?!?!?)). It's definitely not a thing of beauty (insert your scorn for my lack of UI design skills here). Oh well!

Until next time, I'm Jason Olson and that's how the cookie crumbles! Ciao!

The Projects

Jason Olson — Sat, 20 Mar 2004 17:05:00 GMT

Well, I informed all of you that I would let you in on a project I am currently working on. In truth, it's not really Super-Duper or Ultra-Confidential. I suppose the only thing I said about it that is true is that it is an upcoming project. Can you all please forgive me for lying to you? I know it can be hard to forgive a loved one when they have done what I did, so please forgive me because I love all of you. (awwwwww ::tear::)

Well, even though the project is not Super-Duper or Ultra-Confidential, I happen to think it is pretty darn cool and exciting. I suppose this is the point in the show that I am suppose to wave a magic wand and pull a bunny out of a hat, but considering that I have neither a magic wand, nor a bunny, this screenshot will have to do.....

Welcome Back Longhorn

Jason Olson — Mon, 15 Mar 2004 03:37:00 GMT

Well, I'm finally back to using Longhorn. It definitely feels great. Expect to hear more from me in the future about programming in Longhorn (perhaps even about what Longhorn means to game development (as well as how to do it (game development in Longhorn that is))). I will continue to write and update my current series of articles, but expect me to throw in a Longhorn tidbit or two every once in a while (I just have four words for everybody: “Avalon and Indigo, Baby!!!!”).

I can't wait, it's going to be all dat and a bag o' chips...

Peace out, home-skillets....

Wow! A Longhorn RSS Aggregator already!

Jason Olson — Thu, 19 Feb 2004 07:01:00 GMT

Adam Kinney has definitely been doing some cool stuff with Longhorn. I think he topped himself this time. He just realized a pre-Alpha (or Alpha?) version of his RSS Aggregator, Ocel, for Longhorn. Nice work Adam!