March 2005 Entries

Ahh... only five hours remaining until the fruit of the past few months of my life goes into Beta. Feels pretty good now that we're nearing the end of things, but can you imagine having this thing hanging in your row reading only one month left with a high bug count and incomplete feature set on your hands? Not much fun then. ;)

VPC Beta Countdown Clock

posted Thursday, March 31, 2005 3:32 PM | Comments | Filed Under [ Personal ]

I came across this post and figured I'd offer up my own opinions as well...

The default formatting would honestly keep me from using the class designer for anything but reverse engineering and visualizing the code I have already hand written. Even though everyone has a different way of doing it, the structure of the code is what really matters when it comes down to efficiently parsing it with the human brain. And let's face it, we're still not at a point (yet) where developers can avoid editing the source files by hand.

You should really be able to control the output of the class designer. I haven't looked at the VS.NET 2005 APIs at all, but wouldn't it be smart to have a pluggable output API? I realize it wouldn't be for the faint of heart since the VS.NET codedom APIs aren't exactly brain dead simple, but that shouldn't mean that it not be possible at all. Has anyone out there played with the VSIP APIs for 2005 yet? Would this type of customization be possible?

posted Wednesday, March 30, 2005 4:09 PM | Comments | Filed Under [ .NET ]

Just noticed, via a post from Chris Sells, that the MSDN Product Feedback application is now accepting bugs for Avalon and Indigo. Here's your chance to provide feedback and bug reports to Microsoft. Don't like the way something works? Having problems with a certain scenario? Well this is the place to let Microsoft know now before the product is released. Speak now or forever hold your peace... ;)

posted Wednesday, March 30, 2005 3:55 PM | Comments | Filed Under [ WinFx/Vista ]

Came across DesignersLove.Net via a post over on Chris Anderson's blog. It's just getting started, but I'm already sending the link out to all of my designer friends. I have been trying to preach to them about the separation of content and behavior in Avalon and they really seem to love the idea of maintaining complete control over their content. I think the harder part is teaching the developers how to design controls so that their behavior is completely separated from the content. Microsoft has coined the term “look-less controls” to describe this pattern.

It's a challenge to design controls this way because you need some kind of visual representation for your control by default, but you also need to consider that someone may completely replace your control's visual tree and it still needs to maintain the same behavior regardless.

Interesting times lie ahead for both designers and developers...

posted Friday, March 25, 2005 9:04 AM | Comments | Filed Under [ WinFx/Vista ]
Saw this morning that the SDK is now available to the masses. Click here to head on over and download it. Make sure you're running the right VS.NET versions and that you pay close attention to the uninstall/re-install order. FWIW, I had no problems uninstalling the previous CTP and installing the new CTP on top of the same VPC instance.
posted Friday, March 25, 2005 8:53 AM | Comments | Filed Under [ .NET WinFx/Vista ]

I've been sitting on a lot of thoughts about this whole AJAX phenomena that is sweeping the industry lately. Tons of people have thrown their two cents in already and I've been meaning to post my thoughts, so here goes. :) 

First off, let me beat the horse one more time and say: AJAX is nothing new. It's a nice initiative to have a standard library, but people are kidding themselves when they say this is a revolution of the web. The very browser features that AJAX is founded on have been in IE forever. If you want to wonder why people write proprietary stuff for IE it's because, pretty much up until Mozilla came along, it was the only browser that offered enough power to actually be able to create DHTML applications like those that we're just starting to see in the mainstream these days. If you want to blame someone for it not being available in other browsers, blame the creeping standards body which to this day still has no specification for something as simple as a component model in DHTML despite the fact that a proposal from Microsoft has been sitting in the queue since 1998. Yeah, it wasn't perfect, but if it was adopted even in it's original form the development world wouldn't still be writing script to emulate such an architecture to this day.

