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?
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
WinRT's biggest mistage
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
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.
What are you smoking?
Desktop is for serious work
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
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.
@Joe_Raby
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".
@tN0
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
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
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...
Doing some research, I stumbled upon this blog post: http://mrspiteri.wordpress.com/2011/10/16/windows-runtime-xaml-for-the-desktop/
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
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...
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
no joke
Why not just...
Because there are a whole lot of people who want Windows functionality ...
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?
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?
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
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...
C++/CX is not C++