December 02, 2003
Longhorn piracy 'coup'?
The BBC is reporting that "pirated versions of Microsoft's next generation computer operating system are on sale in Malaysia, more than a year before the official release date," and quotes "software industry sources" as saying "it was the piracy coup of the decade."
Er, which decade are they living in?
It's clear from the rest of the article that what the pirates are selling are the PDC bits. These are so widely available that getting hold of them is hardly a 'coup.' And anyone who has used the PDC version of Longhorn knows that huge amounts of it just aren't there, and the bits that are run like a three-legged dog. After all, it's a developer preview, intended to get the key technologies in front of programmers. It's not, at this stage, a usable operating system.
So having copies available for $2 is hardly a big deal. People will buy it, no doubt: developers will buy it to play with and users will buy it because they don't know that they're better off with (an equally pirated copy of) XP at this stage. But this won't cut into the eventual Longhorn revenue stream because the pirated PDC version simply isn't good enough to compete with the eventual RTM.
The big deal, of course, comes when they start pirating the release candidates and RTM versions...
October 31, 2003
Wallent slays Win32 UI; not many dead
Michael Wallent in this morning's Longhorn UI panel: "We want to make existing applications look like DOS applications when they run on Longhorn."
His point was actually that Longhorn applications will exhibit not just different visual style but different behaviour. It is not a matter of applying Avalon chrome to an existing application. The actual interaction must change to fit the Longhorn Way. That means WinFS integration, shell visualisations and so on.
This emphasises the need for developers to ensure that their core application functionality -- what we do -- to be kept separate from the presentation layer -- how we deliver that to the user. Expect to ship a design upgrade in the Longhorn timeframe, and expect it to involve a major if not complete redesign of your existing presentation layer. You don't want to be having to unpick your presentation and functionality in that same effort.
The advice is to track the Longhorn user experience as the builds evolve. They hope to issue these on the Win95 model -- regular builds available to developers -- so that we can develop our new presentation layers during the Longhorn prerelease cycle, and be ready to RTM at the same time as Longhorn.
Another theme of the PDC
The phrase I'm hearing again and again from Microsoft staffers is, "We want to hear your scenarios." You get the impression that having got this far with the technology, they're almost frightened that it won't meet third-party developer needs.
I guess this is why they're previewing the technology so early in the product cycle and so widely. The foundations are there, now they need to know which direction to take it to get developer buy-in. One of the Aero guys remarked that "the hardware manufacturers love it already," but if they want to get the user base to upgrade then they need the software manufacturers to fall in love with it too, and they're not sure they can figure out what's needed to do that from focus groups and privileged private betas alone.
What a change from the Hailstorm PDC.
October 30, 2003
Relections on BoF sessions
The "Birds of a Feather" sessions were a good idea and I hope they continue at future Microsoft conferences, but there were a few things that needed fixing:
1. I lost count of the number of times the organiser said, "Well, I haven't prepared anything, so everyone just leap in," followed by dead silence. Organisers should have some sort of ideas for interesting topics -- presumably that's why they proposed the session. Sure, fluidity and openness are the raison d'etre of these sessions, but there should something to break the ice.
2. The rooms were awful. Way too big, and in at least one of them the air-conditioning was deafening. The physical layout was all wrong too. The folks at the COM Interop BoF had the right idea, sitting at the back of the room: this eliminated the stage/audience distinction and forced people to move chairs around, which meant they ended up in a more natural format.
3. Most moderators didn't know how to lead open discussions. This meant the louder voices drowned out the quieter ones. Werner Vogels at the weblogging BoF was the only person I saw trying to make sure that everyone got a fair crack of the whip.
Whining aside, the BoFs were a great chance to meet up and share ideas, and I hope we'll see a wider variety, perhaps of smaller sessions, at future conferences.
October 28, 2003
Don Box on Indigo
For those wondering whether to go to the repeat session, Don Box's Indigo overview is long on passion and philosophy, but very thin on solid technical detail. It's great if you want to understand the whys and wherefores, and of course it's a lot of fun, but don't come out of it expecting to be able to get started with the code.
And now the tea
My first reaction to Avalon, on reading about it last night in the conference magazine was, "Is that it?" It looked like little more than an extensible, XML-based format for bad old resource files. Today's demos and talks, of course, told a very different story.
Avalon is a unified presentation layer for traditional user interface (controls and forms), documents (such as HTML or PowerPoint) and "media" (images, animation and video). You can define Avalon applications either declaratively using XAML (Extensible Application Markup Language) or procedurally in the same way as Windows Forms. The declarative style supports inline code or code-behind a la ASP.NET.
(In fact a good way to envisage XAML is "ASP.NET for Windows." A XAML document plays the same role as a Web form, defining the page content and structure. The codebehind defines the application logic and event handling.)
Properties can be very rich. For example you can declare a property to be an "animation collection" which means Avalon will vary the property over time. Rob Relyea showed a logo fading in during startup by "animating" the opacity. Or a background colour property turns out to be shorthand for a brush, and you can make it a gradient or pattern brush just by breaking out the property declaration.
It is all vector-based, so rotation and zooming are extremely easy -- just set a transform property on an individual element or a container.
Documents -- whether fixed-format a la Acrobat or flowed a la HTML -- are first-class objects in Avalon. Paging and reflow are natively supported.
Avalon also offers "authoring" or design support. No more writing code for grab handles, drag-and-drop rotation, etc. You just put the objects on a design surface and specify which operations are allowed (move, resize, rotate) and the framework does it for you.
Media support looks impressive. The demo showed video being faded out, rotated and run in the background while a UI ran over the top. A silly novelty, but technically impressive. They're being a bit cagey about the level of hardware required to make this stuff run as smoothly as the demos though.
There is a nice visual styling feature. Rob Relyea demonstrated how to completely change the appearance of a set of radio buttons while retaining their behaviour. More mundanely, you can apply named styles to multiple objects a la CSS.
If anything I worry that Avalon makes it too easy to do your own wacky formatting and layout. Expect an outbreak of self-consciously clever applications full of looked-cool-until-you-had-to-look-at-it-for-half-an-hour colour schemes, distracting animations and bizarre redesigns of the common controls. (Good grief, it could be madder than the old VB1 days.) That said, the diversity of Web site designs may have trained users to no longer expect a unified look and feel, and I guess we'll have to rely on natural selection to take care of the worst excesses.
I'll try to organise my thoughts on Avalon a bit more as the week goes by (and when the wireless LAN isn't falling over... and I'm not running out of power... aargh). In the meantime, it is looking to deliver most of what appeared in the tealeaves and more besides.
September 26, 2003
The dark horse of the PDC
Wesner Moise: "Very little has been said about Avalon. Attendees have even thought of skipping the sessions of Avalon. Aghast."
I don't have Wesner's inside knowledge -- all I know comes from reading the tealeaves -- but in the last few days Avalon has really started shaping up to be the dark horse of this year's PDC. Okay, we have to pick and choose our priorities, but even if Indigo, WinFS and Yukon are more directly relevant to you, you should at least consider going to one of the Avalon overview sessions.
September 23, 2003
Primates for the people
A whole lot of new Birds of a Feather sessions have been approved, but disappointingly Miguel de Icaza's "Mono: A Status Update" is not amongst them. I'm sure a lot of developers would be very interested to hear about the progress of the .NET on Linux effort, and if Microsoft wants to promote .NET as a standard rather than a proprietary platform, they should certainly be giving publicity to rival implementations just as they give publicity to rival .NET languages. De Icaza is highly respected in the .NET community and a great ambassador for .NET in the Linux world. Let's hope the Mono BoF will be approved soon.
September 22, 2003
One thing we won't find out at the PDC
Why the codename "Avalon"? Is it after the mythical island where King Arthur is said to lie sleeping? Or is someone at Microsoft just a closet Roxy Music fan? I suppose the clue will be whether the successor is called "Valhalla" or "Siren."
The tealeaves of Avalon
Avalon is usually described as the new graphics subsystem for Longhorn, as if it were the successor to GDI and GDI+, but it's clearly a lot more than that. Going by the PDC session list, it's more like a successor to the window manager, common control library and COM automation put together with features from UI frameworks like MFC and Windows Forms thrown in to boot.
So what can we read from the tealeaves-- I mean, session abstracts?
- Avalon (CLI200) is built around a Desktop Composition Engine which means each application thinks it has the desktop drawing surface to itself. I remember one preview of the Nashville shell being described as "Microsoft Window" because documents were hosted directly inside the Explorer shell. I wonder if Avalon will become known as "Microsoft No Windows."
- The key underlying graphics abstraction is Direct3D (CLI340). However, Direct3D is way too complex for most desktop applications, not to mention a pain to migrate existing 2D code, so the API is said to resemble GDI and GDI+ rather than Direct3D. Using the Direct3D engine does mean we get a scaleable desktop, as if we were working on a vector rather than raster surface. Display PostScript, anyone?
- Avalon provides a command framework (CLI351) and "integrated document services" (CLI305). Is this bringing document/view or MVC into the core Windows platform? Or is "integrated document services" simply clunky old data binding (CLI306) given a buzzword makeover?
- There's a UI automation subsystem (CLI307). This will be a gift to help authors, testers and administrators (ARC334) as well as to CBT providers. The automation subsystem will be accessible from a (ahem) "Next Generation" command line (ARC334).
- Speech and pen input are supported for both data and commands (CLI351).
- Design-time support is built into the framework (CLI302). In theory this is true in Windows Forms as well, as the designers are part of the framework not part of the IDE, though in practice the framework doesn't provide any useful host for the designers. What is interesting is that Microsoft talk about building Avalon applications using "markup" (CLI300). I'm increasingly suspicious about trying to define behaviour using declarative markup, so it will be interesting to see how Avalon draws the boundary between markup and code.
- Avalon is component-oriented (CLI301) and supports "deep" integration with the Windows shell (CLI303). Previously it's been hinted that Avalon's component orientation extends to visual and behavioural inheritance, with the implication that Avalon components will be able to inherit from shell components such as Explorer. Which, if true, would be nice -- I certainly find this a lot more tantalising than the prospect of bendy windows.
How all this fits together is of course another matter, and something I'm looking forward to finding out...