As usual, there's a bit of a double standard when it comes to standards. Why is it that people can overlook that this is a proprietary extension by Mozilla (adopted from Microsoft no less!)? Why aren't the all the standards zealots who love to constantly bitch about IE's non-compliance with the DOM going insane over the fact that there's a perfectly good specification, called DOM Level 3 Load and Save sitting there in recommendation status since 4/7/04, which Mozilla should have implemented instead of cloning IE's XmlHttpRequest? It should also be noted that in addition to the cloning of the proprietary XmlHttpRequest, Mozilla has also followed Microsoft in introducing it's own proprietary DOM document creation APIs (Microsoft has XMLDOMDocument via ActiveX, Mozilla has DOMParser/XMLSerializer as first class JavaScript objects). Why go proprietary when there is also a perfectly good specification for these things sitting around waiting to be implemented called DOM Level 3 Core?

What actually prompted me to finally sit down and write something up was my pride rising up when I read this post I came across today over on Dare's blog. :) I would argue that my company actually beat Microsoft's Auction Demo App hands down because we wrote a fully functional, browser based staff tracking application, called StaffTrak, on IE4.0. This is obviously well before there was even any XmlHttpRequest available, so how'd we do it? Well back then Microsoft had this nice little Java class called the XMLDSO, which is short for XML Data Source Object. We did all our communication with the backend by embedding the XMLDSO Java component on the page via <applet> and then automating it with JavaScript. I've written about this application before, but here's the details again. I wrote them up on 2/15/99, so when I say “last year” obviously I mean '98. Also I found this article about my old company, Square Earth, which mentions our work on the project and, if you notice, is dated 10/3/97 (note: you need to scroll down a bit). Oh and btw, yes... this application was actually deployed into a production environment and provided a real world solution for Microsoft's NYC office. ;)

In closing, I want to be clear I'm not against AJAX, Mozilla or Google in any way. In fact, I'm all for a standard script library so I can stop having to invent it all myself. :) All I'm trying to get across is that this stuff has been happening on the web for years. Google just happen to come out with a very public showcase app for these technologies when they released Google Maps and they certainly deserve all the credit they've received for the application because it rocks. In the end though, they should not receive all the credit for being the only company that's really innovating on the web by leveraging the underlying technologies that the browsers supply us with.

posted Thursday, March 24, 2005 2:55 PM | Comments | Filed Under [ Web Development ]
The simplest development environment for those of us diving into Avalon these days has just been updated. AvPad, originally called XamlPad, offers a really simple RAD experience for people who want to mock up Avalon interfaces or just learn XAML+Avalon in real-time.
posted Monday, March 21, 2005 4:30 PM | Comments | Filed Under [ WinFx/Vista ]
Here's the official word on all the changes in the Avalon March CTP drop. As a result I will not be making any more changes to the temporary change log I created for the die hard Avaloners out there that needed the info day zero.
posted Friday, March 18, 2005 5:06 PM | Comments | Filed Under [ WinFx/Vista ]

You know VS.NET 2003 is going to blow up when you look at the process with cordbg and see way too many “Compilation Domains”:

