Microsoft seeks more programming language support for Windows 8

Microsoft seeks more programming language support for Windows 8

Summary: Microsoft is hoping to convince more developers to bring their languages to Windows 8 and the new Windows 8 Runtime


While Windows 8 already supports development using a number of programming languages, Microsoft wants developers to bring even more to the new Windows runtime (WinRT) at the heart of the next version of Windows.

Martyn Lovell, Development Manager for the WinRT team, made the pitch for more language support for Windows 8 on April 3, during his Lang.Next conference session at Microsoft.

"Will WinRT be at home in each language?" Lovell rhetorically asked the Lang.Next attendees. "Yes, but never perfectly."

That said, Lovell said Microsoft "wants developers to create languages for the new (WinRT) developer platform."

WinRT already supports development in C++, JavaScript/HTML5, Visual Basic, Visual C# and XAML (a remote cousin of Silverlight). Lovell first publicly outlined Microsoft's plans for WinRT at the Build conference in September 2011.

Today at Lang.Next, Lovell said that almost all of the WinRT design principles he first presented to senior Windows leadership almost two years ago are still in place. A key idea in designing the new runtime was to make native, managed and dynamic languages all first class citizens in WinRT, with JavaScript, C#/VB and C++ as the initial targets.

"Windows Runtime is the whole of Windows," Lovell said. "It's how applications and languages interact" with the Windows core.

When designing WinRT, the team started with a few pieces of COM, Lovell said. In the end, they didn't keep much of it, however, he conceded. They kept things like marshalling and proxy systems, but COM was horrible at Intellisense, support for which is key to WinRT and Windows 8, he said.

Ever since the Build conference, developers have been trying to better understand WinRT and the overall architecture of Windows 8. Lovell outlined it in his own way, noting that Windows Core is at the heart of the platform, with the Windows Runtime core and its application programming interfaces -- things like the user interface, XAML, pickers, storage, controls, network and media -- on top of that.

Here is the core chunk of Lovell's architectural diagram (courtesy of DevExpress):

The latest Windows 8/WinRT architectural diagram I've found helpful comes from @bitcrazed, a k a former Softie and current Appuri co-founder Richard Turner. Check it out:

(click on the diagram above to enlarge)

Chakra (on the left side of the diagram, which is where "Metro-style" apps live) is the JavaScript engine that is at the heart of Internet Explorer 9/10. Trident is the rendering engine used by IE.

Microsoft officials have been encouraging developers to consider HTML5/JavaScript and C++ when writing new Metro-style apps. However, as Development and Platform Evangelist (DPE) Jerry Nixon recently noted, it's the managed languages and .Net that seem to be where most of the Windows 8 developer interest is -- at least when measured in terms of developer questions and comments on the MSDN forums.

Here's what the Windows 8 MSDN developer forum breakout looked like as of March 2012, in terms of number of messages in each topic area, from Nixon's blog post:

Nixon notes his findings are not scientific. Nor was my limited survey of a few independent developers who are writing apps for Windows 8 and prefer XAML and C#/VB. I guess it shouldn't be too surprising, however, that devs prefer using what they already know.

Back to Lovell's request for more programming languages for Metro-Style Windows 8 apps. Developers: What other existing languages would you like to have available for writing Windows 8 apps?

Topics: Software Development, Microsoft, Operating Systems, Software, Windows


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.


