Daily Archives: January 17, 2005

Clarke Scott produces CRM software.

Clarke Scott, one of the Australian .NET blogging crowd (OPML) has started a microISV (at the moment). He is working on some fantastic crm software and needs some GoogleJuice to get the word out.


.NET Screen Capture Tool @ Project Distributor

Darren showed me this neat little utility by Brian Scott on Friday last week which takes screenshots of regions of the screen. I really liked the user interface (and the fact that it was a .NET application) – installed.

Project Distributor is definately grown thanks to Darren’s hard work, and its great to see some of the community software that is being developed and hosted there.

TechEd Keynote Speaker?

Chuck asks who we would like the keynote speacker for TechEd to be. It would be great to see Don Box present again, but since you aren’t going to be able to get him Paris will have to do. Seriously though, if you want me to be there you will need to get both of the sisters in a bath tub with Don.

Really serious now – honestly! I’d like to see some kind of presentation like this that they did at TechEd EMEA this year. Obviously this one had too much of a dev spin on it but I am sure you could come up with something comical that ties together the infrastructure and dev tracks. Basically I want to be entertained – not bored to death with slide decks.

Some people are misinformed about Avalon.

I am not sure when I subscribed to Stephane Rodriguez’s weblog, but I’m sure it would have been because a search feed dug up something that was posted that annoyed me (I have a policy of subscribing to peoples blogs who challenge my thinking), but now this post takes the cake.

What gets me is how someone who is intelligent enough to start a weblog to express their opinions can be so misinformed that it is almost criminal, lets take a look at some of the content from this recent post on Avalon on Windows XP.

why would anyone invest in using this Avalon API for graphics when 1) there are so many very light alternative and often free engines for that matter (most wel lknown being OpenGL and APIs on top of it) 2) engines like QT are cross-platform : Perforce source control system uses QT to back their UI front-end and it looks the same regardless the OS. So what, you want to optimize your code for one Windows revision, while customer needs in the future are demanding ubiquity and servicing? I wonder how much of your employment you are trying to keep at bay doing so?

I have to admit to being a novice when it comes to QT, but from what I understand and have seen it is essentially a windowing tool-kit for producing user interfaces. Thats not a bad thing – thats what Windows has today – but in the future we will need more, and that is where Microsoft is taking us with Avalon. Avalon exposes a rich 3D environment which is equally usable by 3D artists and by business application developers. I was talking to some software engineers last week and made the point that we are now living in a world where most of the population has been watching television for twently years. They want their applications to deliver that same engaging experience (and not in the Days of Our Lives brain-rot way).

It does this by taking DirectX (not unlike OpenGL) and layers on top of it a set of APIs for producing a business application while at the same time exposing all the features that a 3D rendering surface can provide like rich data visualisation. Microsoft is essentially taking the best of the gaming world and the best of window world and blending them together.

On the subject of standard UI’s across platforms, I think the jury is still out on whether that is a good idea. If I have a Ferrari I don’t want to have to drive with the hand brake on just because someone else decided to go with a v-dub. I recall an interview done with Ray Ozzie (Groove Networks, formerly of Notes fame) where he mentioned the approach he took when working at Lotus was flawed in trying to standardise the interface across platforms. Unfortunately I can’t find the original article I am thinking about (its about 3.5 years old now I think), but I found this where he makes a similar remark (about half a page down):

Ray: Although we’re not announcing our non-Windows platform plans at this time, we are indeed demonstrating a Linux port. The product was designed with a multi-platform porting architecture, with an eye toward “best of breed” user interface on any given platform, but also permitting full-fidelity data synchronization regardless of UI.”.

Now to Stephane’s next comment:

 last but not least, Avalon is part of WinFX which is the codename of .NET 3.0 : you might find yourself embarassed that an API that does vector-based graphics (not only that, but be prepared to see a lot of it) might not work that well depending on your Windows XP “fill the blank” edition : like I said above, it’s not all Windows XP flavors, and then we have this reduced support for mobile versions of XP : is the huge gap between .NET compact framework and .NET “desktop” framework going to be filled before Avalon really ships? Looks like an herculean task to me, pretty much incompatible with priorities related to getting a stable version of Avalon on a desktop computer.

I don’t think Microsoft are done with their plans for Avalon on Windows XP. Rewriting the next generation graphics stack is not an easy task, and I think the authors of QT would agree there, but one thing here is actually incorrect.

If you look at the various builds of Longhorn that have been kicking around for a while you will notice that they are actually the .NET 2.0 framework which is getting released this year as part of Visual Studio 2005 (runtime will – of course – be available seperately). Microsoft haven’t even gotten into the full swing of their envisioning phase for Orcas (the IDE for the next version of .NET), so I am doubtful that Longhron will use a CLR much different than that which ships later this year with .NET 2.0 – it might have some patches or something.

Avalon and the Compact Framework? Well, I would never say never, but I don’t think Microsoft’s goal is to have feature parity between the Compact Framework and full-blown framework that lives on the desktop or server. They are very different form factors and as a result the graphics stacks they require are very different.

And about runtime size?

 260MB a download : I need not add any further comment here. I am not sure whether this includes the .NET 2.0 framework SDK, DirectX9, but I am not optimistic about it. If the download ends up being a whole CD download, who is willing to write apps that might require not to ship the equivalent of a CD onto end-user machines, but at least a fraction of it? I recently saw a download link for DirectX 9, and the run-time alone is 34MB. This definitely says it all about apps/games delivered through the wire…

You are right, 34MB is quite large for a runtime (DirectX). I’m not sure if anyone has any idea how big a footprint Avalon will have for the runtime just yet so its a bit early to comment. One thing I would say however is that I’ve been sitting on a broadband connection for about five years now and 34MB really doesn’t worry me, especially if its a one off download from Windows Update.

Outsourcing at home.

Kieran points to a ZD Net article which notes how some companies are starting to look how they can outsource development at home. I’ve often wondered why in Australia we don’t take advantage of our land and establish rural technology centres near small country towns where land is cheap and it is possible to get the infrastructure established.

I’d love to live in a country town but there really aren’t any jobs out there for someone like me. I’ve got lots of ideas how something like this could work for those people who are dedicated to their technology career and for the companies that pay their wages.

The technology centres would be sufficiently remote that it would almost be like living an ex-pat life-style, except because most people would be from Australia it would be easy to establish communities for families to thrive.

Longhorn in 2006

Paul Thurrott has published “The Road to Windows Longhorn 2005”. In the piece he sets out a timeline which lists the RTM date of Longhorn as May 24, 2006. While that seems a fair way down the track it isn’t really, especially if you are a developer who will be expected to be familiar with the new platform features so that you can take advantage of them in your application.

This year is going to be a busy year for .NET developers with a impending release of Visual Studio and SQL Server 2005. I feel that most people will be completely hit of a six when they start using 2005 (if they haven’t used the BETA and CTP releases already) and by the time they recover they are going to get hit in the snoz by new Longhorn API’s which I am just dying to be able to use in production applications.

What is unclear to me at this point is what the tooling story around Longhorn is going to be. It seems like it would be too early for Orcas (the version of Visual Studio after Visual Studio 2005), so are we going to see some kind of an add-in for VS2005. The Avalon CTP (part of the presentation stack for Longhorn) included a number of project templates but nothing by way of designer support.

This wasn’t a huge burden since XAML’s declaritive XML syntax is pretty easy to get the hang of. I’m wondering whether the decision to bring Avalon to XP is a very clever move to get developers used to the platform before it ships so that by the time users get to it they are ready to deploy and are wanting to take advantage of extended features like pop-up-toast.

Its going to be an interesting 18–months in .NET land.