PID=0x910 (2320) Name=C:\Program Files\Microsoft Visual
Studio .NET 2003\Common7\IDE\
ID=113 AppDomainName=Compilation Domain
ID=112 AppDomainName=Compilation Domain
ID=111 AppDomainName=Compilation Domain
ID=110 AppDomainName=Compilation Domain
ID=109 AppDomainName=Compilation Domain
ID=108 AppDomainName=Compilation Domain
ID=107 AppDomainName=Compilation Domain
ID=106 AppDomainName=Compilation Domain
ID=105 AppDomainName=Compilation Domain
ID=104 AppDomainName=Compilation Domain
ID=103 AppDomainName=Compilation Domain
ID=102 AppDomainName=Compilation Domain
ID=101 AppDomainName=Compilation Domain
ID=100 AppDomainName=Compilation Domain
ID=99 AppDomainName=Compilation Domain
ID=98 AppDomainName=Compilation Domain
ID=97 AppDomainName=Compilation Domain
ID=96 AppDomainName=Compilation Domain
ID=95 AppDomainName=Compilation Domain
ID=94 AppDomainName=Compilation Domain
ID=93 AppDomainName=Compilation Domain
ID=92 AppDomainName=Compilation Domain
ID=91 AppDomainName=Compilation Domain
ID=90 AppDomainName=Compilation Domain
ID=89 AppDomainName=Compilation Domain
ID=88 AppDomainName=Compilation Domain
ID=87 AppDomainName=Compilation Domain
ID=86 AppDomainName=Compilation Domain
ID=85 AppDomainName=Compilation Domain
ID=84 AppDomainName=Compilation Domain
ID=83 AppDomainName=Compilation Domain
ID=82 AppDomainName=Compilation Domain
ID=81 AppDomainName=Compilation Domain
ID=80 AppDomainName=Compilation Domain
ID=79 AppDomainName=Compilation Domain
ID=78 AppDomainName=Compilation Domain
ID=77 AppDomainName=Compilation Domain
ID=76 AppDomainName=Compilation Domain
ID=75 AppDomainName=Compilation Domain
ID=74 AppDomainName=Compilation Domain
ID=73 AppDomainName=Compilation Domain
ID=72 AppDomainName=Compilation Domain
ID=71 AppDomainName=Compilation Domain
ID=70 AppDomainName=Compilation Domain
ID=69 AppDomainName=Compilation Domain
ID=68 AppDomainName=Compilation Domain
ID=67 AppDomainName=Compilation Domain
ID=66 AppDomainName=Compilation Domain
ID=65 AppDomainName=Compilation Domain
ID=64 AppDomainName=Compilation Domain
ID=63 AppDomainName=Compilation Domain
ID=62 AppDomainName=Compilation Domain
ID=61 AppDomainName=Compilation Domain
ID=60 AppDomainName=Compilation Domain
ID=59 AppDomainName=Compilation Domain
ID=58 AppDomainName=Compilation Domain
ID=57 AppDomainName=Compilation Domain
ID=56 AppDomainName=Compilation Domain
ID=55 AppDomainName=Compilation Domain
ID=54 AppDomainName=Compilation Domain
ID=53 AppDomainName=Compilation Domain
ID=52 AppDomainName=Compilation Domain
ID=51 AppDomainName=Compilation Domain
ID=50 AppDomainName=Compilation Domain
ID=49 AppDomainName=Compilation Domain
ID=48 AppDomainName=Compilation Domain
ID=47 AppDomainName=Compilation Domain
ID=46 AppDomainName=Compilation Domain
ID=45 AppDomainName=Compilation Domain
ID=44 AppDomainName=Compilation Domain
ID=43 AppDomainName=Compilation Domain
ID=42 AppDomainName=Compilation Domain
ID=41 AppDomainName=Compilation Domain
ID=40 AppDomainName=Compilation Domain
ID=39 AppDomainName=Compilation Domain
ID=38 AppDomainName=Compilation Domain
ID=37 AppDomainName=Compilation Domain
ID=36 AppDomainName=Compilation Domain
ID=35 AppDomainName=Compilation Domain
ID=34 AppDomainName=Compilation Domain
ID=33 AppDomainName=Compilation Domain
ID=32 AppDomainName=Compilation Domain
ID=31 AppDomainName=Compilation Domain
ID=30 AppDomainName=Compilation Domain
ID=29 AppDomainName=Compilation Domain
ID=28 AppDomainName=Compilation Domain
ID=27 AppDomainName=Compilation Domain
ID=26 AppDomainName=Compilation Domain
ID=25 AppDomainName=Compilation Domain
ID=24 AppDomainName=Compilation Domain
ID=23 AppDomainName=Compilation Domain
ID=22 AppDomainName=Compilation Domain
ID=21 AppDomainName=Compilation Domain
ID=20 AppDomainName=Compilation Domain
ID=19 AppDomainName=Compilation Domain
ID=18 AppDomainName=Compilation Domain
ID=17 AppDomainName=Compilation Domain
ID=16 AppDomainName=Compilation Domain
ID=15 AppDomainName=Compilation Domain
ID=14 AppDomainName=Compilation Domain
ID=13 AppDomainName=Compilation Domain
ID=12 AppDomainName=Compilation Domain
ID=11 AppDomainName=Compilation Domain
ID=10 AppDomainName=Compilation Domain
ID=9 AppDomainName=Compilation Domain
ID=8 AppDomainName=Compilation Domain
ID=7 AppDomainName=Compilation Domain
ID=6 AppDomainName=Compilation Domain
ID=5 AppDomainName=Compilation Domain
ID=4 AppDomainName=Compilation Domain
ID=3 AppDomainName=Compilation Domain
ID=2 AppDomainName=Compilation Domain
ID=1 AppDomainName=DefaultDomain