Log in or register to join the discussion
  • WinRT's biggest mistage

    I think the biggest mistake they made with WinRT is that those "modern" apps can't run on the desktop. Imagine there would only be one runtime for desktop and Metro-styled apps!

    Metro apps could have a single button to switch them to a "window" mode. No need to have two separate worlds, two versions of every app. Only one single IE 10, one Office suite, one suite of "Microsoft Live" apps (or whatever they will call Mail, Music and Photos app).

    MetroTwit and the Zune client shows how those apps could look running on the desktop.
    • wow

      someone really doesn't understand what Desktop is??? i will explain it to you, desktop its simply an APP for backwards compatibility.
      IF Microsoft didn't care about backwards compatibility like a lot of companies, Desktop wouldn't be there in x86-x64.
      because WOA doesnt have it, because windows future its about WinRT and its good they are starting somewhere in ARM since there isn't any real ARM device running windows. and of course, besides WinRT its a 1.0 product, it obviously cant be run on Win32, because they are 2 different things.
      Emi Cyberschreiber
      • What are you smoking?

        ARM does so have the desktop -- Microsoft even stated this in the big ARM blog post. Office 15 is a desktop suite, which they also showed. You need to get your facts straight. Professional applications will never become Metro apps because Metro apps have to be sold via the app store, and app store submissions must include the multi-PC license. Autodesk will NEVER offer 5 PC/device licensing for their products included in one price. Ditto for Adobe. Since Metro apps require that they be optimized for touch, many professional apps will never be ported over. And then you also have app developers writing LOB apps to be compatible with older versions of Windows....Your view of things is pretty short-sighted.
      • Desktop is for serious work

        The Desktop is not just there for compatibility concerns. Legacy Win32 apps could run in full screen inside the Metro UI. Actually IE10 in Metro is Win32 software looking like a WinRT app.

        The Desktop will not go away. It still is very relevant for doing serious work. The problem I was talking about is that with Windows 8 you have two systems inside one. Sometimes it is confusing. A PDF opened inside Windows Explorer may be displayed in a Metro app. A link inside a Metro RSS reader may take you to the default Desktop browser. And every time you are left in the other parallel Windows world.

        On the other side, it is not possible to start a task inside a Metro app (looking at pictures) and finish the same task on the desktop (enhancing that picture) and going back to Metro.

        It is known that WOA will have some kind of a desktop environment and that Office 15 will have a touch mode.
      • You're all techinically correct

        @Emi Cyberschreiber
        Yes, WinRT is the future for microsoft as far as app platforms are concerned, although this does not mean that win32 will be killed off completely. Will it be deprecated? Yes, but just like we have access to impossible to do without DOS/CLI scripting functionality through tools like the command prompt, so will the desktop/win32 exist in a metro/winRt future.

        You're correct, the desktop exists in ARM but I think EC was actually referring to the fact that apart from Microsoft's applications, nothing else will run on the ARM desktop which makes it non-existent as far as devs are concerned, atleast that's what I understood from his comment. On your examples with AutoDesk and Adobe, I'll have to disagree. If you understand it from the perspective of where and how Microsoft is positioning metro/winRt, then you'd see that in the long run, any dev, be it individual, professional, hobbyist or big tech company, serious about building applications in a windows 8/post windows 8 platform world will have no choice but to embrace metro/winRT even if it comes at a great cost and effort. Obviously, this won't happen immediately windows 8 launches, it will take a bit of time, heck, some might even decide to wait until windows 8 or to be precise 'metro/winrt' gains enough traction (trust me, it definitely will, as long as it's persistently in your face as it is now in windows 8). The point here being that Microsoft is basically saying "Hey, Metro/WinRt is now how windows will look and behave for the majority of the windows consumers out there, so if you still want to keep developing for windows in the future you'd have to get used to this".

        I think you're looking at it all wrong; Microsoft wants the two systems (win32 & WinRT) to be as disparate as possible. It helps them create more emphasis on what they're positioning as the future of Windows (WinRT/Metro). This is why only browsers are allowed to access win32 APIs from metro while everybody else is given a resounding and firm NO. In fact, the only reason browsers are given this exception is mostly likely because WinRT is not yet matured enough to handle certain critical system functions (hardware accelerated browsing comes to mind here) that are needed by well established browsers like Firefox, IE and chrome, which in many ways are miny operating systems themselves. Not all Win32 libraries have direct equivalents on WinRt as I understand, certain COM constructs where used but not all in building it, even the GDI is not being used by the WinRT subsystem. I don't know how Microsoft is going to improve WinRT in future or even if it wants it to be completely independent of the Win32 subsystem especially for browsers but when you analyze the information we have now one could boldly predict that since WinRT is completely object oriented and only allows asynchronous operation modes for application processes, then it might just be that Microsoft is hard at work trying to find an easier way for app developers to re-implement/re-imagine their win32 Applications into WinRT ones.
      • Not really

        "...desktop its simply an APP for backwards compatibility."

        Nope. Even Microsoft clearly says that the Metro Style Language is not suited for all applications. In fact, Microsoft is going to release several applications this year (or maybe even next year) that are desktop only. The Office Suite applications are *all* desktop applications; so is Visual Studio 11.
      • @MADol

        Windows 8 isn't getting rid of the desktop. I suspect even Windows 9 won't either. What is removing the desktop app compatibility is just WOA, which is destined towards the consumer market.

        Don't forget that businesses can use WOA for BYOD, but legacy apps will run in RemoteApp, and Remote Desktop Connection is available as a Metro app. I haven't honestly checked, so I don't know this, but [b]can someone confirm as to whether or not WOA will ship with a desktop version of Remote Desktop Connection?[/b] What I'd like to know is how RDC works with different apps. I assume that Metro RDC will open desktop RemoteApp's on the actual desktop.

        Oh, and CarlitosLx has it right: Microsoft did state that they are not deprecating the desktop any time soon.
    • Well, it's incomplete...

      If you take a closer look on the Windows Runtime APIs (just use a tool like Reflector or ILSpy, or simply ILDism on the Windows Metadata files), the overall design is very abstract and extensible, and there are hints that Metro-style apps are not the only kind of applications or fullscreen XAML the only user interface possible. As for now, there are already two different types of applications/user interfaces you can create: Metro-style apps that use XAML, and Metro-style games that use DirectX.

      Doing some research, I stumbled upon this blog post:

      It's no fake: someone already managed to make the XAML-implementation of the Windows Runtime run in a "traditional" Win32 window. So there is absolutely no reason to believe that we won't see applications in the future that are based on the Windows Runtime but work and act in a windowed manner like Win32 applications today.
  • Joke

    They must be joking given their track record. They probably asked for other languages to support WPF and Silverlight both of which are buried and cold all in about 5 years.

    And if tablets with Windows 8 don't do good, and that's very likely, WinRT will be hitting same hard times as well. So why support something that in all likelihood is to be around for next 5 years and until new shiny thing show up?

    Microsoft lost a lot of good will from developer community with how it handled WPF and Silverlight. And people will be reluctant to bite onto another hook easily.
    • There are technical reasons...

      WPF and Silverlight are both based on managed code that is executed by the CLR of the .NET Framework, so every language that is available for .NET can be used for WPF/Silverlight programming and Microsoft didn't have to ask for support for other languages (well, they actually did but for the .NET platform altogether and not WPF or Silverlight alone).

      Now, the difference with the Windows Runtime is that it is based on COM, which is native code, and not so easy to use for managed languages, for example, because in the traditional approach you have to cross of the managed/unmanaged boundary at some point and this is very expensive. Microsoft came up with a pretty nice solution here called "projections", a modern kind of typification, so that managed languages can call directly into native code without the need for marshaling etc. by simply providing metadata in a format that can be understood by them. Well, but this works only for .NET. Every other "exotic" language needs to provide their own way how to interact with the APIs. That's why they ask language designers to adapt for the new model.

      The problem with WPF/Silverlight was that is was only accessible from .NET, native languages like C++ couldn't be used. Now they solved it by providing an API that can be accessed by both managed and native code if the languages provides it.
      • Most sensible answer in the thread!

    • You nailed it

      You nailed it. Microsoft is notorious for chasing the "next shiny thing." The API's that Microsoft has released as the next big thing and then abandoned in the last 10 years would fill a drive.
    • no joke

      As a Silverlight developer, I'm actually pretty excited about WinRT joining the ecosystem. Microsoft will improve tooling around profiling across the managed/unmanaged boundary to make sure WinRT apps are performant and don't hog memory. These improvements will help Silverlight as well, as much of the core is unmanaged.
  • Why not just...

    ...actually make money programming an Office Suite for iOS and Android?
    Tony Burzio
    • Because there are a whole lot of people who want Windows functionality ...

      ... with what runs on top of it.

      iOS and Android tablets may be popular, but they are still only a minor part of the total computing world.
      • How does this prevent Microsoft making money out of software?

        Once upon a time, Microsoft used to be software company writing software for different platforms, including the Apple ][ computers. For the IBM PC etc.

        What is wrong with selling your popular software (office suite) on as many platform as there are around?

        If Microsoft is dreaming about taking over that market by not offering their applications on other platform, chances are they may lose big, because other vendors will fill the niche and then will come to Microsoft's own turf to compete.
  • What Would I Like?

    F# (and OCaml), java/jvm, perl, python, PHP, Objective-C, Haskell, Ruby (maybe powered by the CLR, the way JRuby uses the jvm). One can get these things onto a Windows system, but hooks into the GUI, Networking, System Parallel Processing Support, and Data Persistence apis would go a long way towards making the applications' polish as nice as the underlying implementations of algorithms.

    Turning to the heart of the Invitation to the Dance, were my wish list be fulfilled, would the languages I prefer smoothly integrate into the WinRT environment...

    "Yes..." [good!], "but never perfectly." Hmmm. Well, that's the trick isn't it? Development is hard enough without impedance mismatches, and if this is just p.r. smoke, well, why bother? Just say, like Apple, these are the languages of WinRT development, learn them and learn them well.

    Plus, did Mr. Lovell have to face up to any questions about IronPython?
  • Addressing the actual question

    How typical. Any article about Windows 8, and the comments immediately fill up with "Let me tell you what *I* think Microsoft is doing wrong here".

    So addressing MJ's actual question, I'm primarily a C#/XAML dev, and they've got those covered pretty well. To everyone talking about how Microsoft burned us with WPF/Silverlight, as a dev who actually uses WPF and Silverlight myself, I think that attitude is kind of ridiculous. A lot of WPF and Silverlight UI code can be ported straight into WinRT without problems. Of course, you may not WANT to port that straight in since your old XAML probably doesn't match the Metro design language, but you certainly can reuse any pieces you want. And all the XAML skills you learn with WPF/Silverlight carry right over to WinRT, so I don't really see a problem there. WinRT also performs much better than WPF/Silverlight since it's native, and frankly one of my biggest gripes with WPF/Silverlight is the performance so that's great news.

    Otherwise, I'd like to see F# and Python with native WinRT ports. I remember after the WinRT session at Build I specifically asked the Microsoft presenter if other languages could be ported to use with WinRT natively the way C++/C#/JS/VB do, and he said they could. So I guess I already knew they were doing this, although it's nice to have confirmation that it's a priority for them.
    • Agreed...

      ...and there's more: The Windows Runtime APIs can be accessed by native languages like C++, which is another big issue with WPF/Silverlight.
      • C++/CX is not C++

        You can use WinRT with C++/CX, a Microsoft specific language extension that make C++ look like C#. C++/CX is not C++. C++/CX doesn't even look like C++.