Microsoft’s XAML team moved into the Windows division ahead of Windows 8

By Tom Warren, on 23rd Jun 11 11:56 pm with 19 Comments

Microsoft’s XAML technologies team is moving directly into the Windows division.

The software giant announced the change in an internal memo to employees earlier this week. Senior vice president of the Developer Division at Microsoft, S. Somasegar, announced the changes to the entire developer division at Microsoft. Somasegar praised the Client and Mobile teams at Microsoft and announced the following adjustments:

  • The team working on XAML technologies for Windows will move to Windows.
  • The team working on XAML technologies for Windows Phone, Xbox and browser plugin will move to Windows Phone.
  • The Client and Mobile tools teams, including Windows Phone tools and XAML tools, will stay in DevDiv.

“These changes are all effective immediately,” reads an internal memo obtained by WinRumors. “There is a lot of very exciting and critical work underway as part of our next wave of platform releases and I am very eagerly looking forward to seeing the team’s work in the hands of our developers and customers.” In a follow-up memo, Julie Larson-Green, corporate vice president of program management for the Windows Experience at Microsoft, explained the XAML team transfer in more detail. “While the team has been working side-by-side with the Windows team for the entire project, this step brings them into our team formally,” said Larson-Green. ”The team will continue their work on Windows 8 as planned and will join our Developer Experience (DEVX) team.”

Microsoft’s DevX team are currently responsible for the implementation of AppX inside Windows 8. It is believed that the software giant is preparing an application model codenamed “Jupiter”. The model would allow developers to create native applications that can be easily deployed using AppX packaging. The container method is similar to Microsoft’s Silverlight-based application package (XAP). Microsoft’s confirmation that the XAML team are working closely on Windows 8 is an interesting one. XAML is the markup language used in writing Silverlight and WPF applications. Microsoft revealed its new Start Screen user interface using HTML5 and JavaScript earlier this month. The demonstration has created an uncertainty amongst Microsoft’s developer community. A number of agitated developers have made their thoughts and feelings clear in Microsoft’s own developer forums. Developers want to know how they will be able to target the new Windows 8 UI with native and Silverlight based applications. The software giant is refusing to speak any further about Windows 8 but promises to reveal all at the BUILD Windows developer conference in September. Judging by the leaked memo, developers can feel a little more comfortable knowing that the XAML team is now part of Windows and ultimately Windows 8.

  • http://www.facebook.com/people/Jonathan-Marston/542557737 Jonathan Marston
  • http://twitter.com/nzben Ben Gracewood

    Hang about. “The team working on XAML technologies for .. XBox”  !
    THAT is news.

    • http://www.facebook.com/profile.php?id=100001039271971 Martyn Metalous

      Apps are coming to the XBOX, old news just new to you ;)

  • GP007

    I don’t understand why the XAML teams were on their own till now when this sort of setup makes more sense to me.  Well, less devisions and more working together sounds good to me.

  • http://twitter.com/MichielPapp Michiel Papp

    This is gonne be excellent. Better developer support. Maybe the .net framework can be builtin in win 8. Maybe we can finally get the promissed windows longhorn development. WPF was at first a part of the longhorn development stratigy. Really enjoying this :)

    • Bob
    • Tom

      Indeed.  The Longhorn dream was delayed, but it’s finally coming true.

      All sorts of stuff that got derailed by the Vista fiasco are now making a comeback.  Multi-monitor taskbars!

    • Guest

      It may not be WPF but one of those DirectUI or something. But what I do know is that Ahead-Of-Time-Compilation for .Net Framework will allow for example C# written apps to be compiled to native code so MS will be ahead of Chrome here. Either way the Longhorn vision is coming true. Protogon File system extension, markup language for UI, .Net languages for Windows development.

    • Tom

      XAML is integral to WPF.  It wouldn’t just be DirectWrite.  However, it doesn’t sound like they’re moving the whole .NET Framework.

      (There is, however, a relatively clean way to split up .NET.  Everything below IL could go into Windows, and everything above IL stays with DevDiv.  That’s analogous to the XAML situation, where the core of XAML goes into Windows, but all the developer tools stay with DevDiv.)

    • http://www.facebook.com/people/Jonathan-Marston/542557737 Jonathan Marston

      What they’re doing is making a whole new C++ Windows API called the Windows Runtime. It will basically replace Win32 with a modern C++ API including a new UI framework called DirectUI that’s heavily based on WPF/Silverlight, but more light-weight and performant.

      What’s really exciting is how they’re exposing all this to .NET (and presumably HTML5/JavaScript). There’s a new version of COM that will expose every API in the Windows Runtime directly to .NET. It’s not gonna be a traditional wrapper like we’re used to, .NET will be directly calling the native API.

      This means that as new APIs are added to WinRT, .NET developers will instantly have access, rather than waiting for Microsoft to create a wrapper, or doing a bunch of PInvokes.

      Very exciting times for Windows

    • Tom

      Thanks for the clarification.  Looks like the beta hackers have turned up some truly revolutionary stuff since the last time I read about this stuff.  This changes everything.

      WPF has always had problems with performance.  Even a moderately-complex UI can bog down quite quickly, because there are just too many gotchas to be aware of.  You can get WPF apps to perform well, but only after doing a bunch of profiling and reading up on workarounds.

      If DirectUI can perform well, then I’d be willing to give up a *lot* of features from WPF.  The reduced headaches would be worth it.

      If WPF was v1, and Silverlight was v2, then maybe Microsoft can return to the tradition of getting things right for v3.

    • Guest

      Managed code has traditionally been slow performing when used for the UI while something like an app that uses the native Haiku UI but with a Python, Lua or Perl backend is still actually relatively fast. As Windows Phone demonstrates, Silverlight with XAML can deliver fast performing code for the UI.

    • Tom

      Thanks for the clarification.  Looks like the beta hackers have turned up some truly revolutionary stuff since the last time I read about this stuff.  This changes everything.

      WPF has always had problems with performance.  Even a moderately-complex UI can bog down quite quickly, because there are just too many gotchas to be aware of.  You can get WPF apps to perform well, but only after doing a bunch of profiling and reading up on workarounds.

      If DirectUI can perform well, then I’d be willing to give up a *lot* of features from WPF.  The reduced headaches would be worth it.

      If WPF was v1, and Silverlight was v2, then maybe Microsoft can return to the tradition of getting things right for v3.

    • Test1ngi23

      Good idea on how to split up the .NET teams. CIL would make for a nice division line.

    • Test1ngi23

      Good idea on how to split up the .NET teams. CIL would make for a nice division line.

  • Bob
  • Renzo

    XAML is what HTML should have been.

    *can of worms flies open*
    :)

    • Test1ngi23

      LOL, sure buddy…

    • Anonymous

      HTML was designed for document oriented interfaces, XAML for application oriented interfaces  (as was XUL, though XAML is more powerful). Why people want to use HTML to build apps is beyond me.
      My biggest problem with XAML versus HTML/XUL is stylistically its very ugly, even if it logically makes sense.