Why aren't these domains being Unload()ed? Isn't a service pack coming out to address these known issues? I'm really getting tired of the daily explosions and hangs that I have to deal with. :(

posted Wednesday, March 16, 2005 5:05 PM | Comments | Filed Under [ .NET ]
As expected, the March CTP drop of the Avalon+Indigo+WinFX SDK has been released to MSDN subscribers. I imagine it will be available to the general public within the next couple of weeks.
posted Wednesday, March 16, 2005 9:53 AM | Comments | Filed Under [ WinFx/Vista ]

The documentation for the March CTP of Avalon has been released. I assume we can expect the actual SDK to be released soon. Here's a brief change log that I've started gathering on my own, I will continue to expand the article over time.

posted Tuesday, March 15, 2005 3:51 PM | Comments | Filed Under [ WinFx/Vista ]

Scoble says Aero is not based on Avalon. I'm not so sure about that. To the best of my knowledge it is. I mean, it's entirely possible that it's not since it could skirt around Avalon and talk directly to DirectX and/or the Longhorn Display Driver Model (LDDM) itself, but then that would mean that I've been gettings some seriously mixed messages on the subject.

Can we get some third party clarification on this one? :)

Update:

As some others have pointed out, perhaps what Scoble meant is that Aero doesn't use the managed APIs of Avalon. It most likely just talks to the Media Integration Layer (MIL) API directly. While this isn't what most people think of as Avalon, it does fall under the technology's umbrella as far as I know. Click here for a great article that discusses what the MIL is all about, written by Mr. Avalon himself (Chris Anderson). Note that the article is a year old now and some of the terminology has changed, but the principals of the MIL covered in the article have not.

posted Monday, March 14, 2005 12:13 PM | Comments | Filed Under [ WinFx/Vista ]

I'm sure we've all seen Richard's commentary on the state of .NET as well as Dan Fernandez's rebuttal. If not, go read those first. Since the subject has already been talked to death from the .NET framework perspective, the only thing that I wanted to address is the assertion that Richard makes in his follow up comment in Dan's rebuttal where he states:

As to your comments on Avalon and Indigo. I concede your point about Indigo, but I refute your point about Avalon. In Dec 2004 a tech preview of Avalon was made publicly available on MSDN downloads, and by examining this with ildasm it is clear to me that Avalon is yet another wrapper over Win32. Avalon is based on Windows messages, and uses GetMessage, DispatchMessage et al, that Windows developers have been comfortable with since 16 bit Windows!

First off, Richard's absolutely right, there are all kinds of calls to Win32 messaging APIs in the Avalon CTP. However, the important thing to realize is that none of this is exposed via the Avalon API itself. Of course there needs to be calls to Win32 APIs under the covers, this is just how things get done on Win32. Therefore, backporting Avalon to Win32 meant that some things had to be accounted for and handled using the existing platform's plumbing. Why do we care how Avalon is implemented under the covers so long as those details are hidden from us? If I can write an Avalon application that runs on Win32 just as good as it will run on WinXXX three to five years from now, who cares what they do to preserve that?

