Ben Galbraith's Blog

Avalon Everywhere? Cross-platform Microsoft?

Another interesting announcement here at PDC is that Microsoft is creating a subset of their cool, fancy pants UI layer (formerly code-named Avalon, now WPF) on other platforms, including the Mac! In fact, one of the demos involved showing vector graphics rendered in Safari using a Microsoft plug-in.

This subset, called WPF/E, will be powered by XAML (their XML dialect for representing the UI) and JavaScript. Sound familiar? Yes, that's right -- Microsoft also announced a Dashboard clone for Windows Vista. Interesting...

Microsoft will never port .NET to other major operating systems, but to have a subset of Avalon available on other platforms is a bit of a curveball. In fact, in light of Firefox and Safari's upcoming support of SVG and Canvas (and in the future, 3D functionality), this move makes sense; Microsoft wants to provide their own proprietary solution to cut off this new cross-platform initiative.

Also, Microsoft's Ajax framework, Atlas, will target WPF/E. The WPF/E subset of Avalon will include all of the Avalon features (vector graphics, animations, etc.) less 3D, some of their XPS features (XPS == Microsoft PDF clone), and hardware acceleration.

In a WPF/E session, someone asked if Microsoft's WPF/E plug-in will be available in Firefox; the speaker dodged the question ("We hope such support will emerge...").

My first reaction to WPF/E is frankly disappointment that they wouldn't just embrace SVG, though what I've seen of 2D XAML makes it look a while lot like SVG with different attribute names and various other differences. I wonder if XSLT will do the trick there...

Lack of many of the Avalon features in WPF/E, notably hardware acceleration, really makes it seem that the strategy is to make apps work on other platforms, but make them work poorly compared to Windows -- motivating users to switch to a Windows platform.

Comments

