Will Microsoft's developers make the WinRT platform leap?

Will Microsoft's developers make the WinRT platform leap?

Summary: In a new report, Forrester Research takes stock of the adoption issues surrounding Microsoft's combined Windows 8, Windows RT and Azure developer platform.

SHARE:

It's been months (almost 11) since Microsoft introduced its new developer platform, anchored by the WinRT application programming interfaces, at the Build conference in September 2011.

That updated dev platform looked like this (insert your favorite version of this slide here):

win8platformmsdiagram

Microsoft may be gearing up to share more about this platform at its upcoming Build 2012 conference at the end of October, but in the interim, the researchers at Forrester have delivered a state-of-the-state report on Microsoft's new dev platforms, generated by interviews with enterprise and third-party software developers.

At the crux of the Forrester report published August 24 (20 pages, $499 for non-clients) -- "The Future Of Microsoft .NET: New Options, New Choices, New Risks" -- is the key question: Can Microsoft make another big platform leap?

Forrester's answer:

"Yes, but the odds are long. With Windows 8, Windows RT, .NET Framework 4.5, and Windows Azure, Microsoft has reached its latest existential moment. So much of Microsoft’s future growth and profitability is tied to the success of this platform, and the obstacles to success with Windows 8 and WinRT, and to some degree Windows Azure, are great. This is a shift that Microsoft must get right or face serious constraints on its growth in future years."

Forrester's report includes a diagram (included below) which highlights some of the many changes to which Microsoft's core developer base is having to adjust.

forresterdotnetapis

Interestingly, Forrester puts the WinRT application programming interfaces (APIs) in the "speculative" category, along with OData and PLINQ. Not so surprisingly, Silverlight, Windows Presentation Foundation (WPF) and WinForms are all in the "on their way out" category.

Given I myself just interviewed a few business-app developers grappling with Windows 8 and WinRT, I found the section of the report -- based on 14 "vendor and user company interviews" that supplement the "dozens of client conversations" on Microsoft's platform that Forrester has every month -- to include other noteworthy insights.

Forrester's researchers said "established" independent software vendors (ISVs) are running about two years behind Microsoft in terms of adopting new frameworks and ideas. Many of these ISVs tend to use as little of Microsoft's framework as possible in order to hedge against regular changes Microsoft makes to its core set of APIs (see Silverlight and WPF). There are also some questions in the minds of those Forrester surveyed about Microsoft's long-term commitment to its own C# language, given the Windows Developer Division's emphasis on HTML, CSS, JavaScript and C++.

"Many .NET ISVs insist on clients not tied to .NET," the Forrester report noted. "The .NET ISVs we spoke with were highly committed to .NET on the server, including Azure. But they were much less loyal to any individual client technology, even the many provided by Microsoft."

At the same time, a number of ISVs have been investing in either native or hybrid HTML5 mobile clients, Forrester said. "WinRT must compete for a place in the ISV’s client pantheon and will earn a place only if Windows 8 is widely adopted," Forrester added.

Microsoft's Developer Division will be holding a virtual launch of Visual Studio 2012, which was released to manufacturing in late July, on September 12. According to the agenda, Microsoft execs will be providing more details on building Windows 8/Metro/modern apps -- which the Developer Division officials seem to prefer to call "Windows Store" apps -- with Visual Studio 2012. Also on the launch day agenda are .Net 4.5, Workflow Foundation 4.5, Windows Communication Foundation 4.5, Entity Framework 5, and Visual C++ 2012. Who knows: Maybe there will be an update or even code for those awaiting the promised software development kit for Windows Phone 8, too.

 

Topics: Windows, Cloud, Enterprise Software, Microsoft, Software Development

About

Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