Let's examine the one specific area which demonstrates Avalon's abstraction from the underlying OS: the UIDispatcher class. The UIDispatcher class' job is to dispatch messages received from the underlying OS to the UIContext for a particular Avalon application. Now obviously in Win32, these messages need to be handled via a message pump, so there is a specific implementation of a UIDispatcher called the Win32Dispatcher (go figure). More specifically, if you're writing an Avalon application that is going to use WinForms controls (or any windows controls really) you need to go one step further and use the HwndDispatcher. Oh and by the way, this is also the piece that enables the reverse scenario: Avalon controls hosted in legacy Windows/WinForms applications. The key to this part of the API though is that this is the piece where things get translated from native OS messages to strongly typed Avalon events. Beyond Win32Dispatcher, there is no such thing as a Win32 style message.

Next let's examine the most obvious dependency of Avalon: DirectX. Under the covers, Avalon is making heavy use of the DirectX API in order to achieve its rendering goals. This is another area where there is there is just zero leakage in the API. As an Avalon programmer working at almost the deepest depths of the graphics plumbing in the API I see no signs of DirectX whatsoever. What does this mean? It means that once again Avalon could technically run on any graphics API under the covers. It happens to be DirectX9 right now, but whenever DirectX10 rolls out the Avalon team could also roll out some optimizations to the Avalon API which take advantage of that version without my application being any wiser.

So, is this a bad thing? If so, I just don't see it. What this really means to me is that they're doing an excellent job separating Avalon from any one underlying architecture and, in fact, enabling it to run optimally on any architectures they introduce down the line with very little work and almost zero changes to existing applications. The reason we're at the point where Avalon is even being built on these “older” architectures, as has already been mentioned, is because customers were demanding it and Microsoft actually listened.

posted Monday, March 07, 2005 9:32 AM | Comments | Filed Under [ .NET WinFx/Vista ]

Ok, so I was reading /.'s coverage of Mark Lucovsky jumping ship from MS to Google. Naturally I expected the typical anti-MS spin and of course it was there, but in the form of link to an entry on Mark's blog about Microsoft not being very good at shipping software. In this entry Mark analyzes the way Microsoft ships their software (specifically he mentions the .NET framework) vs. the way Amazon ships a fix for their software (their web site). Maybe if Mark expanded a little bit on what he believes the right answer to the problem is I could understand his angle a little better, but how you can make this comparison of shipping software to a controlled environment vs. millions of user's desktops is beyond me. That said, I did want to just talk about the .NET Framework part for a minute.

For starters, the .NET Framework is available on Windows Update. It's just an optional component to install because you don't need it to use windows. You could technically ship your application with an installer that detects that the framework is not installed and tell them to get it from Windows update, but why make the user go through all the trouble. Just slap the resdistributable merge module into your installer and ship it with your application. This is exactly the way DirectX works for example. Sure you can grab the latest from Windows update, but almost all video driver installs and/or game installs ship with the latest version so that when the user installs their new card or the latest game they can just start playing right out of the box.

So now let's consider how updates are handled for Microsoft's biggest application: Office. Office Update is there, people can check for and grab the latest updates whenever they want. The updates aren't forced, but why should they be? If people are perfectly happy with Office the way it is why would you badger your users to download megs of updates just because you refactored your code and improved speed of a certain operation by 10%?