• Color me skeptical, but this sounds like a page out of the old Microsoft playbook.

  Create the illusion of portability by supporting a subset of a new technology on other platforms. On the other platform, make that subset hard to work with, perform fairly poorly for anything other than a toy app, and then stop upgrading/supporting it (after the "competition" has lost it's momentum). Well it makes for a good conspiracy theory if you go for such things. Your mileage may vary.

  About a decade ago, vendors were making great strides in creating cross platform toolkits. Microsoft had Visual C++ and the MFC framework for building apps (think AWT). Thay announced MFC for Mac, but beyond demos it was somewhat broken and they dropped it sometime later. Surprise, surprise? Now the other companies and products have their own culpability in this saga, but Microsoft had a nice run with this tactic, intentional or not.

  Of course there are other examples of this more recently if you think real hard.

  By the way, this one probably ain't pointed at Sun/Java or Firefox/Safari. It seems pointed at Adobe/Macromedia. But it doesn't matter....

  Posted by: ericraymond on September 14, 2005 at 12:00 AM

• You have stated that "Microsoft will never port .NET to other major operating systems", I beg to differ.

  They have ported the "Common Language Infrastructure" which minus all the marketing misinformation is the core of .net to FreeBSD and OSX

  Check it out for yourself. Where do you think they are going with this?

  Posted by: chekristo on September 14, 2005 at 04:59 AM

• @chekristo:
  Check the publication date of this release (top of the page): 11/5/2002;
  Googling for "MS Rotor" (Rotor is the name of this implementation) also brings up this page.
  Rotor is a research project where MS got a .NET VM running on BSD (MacOS X only works because it has a BSD kernel).
  

  Posted by: murphee on September 14, 2005 at 07:18 AM

• Today's Simile: Microsoft is Pepsi. They're not original, but they copy the original fairly well.

  Posted by: phlogistic on September 14, 2005 at 10:58 AM

• Ben, your argument mischaracterizes many issues. Permit me to clarify some of them:
  You say WPF or WPF/E were intended to counter SVG. Windows Presentation Foundation is a platform for building rich client applications with immersive UI. SVG, on the other hand, is a language for describing two-dimensional graphics in XML [1]. Vector graphics are but one of the many features of WPF. Other WPF features like media (audio, video), data binding, application model, layouts, uniform programming model for building installed and web browser applications, etc. have no parallel in SVG. Applications like Max [2] and Sparkle [3] are built using WPF. For WPF to be using SVG in place of XAML - as you suggest - just doesn't make sense. No existing declarative programming language had these capabilites, so a new one had to be conceived.

  You say some speaker dodged the question about supporting Firefox. Web Browser Applications in WPF are supported by Internet Explorer 6.0 and above. They require a Web Browser Control (WebOC) and should function even today in browsers that use the WebOC (I think Netscape does, don't know about others). Other browsers can choose to support this model and may indeed choose to do so once Windows Presentation Foundation is released. I don't expect Microsoft will comment on other companies' efforts or plans.

  You somehow ascribe an ulterior motive in not supporting hardware acceleration on other platforms. The reality is quite less controverial, even boring. Hardware acceleration on Windows Vista (or XP etc.) is realized by the leveraging the graphics card's GPU. Since WPF/E is designed to work on multiple platforms (other OSes, CPU architectures, mobile phones and PDAs), you cannot extend this paradigm. My cellphone and I am willing to bet yours too, just doesn't have this in place. So MS has two choices: ignore us, or create a platform that works around this hurdle. Guess what they chose?

  [1] SVG 1.1 Specification
  [2] Max is a sample photo organization and sharing app built using WPF
  [3] Sparkle is an IDE targetted at designers for building WPF apps and is itself built using WPF
  

  Posted by: nerddawg on September 14, 2005 at 09:23 PM

• > You somehow ascribe an ulterior motive in not supporting hardware acceleration > on other platforms...... My cellphone and I am willing to bet yours too, just >doesn't have this in place. So MS has two choices: ignore us, or create a platform > that works around this hurdle. Guess what they chose?

  Hmmm......that of course would be true, if there wasn't OGL and OGL ES. So, they could actually choose to make it accelerated on all platforms that suport those specifications. There aren't many mobile phones supporting OGL ES HW acceleration, but there are some. And will be much more in the furure (when Vista and all of those technologies ships). Btw, I somehow don't think that wave of technology will somehow magically work on my or yours current cell phone. In short, I think that author is right, especially given MS track record. There IS an ulterior motive.

  Speaking of which, XAML-GUI and SVG do look strikingly similar. One could argue all day about MS actual motives, however, looking at those two, I cannot to remember old MS mantra "embrace, extend, extinguish"

  Posted by: selendic1 on September 15, 2005 at 04:58 AM

• nerddawg: Regardless of the marketing speak, XAML is a vector graphics markup language, and SVG is a vector graphics markup language. XAML can be used to create non-interactive vector graphics; SVG can be used to create non-interactive vector graphics. XAML can be used to create GUIs; SVG can be used to create GUIs. They are not clones of each other, of course, but when you consider XAML without 3D graphics, they are more similiar than distinct.

  WPF/E + JavaScript delivers functionality a whole lot like SVG + JavaScript or even Canvas + JavaScript, which is what I'm talking about by the way, not full-on XAML + CLR vs. SVG + JavaScript, which would be a stupid comparison to make.

  RE: dodging the question. WPF/E has already been (experimentally?) ported to Safari on the Mac, which was demonstrated. The audience member asked if Firefox would be supported. The speaker hummed and hawed and finally said, "Err, we'd like to see a third-party support Linux." No mention of, say, Firefox on Windows being supported, and the speaker answered the question very carefully and incompletely. What word besides "dodge" would you prefer to describe this?

  RE: acceleration. Dude, what planet have you been living on? D3D hardware acceleration is, if not a copy of Quartz Extreme, at least heavily inspired by it -- or to be generous, they are both aspire to achieve the same end. Do you think, maybe, the Microsofties could map WPF/E on the Mac to Quartz? Do you think, maybe, the Microsofties could map WPF/E on Linux to Cairo? What I'm suggesting is that Microsoft, with its enormous resources, probably won't want to do this because at the end of the day, as *everyone* knows, their strategy is to sell copies of Windows. Period.

  By the way, this does not make them evil (to me). It makes them a business with a plan to make money. I have no problem with that. But, come on, let's not be naive and suggest that Microsoft would love to help the community altruistically, if only other platforms had the technology sufficient for Microsoft to enable Microsoft do make their wonderful Avalon acceleration available.

  As far as hardware accelerated cellphones, dude, you obviously aren't familiar with the latest models, whose hardware acceleration is actually rather impressive. Your "my cellphone doesn't have h/w acceleration" is a fairly sad argument, given that most of today's PCs aren't capable of doing the full H/W acceleration that Avalon wants, either.

  Posted by: javaben on September 15, 2005 at 07:29 AM

• 
  I really don't want to admit this, but Microsoft is putting out some really nice stuff with WPF. Check out this Sparkle demo, which is a UI design application that uses the XAML 2D/3D scalable vector drawing capabilities to create a 3D GPU accelerated UI ready for integration with back end C# code. Very slick, very nice.

  For rich desktop corporate development, this will probably have as much impact as the VB2/VB3 days. Plus, it can all be deployed through the web using their WebStart clone.

  It doesn't look like Java will have an answer for several years. If there were Java UI designs tools that allowed for easy manipulation of a GUI's look and feel via Synth, and Swing natively rendered SVG while seemlessly integrating with Java3D/JOGL, as well as the JVM's offering GPU acceleration by default, then we may have something....
  

  Posted by: cupahjoe on September 16, 2005 at 11:32 AM

• XAML is an XML markup allowing declarative access to .net objects. It's more like a client-side version of JSP/JSTL than SVG. Although you can use it to draw on the screen, it creates vector drawings by accessing .net's equivalent of the 2D API. It really isn't an equivalent to SVG (or XUL as other authors have tried to point out). It's much more like JSP, allowing access to already existing objects from a markup language.

  This brings up another mistake in the article... XAML is .net code compiling down to IL (.net bytecode). How could microsoft possibly get it working on the Mac without having a Mac version of the .net runtime?!?

  Sure, Avalon isn't anything amazingly original, but it is slick, and we don't have anything better.

  Posted by: bryanyoung on September 27, 2005 at 06:50 AM

• 
  bryanyoung: Obviously, XAML does things that SVG doesn't. The issue is whether or not Microsoft could have used the SVG grammar to express 2D vector operations, or at least offered some support for it within the XAML grammar (XML namespaces, anyone?).

  
  By the way, the markup used to define an image has little to do with the underlying API used to render the image. Maybe that's a little clue on how Microsoft created a XAML-rendering plug-in for the Mac. ;-) That's not a "mistake" in the blog, my friend, it's reporting on a demo that Microsoft gave at PDC -- in front of thousands of people.
  

  Posted by: javaben on September 27, 2005 at 07:00 AM

• XAML is not an XML format for expressing vector based drawings. It's a way of expressing .net il. Every entity represents an object. Every attribute represents a property. Every xml namespace maps to a .net namespace. That fact that you can draw with it is just a neat side effect of having access to .net 2D drawing tools. Adding xml calls that don't follow the conventions above would undermine that contract and make xaml a confusing mix of keywords and object references.

  The purpose of XAML isn't to abstract implementation away from the programmer, but to expose it in a more structured form (so GUI editors can generate XML rather than C# code).

  BTW, the mistake I was referring to wasn't that .net couldn't run on Mac (I've run mono's implementation on mine). I was pointing out that the claim that "Microsoft will never port .NET to other major operating systems" is not really true. No part of Avalon would be able to run on the mac without the .net run-time.

  Posted by: bryanyoung on September 27, 2005 at 12:02 PM

• 
  bryanyoung: Hey, this is fun. Check out:

  
  http://www.svgopen.org/2004/paperAbstracts/TargetingSVGandXAML.html

  
  Describes how as I've described "The XAML elements for vector graphics and animation are closely modelled after SVG. Furthermore, SVG deployment scenarios are similar to XAML: SVG can be used as Browser content, or as user interface to a Web application when accompanied by event-driven procedural code (script)."

  
  RE: porting .NET to other operating systems. .NET is a strategy to lock developers into Windows, just as Avalon is a strategy to add value to Windows-specific clients. Microsoft has no model for making money on .NET on other platforms, though some argue they should sell a Unix .NET license for a ton of money to make up for lost revenue on the Windows licenses, but the Microsoft managers I've talked to aren't excited about that (for obvious reasons).

  
  We could get into an long and interesting debate about the semantics of porting .NET to the Mac, but frankly, unless its available to developers, its not of interest to me. For example, it's interesting that iTunes on Windows uses OpenGL and appears to be a partial port of Cocoa to Windows. That's very interesting. But, I can't use the alleged Cocoa/Windows library to develop applications, so its of limited usefulness to me.

  
  Time will tell if the demo'd Safari plug-in is even written in .NET (which I doubt) and whether or not it will ever ship.

  
  Best, Ben
  

  Posted by: javaben on September 27, 2005 at 12:12 PM

• True, the drawing portions of XAML superficially represent SVG, but that doesn't mean they could have adopted/integrated SVG without compromising the base philosophies of XAML: that there is a direct correlation between the xml structure and the underlying object model.

  I don't disagree that all the basic pieces are there to create a gui drawing framework based on SVG - reusable shapes, events, animation, styles, etc. But I don't believe it solves the problem Microsoft was looking at: they needed a way to persist GUI layout information so it could be machine generated, machine parsed and still reasonably readable. While SVG could (with help from other technologies such as HTML, Javascript, etc) be used to create a UI, the results wouldn't have been any more structured than the generated C# code found in Winforms code. It would still be vulnerable to mis-parsing hand-written changes much like Java IDEs have today.

  WinForms, Swing and other hand written UI frameworks can be generated by a visual designer, but with serious drawbacks. While these frameworks were a major step forward in flexibility over VB; Visual Basic's designer was still more developer friendly for simple a UI in 1993 than Winforms and Swing are today. XAML's provides a place where the visual designer and hand-tweaked code can exist together. While an SVG solution would be available from java, javascript, ruby, etc, it wouldn't offer Microsoft an advantages over Winforms (other than the flexibility of using vector drawing).

  I disagree that .NET is a strategy to lock developers to Windows. I think Microsoft is fine with .NET running on other operating systems as long as it always runs better on Windows. They know Avalon will never take off on the web unless it runs in some limited capacity on other platforms. All they need to port is the VM, the core libraries and the Avalon libraries. They can skip data access, winfs, winfx (other than avalon), monad and any libraries that could run in the sandbox.

  As far as the Safari plug-in being written in .net, I'm sure the plugin itself is written in C (Safari would be able to communicate with .net directly). But there's no doubt that the XAML running in the plugin is compiling to IL and running on a .net VM. If not, then it's not really XAML.

  Posted by: bryanyoung on September 27, 2005 at 02:11 PM

• bryanyoung: Okay, we agree to disagree on the benefit of incorporating an existing 2D vector graphics standard in the set of WPF that does 2D vector drawing. I'm not interesting in debating the merits of XAML as a way to express GUIs and bind them to the app -- but I will say that I've long advocated that Sun standardize on a XUL format.

  RE: SVG as a GUI serialization format. Huh? I don't see how that would work. Listen, I'm not saying XAML is bad, or that XAML can somehow be replaced with SVG. I'm saying geez, wouldn't it have been easier if WPF provided native support for SVG?

  RE: .NET lock-in. Having .NET cross-platform would definitely change the game, but unfortunately, if its crippled, that defeats the point. If I can get what I need out of it, I don't need to buy Windows, hence, Microsoft loses money. If I don't get what I need out of it, I have to buy Windows, hence, the "cross-platform" bit is meaningless. Nice try, though.

  RE: .NET ported to the Mac. That's interesting! I confess I'm really skeptical that subsetting XAML to work with a native implementation is actually harder to do than implementing and supporting the CLR on the Mac on both x86 and PowerPC architectures but I'm more often wrong than right!

  Ben

  Posted by: javaben on September 27, 2005 at 06:49 PM

This work is licensed under a Creative Commons License.