32 comments
Log in or register to join the discussion
  • WinRT is more than for Modern apps and Windows RT

    One clarification:

    There are WinRT APIs usable on the desktop as well as in Modern-style apps. They *must* be used for Modern-style apps but they have equivalents available for native desktop applications as well.

    It would appear that the WinRT APIs might be thought of as a broadening of the .NET Portable Class Libraries beyond the .NET Framework. It is interesting to me that they have a COM lineage and can work well at the binary level.

    I haven't done the work to determine whether this is a powerful API selection for encouragement of portable code that can be targeted to multiple platforms and stacks. I am intrigued enough to check it out, though. (Not part of the developer community you are speaking of, though.)
    orcmid
    • Huh?

      Where is your evidence that "there are WinRT APIs usable on the desktop" or that there are "equivalents available for native desktop applications"? Point me to documentation from Microsoft that says this. Can I write desktop XAML code that generates C++/CX code like WinRT developers can? I don't think so. My understanding is that if you build an application that links in WinRT, your application will not run if launched from the desktop.
      FDanconia
      • Not supported, but possible

        It's possible to a certain degree to re-use Windows Runtime APIs in Desktop applications, even the native XAML stack works (theoretically) as some guy showed in a simple proof-of-concept Win32 application: He used C#, created a native Win32 window and loaded some XAML content (using Windows.UI.Xaml instead of WPF). Things like event handling etc. didnt work, though.

        I think it's possible as long as no such things as contracts or other Windows Runtime-specific stuff is required. Creating a normal C# application and using Windows Runtime APIs to use the webcam, for example, won't work because of security constraints.
        sevenacids
  • On the way down: client apps created in Visual Studio

    I'm having a terrible time advising on what UI platform to use, and frankly my interest is swinging towards Delphi for Windows apps that need to interact with client-side full-trust resources. Had Silverlight continued to mature, it would have been the glaringly obvious choice. But with it "on the way down," and web apps too restricted in their interoperability, we're stuck with ClickOnce and either WinForms or WPF, both of which are also "on the way down."

    What I need, and I need it soon, is to see a road map with clear signs of commitment from Microsoft for WPF and Silverlight, or even just WPF via Silverlight, so that business developers can get back to work with confidence. Without this, I'm afraid a switch to Delphi will be necessary -- we cannot expect end users to install software or .NET runtimes anymore.
    scH4MMER
    • Delphi?

      Isn't Delphi a little old now? Not that I'm trying to knock it - it was fantastic. But today, I'd be looking at Qt, not only is it cross platform, they have a prototype of it working as a Metro plugin, so you might just get cross-platform (where Metro and desktop can be considered 2 platforms) plus iPhone and Android as well as Linux and Mac GUIs. It may not be as polished as you'd like on all platforms, but what other choice do we have?!
      gbjbaanb2
  • No "rising" API for the Desktop

    Two notable things about this:

    1) I lose some respect for Forrester here for focusing on ".NET". Along with the birth of WinRT came a re-emphasis on native code. WinRT is not strictly speaking a .NET technology, although you can write WinRT apps using .NET. But Direct2D, huge in WinRT, is native, and the interesting part of WinRT (at least for some of us) is that it allows you to code to WinRT with strictly native code. So if you are doing a study on Microsoft API's, why not include the native API's as well? Where is MFC on this chart? Hey, stop laughing, MFC is still the only API (other than the raw SDK) that Microsoft has for native development.

    2) An intelligent person looking at that chart would ask, is Microsoft completely abandoning the Desktop? There are no Desktop APIs in that list that are not in the "On the way down" category. The Desktop is where Microsoft has 90% market share. So what are they doing, treating it like IE 6 and just leaving it dormant for years of forever? I realize desktop applications are old school, but the company I work for still sees growth in the desktop apps they develop. You would think it would be worthwhile for Microsoft to expend *some* resources on the Desktop to maintain their dominance. By mothballing the desktop, Microsoft is encouraging companies to abandon their desktop applications and move to mobile apps, and if companies do that, they are going to think long and hard about which platform to develop their mobile apps for, and at this point, Windows RT is going to be a lot of companies' third choice.
    FDanconia
    • MFC

      MFC is NOT an API. It is an embarrassing and outdated win32 API wrapper.
      I personally would not consider writing any serious UI using C++. Even in 1995 it was crappy library but it was sort of OK. Now it is just a waste of time. Lets say as it is. C++ for UI is dead end on windows. Using .NET extensions in C++ is also a dumb idea. Microsoft keeps changing syntax and libraries from version to version and long term such code is not viable.
      paul2011
      • C++ for the WinRT API is active

        C++ and WinRT would be the green block to the left in the diagram. C++ and MFC to Win32 would be the blue box onthe right in the diagram.

        If you want to use C# or HTML/CSS/Javascript for UI through the WinRT APIs that is fine too.

        Search for Windows Metro style apps Forums
        and you will see 6000 messages dealing with the use of C++ for user interface in the Windows RT APIs. C++ has more options on Windows 8 than in Windows 7.
        AndrewDover
      • @ paul2011

        Believe it or not, applications created on WinNT 4.0 with Win32 SDK still run fine enough with new Win7 machines though holes and bugs exist. So do MFC applications. The MFC library atleast provides some MVC overlay on the plain Win32 API data framework. Without it, the code design will be closer to writing for a DOS machine.

        From what I understand elsewhere, I think this is actually Microsoft's future path:
        #1 The path to future client applications (desktop and mobile tablet and phone) is mostly through C++ native code on Win32 or WinRT API.
        #2 It will also be well-supported through HTML5/JS code on IE client.
        #3 Managed code support with .NET C# is a neutral priority on mobile clients though this will be supported on WinRT and Win8 mobile platforms.
        #4 WinForms, WPF are secondary in support since MVC support is now crucial and Silverlight is secondary too since Rich Internet Applications are not a priority anymore. These will be dropped soon.

        I always liked the old Win32 SDK approach with its easy to use C API though they were raw. And for implementing service oriented applications, I always found WCF API as being well designed for implementing REST. Hope Microsoft remembers its old customers.
        calahan
    • The Term "Desktop"

      You're combining two (albeit confusing) different meanings of the term "Desktop".

      There are two definitions of "Desktop":
      a) A standalone computer comprising a CPU, Display, Keyboard and Mouse. These may be separate components or combined into an all-in-one or laptop system.

      b) A mouse-centric graphical user interface found in operating systems such as OSX, X-Windows and Microsoft Windows.

      With Windows 8 the Desktop UI has been deemphasized but continues to exists for legacy support, line-of-business applications, etc. The primary user experience is a full-screen user experience which provides a much better environment for applications that support a combination of mouse, touch and keyboard inputs (one could speculate that Kinect style input isn't far behind either).

      Support for Desktop PCs however is just as strong as it ever was. While there is substantial interest in the new Windows RT Tablets as an iPad alternative, Windows 8 is much more than that. It has everything Windows 7 has plus many substantial improvements.

      You are also mixing two other terms (again, even more confusing) in Windows RT and WinRT. Windows RT is an ARM based edition of Windows 8 intended for the tablet market. WinRT is the next generation of the Windows API (Win16, Win23, WinRT).

      I'll admit it is confusing. Windows RT won't run on a Desktop because it is ARM based but does include the Desktop and will only run apps built on WinRT. Windows 8 WILL run on a Desktop because it is x86 based, it also includes the Desktop and will run apps built on Win32 or WinRT. Got it? No? Yeah, I don't blame you. :)
      WarmBody
      • Bad assumption?

        I am assuming that in the context of discussions of Windows 8, everybody knows that when we talk about the "Desktop", we are talking about Desktop applications vs. Metro applications, i.e., the applications that run on the Desktop side of Windows 8. I'm not talking about a computer form factor here. This is perhaps another example of how hard it is to even talk about Windows applications right now because of the poor job Microsoft has done giving names to the different parts of Windows 8.
        FDanconia
    • Yeah I see that too

      I see the same issue with this. If you're in a company running Windows 7 and with no plans to go to (ie: most of them), there's nothing for desktop app development that isn't in decline on here. Worse then that, Microsoft doesn't seem particularly interested in that setup anymore.

      Since it's not going away anytime soon, there's a hole that they aren't filling.
      Tridus
  • Delphi? Really?

    If you commit to "C# + XAML" you cover WinRT, WPF and Silverlight. There are some subtle differences here and there, but with the languages and most of the Frameworks the same, you end up with a consistent way for your devs to think - and, it's transportable to your web apps (where C# + ASP.NET/MVC/etc is the way to go).

    It's certainly a better solution that going Objective C on that other platform.
    Flydog57
    • XAML isn't a platform

      XAML sounds great, but language isn't the concern here. Windows 8 won't be endorsed at my company for years, assuming it survives that long. We are building desktop applications now, right this moment, and all our available platforms are "on the way down." I hope Microsoft doesn't wait until Windows 8 achieves saturation before they put a desktop UI platform back "on the way up."

      Meanwhile, Delphi is addressing issues such as: multi-platform components, lightweight installs that don't require a framework, and UI platform clarity. I'm just saying, the decision makers I talk to are losing patience with Microsoft when it comes to desktop apps. Ironic, since it used to be Microsoft Windows' campaign against Google that a desktop app is better than a web app.
      scH4MMER
      • Right there with you

        I think WinRT is a great application development platform for mobile apps and possibly even for some line-of-business apps, but Microsoft is acting like it is the upgrade path for desktop apps, when many, many desktop apps (not to mention the way people are used to working with multiple applications at once) either do not fit well in WinRT or are cost-prohibitive to port. The desktop is where Microsoft has massive market share advantage, and yet they are acting like they want the desktop to go away. It is truly mind-boggling.
        FDanconia
    • Why Not?

      At this point it doesn't look like Microsoft is ever going to create the same eco-system that Apple has - Smart Phone, Tablet, Laptop, and Desktop. You can stick with Microsoft hoping they change the current dynamic, but from what I've seen of Windows 8, my confidence is shaken.
      TEAMSWITCHER
  • WPF

    Isn't XAML just a more generic name for WPF? Talking about WPF as being "on the way down" and XAML as being "on the way up" does not make any sense.
    paul2011
    • XAML and WPF

      XAML (eXtensible Application Markup Language) is technically not tied to WPF. It is a generic markup language that is used by the WPF subsystem to declare/describe some of its components (like forms).

      XAML is also used on Windows Phone development.
      TheCyberKnight
    • XAML is...

      There is substantial confusion around this topic. XAML (as TheCyberKnight pointed out) the UI language used by WPF but it is not itself WPF. XAML is used for WPF, Silverlight, Silverlight for Windows Phone 7 and Windows 8 Store Apps (aka Modern UI, formally known as Metro apps).
      WarmBody
  • C# future as a native language?

    Maybe Microsoft will drop the CLR backend in the future and replace it with the Windows Runtime. I mean, just look at the way how they make API metadata available for .NET applications: It's called Windows Metadata (WinMD), and it's almost the same format that .NET uses, so there are already some similarities.

    By design, C# doesn't require a specific runtime. What if they build a compiler for C# that generates native instead of IL code, like Bartok today, but designed to use the Windows Runtime as its backend infrastructure? That would make C# a far better choice over the weirdness of C++.

    What we would lose in the process is portability, of course. The Windows Runtime is, unlike the CLR, a proprietary, non-standardized runtime environment.
    sevenacids