Ultimately I believe Microsoft is getting better and better at breaking their products into smaller more manageable pieces. This is eventually going to lead to smaller, faster updates for the OS as well as applications. They are also working very hard on delivering the Smart Client technology with .NET 2.0. Using ClickOnce the install procedure can literally be the equivalent of clicking on a link and approving/denying some rights the product may require to run. For updates, each time you launch the application, or based on a schedule, it can check if there are updates and ask if the user wants to download them. Longhorn is going to ship with with all of this functionality baked right in. As a result, we should see more and more programs, both by Microsoft and third parties, start to use this functionality to perform installation and updating of products.

posted Thursday, March 03, 2005 4:57 PM | Comments | Filed Under [ .NET WinFx/Vista ]

Now, I loooove Mozilla/FireFox and am so happy that there's such a great alternative to IE (especially since it's available on other platforms) so this isn't a knock on the technology. It's targeted at the people who like to pretend that the Mozilla/FireFox codebase is somehow blessed by the software gods to be completely free of flaws/vulnerabilities. The realists in this industry already know there's no such thing, but apparently some people are still too near sighted to admit it.

Eight vulnerabilities had been discovered in 1.0 and just recently patched with 1.0.1. Naturally I expect an extremely slanted view from the /. crowd, but man this post's discussion thread is loaded with denial. My favorite happens to be this one which is somehow rated as 4 - Informative. You gotta be kiddin' me, right? I swear intelligence goes right out the window when people are so religious about something. Can you imagine the rating and ensuing discussion if someone wrote the same reply for a security related post about IE??? Woo... that thing would be on fire.

Anyway, everyone make sure to update.

posted Wednesday, March 02, 2005 6:33 PM | Comments | Filed Under [ Web Development ]

Adobe has open sourced a couple libraries they're working on called Adam and Eve. From my brief skim through the overview, both libraries essentially sound like they aim to provide a cross platform architecture that is somewhat equivalent to what Avalon is going to deliver for Windows. Adam, for example, sounds somewhat like the DependencyObject + DependencyProperty + Expression features of Avalon. Eve defines a syntax (like XAML, but not XML) and a layout engine. They're already talking about an Eve2 where they separate the syntax from the model so that other syntaxes can be leveraged to create an Eve object graph. In other words one could write a basic XAML parser that constructs an equivalent Eve object graph. Or, even more useful, one could write an HTML parser that constructs an Eve object graph.

posted Wednesday, March 02, 2005 12:32 PM | Comments |

So what do you do when someone blantantly wants to rip off your company's entire serviceHere's a google cache just in case it disappears.

My favorite part of the listing is that the lister expects the whole thing to be done in 30days. Good luck I say. :)

posted Wednesday, March 02, 2005 10:04 AM | Comments | Filed Under [ Personal ]

This post goes out to whoever in Microsoft might be able to shed some light on the subject:

When, if at all, can we expect to see support for E4X in JScript[.NET]?

My main reason for asking is because Mozilla recently added support for it to their ECMAScript implementation and I can already see the same thing that happened when people wrote code for proprietary DOM implementations is going to start happening again. This time though, it's going to be E4X code not working in IE. I realize C-Omega should eventually result in similar features being added to C# 3.0, but that's no reason for JScript.NET not to run with E4X as well. The problem is though, IE uses the ActiveScripting version (JScript), so it's more important for that version to be updated to support the spec since that's the implementation that matters when it comes to every day web browsing.

posted Tuesday, March 01, 2005 3:24 PM | Comments | Filed Under [ .NET Web Development ]

Well Yahoo has released their search engine web service APIs. The fact that they chose to ignore industry standard communication protocols (SOAP + WS-*) was just a bad decision IMHO. Now all the toolkits that exist for various languages/frameworks are useless in helping the programmer develop against these APIs and everyone must roll their own XML parsing.

Something that could have taken ten seconds of running your favorite language wrapper generator now boils down to you having to write extensive amounts of XML generation/parsing logic. I see they released some sample client implementations for ECMAScript and Java, but noticeably absent is an sample implementation for .NET. Hmmm...

posted Tuesday, March 01, 2005 1:23 PM | Comments | Filed Under [ Web Services ]